Bits & Bytes

Order of BodyPart in Java Mail

2008-05-21T14:00:00.015+05:30

I always had confusion on how to send both text and html with images content in single mail, so that all the mail clients which can render html will show html content and others which cannot render HTML will show the text content.

While sending any mail, the content-type of the mail is very important. Every content to be sent is attached to the MimeMessage as a BodyPart with proper Content type. i.e if we send a simple Text mail, content type would be text/plain, for a HTML mail it would be text/html. similarly if we send a HTML mail with embedded images, it would be multipart/relative message with each part specifying its content type.

When coming to sending both text and html content along with embedded messages ( will be referred as TEXT-HTML images embedded mail herewith ), its gets bit complex, which i want to discuss here. The order in which these BodyParts are attached to the MimeMessage is very important so that message gets rendered properly in all mail clients.

First we will look at creating the various body parts needed in sending a TEXT-HTML images embedded mail.

  
    private BodyPart createTextBody(File textContentFile)
            throws MessagingException, IOException
    {
        StringBuffer contentBuffer = new StringBuffer();

        BufferedReader reader = null;
        FileInputStream stream = null;
        try {
            stream = new FileInputStream(textContentFile);
            reader = new BufferedReader(new InputStreamReader(stream, "utf-8"));
            String content;
            while ((content = reader.readLine()) != null) {
                contentBuffer.append(content);
            }
        } finally {
            if (reader != null) {
                reader.close();
            }
            if (stream != null) {
                stream.close();
            }
        }

        BodyPart textMessageBodyPart = new MimeBodyPart();
        textMessageBodyPart.setContent(contentBuffer.toString(), "text/plain; charset=UTF-8");
        return textMessageBodyPart;
    }

    private BodyPart createHtmlBody(File htmlContentFile)
            throws MessagingException, IOException
    {
        StringBuffer contentBuffer = new StringBuffer();

        BufferedReader reader = null;
        FileInputStream stream = null;
        try {
            stream = new FileInputStream(htmlContentFile);
            reader = new BufferedReader(new InputStreamReader(stream, "utf-8"));
            String content;
            while ((content = reader.readLine()) != null) {
                contentBuffer.append(content);
            }
        } finally {
            if (reader != null) {
                reader.close();
            }
            if (stream != null) {
                stream.close();
            }
        }

        BodyPart messageBodyPart = new MimeBodyPart();
        messageBodyPart.setContent(contentBuffer.toString(), "text/html; charset=UTF-8");

        return messageBodyPart;
    }

    private BodyPart createImagePart(File imagePath, String cid)
            throws MessagingException
    {
        BodyPart messageBodyPart = new MimeBodyPart();
        messageBodyPart.setDataHandler(new DataHandler(new FileDataSource(imagePath)));
        messageBodyPart.setHeader("Content-ID", "<" + cid + ">");
        messageBodyPart.setDisposition("inline");

        return messageBodyPart;
    }

Attaching these contents to mimemessage, we have two options (actually its only one option, as other option will not render the email properly in some mail clients, which is the reason for this entire article)

Option one:
Create a multipart/alternative message, with two parts

First part having the TextBodyPart.
Second part will be a multipart/related message, again with two parts
- First part will have HTMLBodyPart
- Second part will be the ImageBodyPart to be Embedded which were used in HTMLBodyPart

How on arriving at the above multipart subtypes is beyond the scope of this entry. Interested users can get needed information here

Translating the above steps into code:

    private void updateContentOptionOne(MimeMessage mimeMessage, File textContentFile, 
                                        File htmlContentFile, File imagePath)
            throws MessagingException, IOException
    {
        MimeMultipart outerPart = new MimeMultipart("alternative");

        BodyPart textBody = createTextBody(textContentFile);
        outerPart.addBodyPart(textBody);

        MimeMultipart innerPart = new MimeMultipart("related");
        innerPart.addBodyPart(createHtmlBody(htmlContentFile));
        innerPart.addBodyPart(createImagePart(imagePath, imagePath.getName()));

        BodyPart relatedPart = new MimeBodyPart();
        relatedPart.setContent(innerPart);
        outerPart.addBodyPart(relatedPart);

        mimeMessage.setContent(outerPart);
    }

If the above sent content is checked in Yahoo! Mail, Gmail or on offline web clients like Thnderbird, Evolution everything looks fine. but if you use a webmail Client which displays only textContent like SquirrelMail, you will see only the text content. and there would be no option to view the html content as shown below:

Coming to the Option two:

Create a multipart/related message, with two parts

First part will be a multipart/alternative message, again with two parts
- First part will have TextBodyPart
- Second part having the HTMLBodyPart
Second part will be the ImageBodyPart to be Embedded which are used in HTMLBodyPart

