A cup of Java

One of the advantages of living on the bleeding edge as it comes to EJB3, is that you can come up with solutions other (.NET) developers can only dream of. Such solutions to common design problems not necessarily need to be very complex. We all like to KISS every now and them, right? One such rather simple design problem is bootstrapping an application. It's like when you have a method in your code that is allowed to be executed only once. Most of the time developers go off like this:

    void bootstrapApplication(...) {
        if (alreadyBeenCalled()) {
            throw new IllegalStateException("bootstrapping twice");
        }
        doBootstrapApplication();
    }

Which, OK, works, but, on the other hand, is a very boring way of coding methods. Once you have to provide bootstrap functionality to a number of services within your system, it becomes too much of a copy-and-paste operation. It just smells bad. One way to handle such situation is to aspectize the bootstrap... aspect. The idea is that you would like to end up with something very clean like:

    @Bootstrap
    void bootstrapApplication(...) {
        ...
    }

where you handle over the bootstrap aspect to some EJB3 default interceptor. The bootstrap interceptor uses a bootstrap service to keep track of whether a method already has been called or not. One nice thing about this design is that you have a central point within your system that can be contacted to query for bootstrap information. Suppose we annotate a method like this:

    public static final String A_BOOTSTRAP_ID = "system-x-bootstrap-id";

    @Bootstrap(A_BOOTSTRAP_ID)
    void bootstrapSystem(...) {
        ...
    }

If, for some reason, we want to check that this part of the application has already been bootstrapped, we simple go to the bootstrap service and ask for it via the given A_BOOTSTRAP_ID. Lovely, isn't it? This is what I like about such designs. The basic idea is simple. The implementation can be done very quickly when you run inside of an EJB3 J2EE container. I implemented this in something like 30 minutes. (BTW: a nice definition of a container: something that manages all kinds of aspects, even the aspect of defining new aspects). And despite its simplicity, it gives you a very powerful and flexible solution to the bootstrap problem.

Along with a recent spike in one of the projects I'm working on, i.e. to verify whether we can run a highly distributed system in JBoss Application Server, I also took the opportunity to go and investigate on the applicability of Maven2 as a production build system. Since I'm already quite experienced at working with Maven1 (also known as Ant on Jelly-based steroids), I thought this wouldn't be that much of an issue. But after a while, I found out why they pushed for a new major version number. Besides the absence of good documentation (at JavaPolis I heard they're writing a Maven2 book, which is probably why there isn't much online documentation), this is really a complete make-over of the Maven1 build system. Compared to Maven1 you'll immediately notice that the repository is much better structured. Really new in Maven2 are the explicit build phases. But then again, this is something you already had to introduce in Maven1 projects when you wanted to use the reactor to perform a multi-project build. Another big improvement is the explicit plugin versioning. This is needed to make your builds completely reproducible.

While Maven1 still allows one to do Ant-isch builds, Maven2 completely breaks with this (not taking the ugly duckling maven-antrun-plugin into account). In the beginning you tend to feel that Maven2 really disallows you to do things your way. With Maven1 you just had to create a maven.xml file to start customizing the build of your artifact. To customize a build with Maven2, you're almost forced to create a new Maven plugin, aka MOJO, if not even to define a complete new artifact packaging. But, when you start thinking of it, do you really want to do a custom build?
I think it's OK that it hurts when you're trying to customize your build, simply because you should not be doing so. F*ck the custom builds. In most cases you can get rid of them.

At Sun they spend a lot of time and money defining various J2EE archives to solve all kind of problems. Some with more success than others. So why not simply settle with them and use a build system that is very good at dealing with standard J2EE component formats? It makes your daily life a lot easier (that is, at least the developer part of it, for the other aspects, a good advice, never use standard components). This is especially true whey you're deploying your application on a standard application server like JBoss AS. (As for some of you with who I've got into discussion on this topic, just for the record, MSSQL server is not an application server, thank you.)

One area where I would like to see some improvements is JMX MBean packaging. On JBoss you have a SAR packaging which works just fine, but it's not really a standard J2EE component yet. I don't think Sun's Glassfish will eat it as is. Not only because of the packaging, but also because of the container specific JMX stuff you put inside your MBeans. It would be nice that the most common JMX services, that a J2EE container offers, were somehow standardized. This would make J2EE applications, that need to tweak the container, more container independent. As for the MBean development itself, what is taking the Sun annotation junkies so long to clean up the meta-data API of the MBean? Same remark for the Maven2 plugin API here. XDoclet-alike annotations feel too much like, well, XDoclet. Hopefully we'll see some of the here above mentioned issues getting addressed by JCPs in the near future.

Once you can agree on building only standard J2EE components, I think you gain great benefit from using build systems like Maven2 compared to Ant-based ... systems. Don't listen to the stories of some people telling you that Maven2 still needs some time to mature. That's just script-kiddie nonsense. It had time to mature via Maven1. The only thing that needs to mature is those people's willingness to adopt new ways of building their components according to the (new EJB3) J2EE standards.

JBoss AS 4.0.4RC1 is available for download from:

http://prdownloads.sourceforge.net/jboss/jboss-4.0.4RC1-installer.jar?download

It contains the latest EJB3 RC4, which is more in line with the EJB3 spec (or is it the other way around?). This unfortunately also forces you to update your EJB3 projects, since they probably won't run anymore because of the changes in RC4. So, have fun.