Monday, August 15, 2011

Migrating from JBoss 4.3 to Jboss 5.1

In several of my previous jobs, which involved an enterprise application that ran on an application server, it usually was the one made by JBoss. The downside is that I know next to nothing about Websphere, Glassfish, and other competing servers, but the upside is that I'm pretty familiar with JBoss.

JBoss version 4, that is. And now, in 2011, I found out that the new project I'm working on, also uses JBoss 4. Yes, I know, it's Jboss 4.3 EAP, enterprise supported by Red Hat, which not long ago I found out is not the same as version 4.2, as the messaging system is different. But still, it just feels so old! JBoss AS is version 7 already, which I have to say, boots REALLY fast, and I've got the feeling that I'll be using JBoss 7 at work maybe in the year 2015.

Now, you'll say: but neither JBoss 6 nor 7 are not full JEE certified! They even haven't got EAP versions! (I think Jboss 7.1 will be EAP). So this time I focused on trying to run the current system on JBoss 5.1

This is not the first time I do this. That was last year, on another project, but couldn't succeed and ran out of time. Luckily this time I did have success. What happened last time was that the queues were in JBossMQ, and I didn't know how to migrate them to JBoss Messaging. This time, as the system runs in JBoss 4.3, it's already configured for JBoss Messaging, so that part was easy.

Also, the WARs used the Spring Framework, so there are no EJBs or EARs to convert. That also made the migrating process easier, although it made less sense to migrate, as it was only for the microkernel of JBoss 5, the JMS and the new version of JTA. No new EJB container nor Hibernate that mattered this time.

But still there were a few quirks:

  1. Classpath: One of the projects included a JAR library with JAXB implementation, and since that's included in Java 6, there was an exception because you had the same classes in different classloaders on the same hierarchy and JBoss 5.1 was picky about that.
  2. Libraries in SAR package: They needed to be in root of the SAR instead of in the lib folder. There is a workaround (or maybe it's the official way) by using jboss-structure.xml to specify where the libraries are, but haven't used that.
In conclusion: easier to migrate if you don't use the EJB stack, as I didn't have to deal with ejb-jar.xml, persistence.xml and the kind, but still not as easy or straightforward that I'd like to. I guess it won't be easier to move to JBoss 6 or 7, or even another application server. So much for standards...

No comments: