[Amos]

Hi,

I’ve noticed something rather strange when adding Web project capabilities to a project I’m working on (integrating JForum into our framework).

There’s a class

public class IdentifiableMimeMessage extends MimeMessage

which implements the following:

    /**
     * @see javax.mail.internet.MimeMessage#updateMessageID()
     */
    protected void updateMessageID() throws MessagingException {
        if (this.messageId != null) {
            this.addHeader("Message-ID", this.messageId);
        } else {
            super.updateMessageID();
        }
    }

This code seems fine in a pure “Java project”, but as soon as I add web project capabilities to the project, I get a validation error on the call to super.updateMessageId(). My first thought was that the action had replaced the mail.jar file in the project, so I created two versions of the project, one with and one without web project capabilities. I’ve had a look at the timestamp of mail.jar in both versions, and they’re exactly the same, yet the validation is fine in one case and gives an error in the other.

I removed web project capabilities and added them back in, this time not checking the “Add J2EE Libs to Buildpath” box (the project comes with the jars anyway), and didn’t get the validation error.

From the javadoc of MimeMessage, it seems the method updateMessageID() has been there since JavaMail version 1.4 – does the web project bit add a prior version? Is there any way to control which jars the web project bit adds and which it doesn’t?

It’s no big deal since I can work around it, but I’m still curious why I got the error in one case and not in the other when the mail.jars were exactly the same (I tried copying the “valid” one over, doing a “clean” and manually running the validation). Is there anything I’m missing?

[Riyad Kalla]

You nailed it on the head. JavaMail 1.4 is the newest release, and what we are adding with web capabilities is the entire J2EE 1.4 stack, which is quite a bit older (2-3 years now?). Comming in our next release we will be adding JEE 5 library stack that can be added to the project if that is desired, but it sounds like you got things under control (if the libraries are already in the project, just skip adding our library set).

[Amos]

Ah, ok, thanks for confirming that. It’d be nice if it were possible to choose (at the time of adding the web capabilities) which jars were added and which weren’t, with defaults being the latest version. 🙂

[Riyad Kalla]

See that’s the problem though, the J2EE spec defines XYZ versions of every JAR that comprises it. To be J2EE 1.4 compliant, we have to ship exactly that list. Adding version 1.4 of Mail API to that set no longer makes up the “J2EE 1.4 compliant library set” and instead makes up some other hybrid thingie.

But, if you mean the newest version of the JEE specification (5.0), then yes that will be coming in our next release which will certainly have Mail 1.4 in it, along with many many other things.

But I suppose that’s the blessing and the curse of specs… consistent, but can get severly outdated in the name of consistency.

[Amos]

Good point… I’m only finding out just how confusing it can get now that I’m trying to integrate an open-source project with our existing framework. 😕

[Author]

Posts