Translating the above steps into code:

    private void updateContentOptionTwo(MimeMessage mimeMessage, File textContentFile, 
                                        File htmlContentFile, File imagePath)
            throws MessagingException, IOException
    {
        MimeMultipart outerPart = new MimeMultipart("related");

        MimeMultipart innerPart = new MimeMultipart("alternative");
        innerPart.addBodyPart(createTextBody(textContentFile));
        innerPart.addBodyPart(createHtmlBody(htmlContentFile));

        BodyPart alternativePart = new MimeBodyPart();
        alternativePart.setContent(innerPart);
        outerPart.addBodyPart(alternativePart);

        BodyPart imagePart = createImagePart(imagePath, imagePath.getName());
        outerPart.addBodyPart(imagePart);

        mimeMessage.setContent(outerPart);
    }

Now if you check the mail sent in SquirrelMail WebMailClient, it looks like below, text content with html mail as an attachment.

Clicking on the attachment will show the HTML content.

Again in this option (Option Two), the order in which we attach the alternative messages are important, as in some offline mail clients like Thunderbird (tested on version 2.0.0.14), it picks up the last alternative message in the list of available alternatives it can render. So if we attach the HtmlBodypart before the TextBodyPart, we would be seeing the Text content, though Thunderbird can render the HTML content attached.

Download Source

Java Object Serialization

2007-05-15T10:34:00.002+05:30

Java Object Serialization is often confused subject for me. I first learned about them when i was having my Java training. Then when i got to use this for persisting session information for our container, i read more on this and went through the SUN's JDK source. While going though i found something interesting, which lead to think that Java serialization can break in some cases. I may be wrong, but again i want users who read this blog to explain where did i go wrong. let us try first with an example. ClassA has a writeReplace which replaces itself with instance of ClassB.

public class ClassA
        implements Serializable
{
    private String classAData;

    public ClassA(String classAData)
    {
        this.classAData = classAData;
    }

    public String getClassAData()
    {
        return classAData;
    }

    public Object writeReplace()
    {
        System.out.println("ClassA.WriteReplace [" + this + "]");
        return new ClassB(classAData);
    }

    public Object readResolve()
    {
        System.out.println("ClassA.readResolve --> Nothing to do");
        return this;
    }

    public String toString()
    {
        return "Class A: " + classAData;
    }
}

and ClassB does vice-versa i.e has readResolve which replaces itself with instance of ClassA.

public class ClassB
        implements Serializable
{
    private String classBData;

    public ClassB(String classBData)
    {
        this.classBData = classBData;
    }

    public String getClassBData()
    {
        return classBData;
    }

    public Object writeReplace()
    {
        System.out.println("ClassB.writeReplace -->  Nothing to do");
        return this;
    }

    public Object readResolve()
    {
        System.out.println("ClassB.readResolve [" + this + "]");
        return new ClassA(classBData);
    }

    public String toString()
    {
        return "Class B: " + classBData;
    }
}

ClassC has a writeObject and readObject where it writes/reads its variable 'classCData' into/from object stream respectively.

public class ClassC
        implements Serializable
{
    private String classCData;

    public ClassC(String classCData)
    {
        this.classCData = classCData;
    }

    public String getClassCData()
    {
        return classCData;
    }

    private void writeObject(ObjectOutputStream out) throws IOException
    {
        System.out.println("ClassC.writeObject");
        out.writeObject("SU:" + classCData);
    }

    private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException
    {
        System.out.println("ClassC.readObject");
        String str = (String) in.readObject();
        classCData = str.substring(3);
    }

    public Object writeReplace()
    {
        System.out.println("ClassC.writeReplace --> Nothing to do");
        return this;
    }

    public Object readResolve()
    {
        System.out.println("ClassC.readResolve --> Nothing to do");
        return this;
    }

    public String toString()
    {
        return "Class C: " + classCData;
    }
}

CustomObjectInputStream has a resolveObject where it replaces an Object of ClassC with ClassB

public class CustomObjectInputStream
        extends ObjectInputStream
{
    public CustomObjectInputStream(InputStream in)
            throws IOException
    {
        super(in);
        enableResolveObject(true);
    }

    protected Object resolveObject(Object obj) throws IOException
    {
        if (obj instanceof ClassA || obj instanceof ClassB || obj instanceof ClassC) {
            System.out.println("CustomObjectInputStream.resolveObject [" + obj + "]");
        }
        if (obj instanceof ClassC) {
            return new ClassB(((ClassC) obj).getClassCData());
        }
        return obj;
    }
}

and CustomObjectOutputStream does vice versa i.e has a replaceObject where it replaces a an Object of ClassB with ClassC

public class CustomObjectOutputStream
        extends ObjectOutputStream
{
    public CustomObjectOutputStream(OutputStream out)
            throws IOException
    {
        super(out);
        enableReplaceObject(true);
    }

    protected Object replaceObject(Object obj) throws IOException
    {
        if (obj instanceof ClassA || obj instanceof ClassB || obj instanceof ClassC) {
            System.out.println("CustomObjectOutputStream.replaceObject [" + obj + "]");
        }
        if (obj instanceof ClassB) {
            return new ClassC(((ClassB) obj).getClassBData());
        }
        return obj;
    }
}

Now my Main class looks like below:

public class Main
{
    public static void main(String[] args) throws IOException, ClassNotFoundException
    {
        ByteArrayOutputStream byteOutStream = new ByteArrayOutputStream();
        CustomObjectOutputStream objOutStream = new CustomObjectOutputStream(byteOutStream);

        ClassA obj = new ClassA("Test***String");
        objOutStream.writeObject(obj);
        objOutStream.flush();
        byte[] data = byteOutStream.toByteArray();


        ByteArrayInputStream byteInStream = new ByteArrayInputStream(data);
        CustomObjectInputStream objInStream = new CustomObjectInputStream(byteInStream);
        Object reCreatedObj = objInStream.readObject();
        if (reCreatedObj instanceof ClassA) {
            System.out.println("Class is correct");
            if (obj.getClassAData().equals(((ClassA) reCreatedObj).getClassAData())) {
                System.out.println("data also matched");
            } else {
                System.out.println("data Didnt matched");
            }
        } else {
            System.out.println("Read and write DataObject Failed. returned Object [" + reCreatedObj + "]");
        }
    }
}

I expected output to be like:

ClassA.WriteReplace [Class A: Test***String]
ClassB.writeReplace -->  Nothing to do
CustomObjectOutputStream.replaceObject [Class B: Test***String]
ClassC.writeObject
ClassC.readObject
CustomObjectInputStream.resolveObject [Class C: Test***String]
ClassB.readResolve [Class B: Test***String]
ClassA.readResolve --> Nothing to do
Class is correct
data also matched

but the output is

ClassA.WriteReplace [Class A: Test***String]
ClassB.writeReplace -->  Nothing to do
CustomObjectOutputStream.replaceObject [Class B: Test***String]
ClassC.writeObject
ClassC.readObject
ClassC.readResolve --> Nothing to do
CustomObjectInputStream.resolveObject [Class C: Test***String]
Read and write DataObject Failed. returned Object [Class B: Test***String]

Now going through the ObjectOutputStream and ObjectInputStream Source Code you will find the following sequence followed in persisting and resolving an Object. While converting an Object into a series of bytes:

Check whether ObjectOutputStream is created using overridden default constructor. if yes, just give callback to writeObjectOverride(Object obj) and return. (In our case, CustomObjectOutputStream doesn't override default Constructor. so go to step 2)
If not, Check whether the Object to be persisted has a writeReplace method overridden. If yes, replace the incoming Object with returned Object. (in our case, ClassA has overridden WriteReplace. After this method invocation, the object to be persisted is Object of type ClassB). Repeat step 2 if the returned Object has a writeReplace(), until an object returned doesn't override writeReplace().
Then Check whether ObjectOuputStream has a replaceObject(Object obj) method. If yes, pass the above returned Object and get the new Object to be persisted. This method would be invoked only when the ObjectOutputStream sub class, sets the enableReplaceObject(boolean) to true. (enableReplaceObject is set for our CustomObjectOutputStream. So invoking above method with object of type ClassB, returns Object of type ClassC)
Then check whether the replaced object from above method implements Serializable/Externalizable. if not, throw InvalidClassException. (ClassC implements Serializable)
else, write the class Description first. and then if above object extends Serializable invoke writeObject() if defined or else persist all the primitive data. Or if above Object extends Externalizable invoke writeExternal. (Object of type ClassC is converted into bytes using writeObject).

and while recreating, with above created bytes,

Check whether ObjectInputStream is created using overridden default constructor. If yes, give call Back to readObjectOverride(), and return. (In our case, CustomObjectInputStream doesn't override defaultConstructor. so go to step 2)
If not, read the classDescription First. and if the constructed class instance is not of type Serializable the data is corrupted, so throw a InvalidClassException. (Object of ClassC is created)
Then check whether class implements Externalizable/Serializable and invoke readExternal or readObject() respectively and get an instance. (as ClassC implements Serializable invoke readObject())
Then invoke the readResolve method if defined on the above resolve method. (now here, ClassC readResolve() method is invoked which doesn't do anything). This is not a recursive call unlike writeReplace().
Then check whether the ObjectInputStream has a resolveObject. If yes, pass this Object and return the returned Object as the Object constructed from persisted bytes. (as ObjectInputStream has a resolveObject method defined, we pass Object of type ClassC, so returned Object would be of type ClassB).

So when we compare both persisted Object (type ClassA) and recreated Object (type ClassB) they don't match. If SUN's Java Serialization has been written in such a way that above sequences 4 and 5 are interchanged, it would have been exactly as i have expected. Now i don't know the reason why sun Java serialization is implemented in above fashion. if anyone there know please update me by putting your comments. PS: tried above example on SUN JDK 1.5.0_10.