Benefits (and tips) of an upgrade from JBoss 4.2.x to JBoss 5.x, 6.x, 7.x and WildFly 8.x?

Question

Please assume that I do not need to worry about development time and costs: I am interested in general technical benefits (improved performance? improved APIs?) and new features.

I am currently working on products using 4.2.x, and we consider a major shift for versions that are a long time ahead and need to converge.

I had a brief look at the release notes of each version and some articles about each release for 5.x, 6.x, 7.x and 8.x. But I would be glad to have first-hand feedback from people who have made the switch.

I noticed there are some important changes surrounding messaging (switching from JBoss MQ to JBoss Messenging), and that for JBoss 7.x it seems to change a fair bit its configuration layer. Then there's a lot more going on when switching to JBoss/WildFly 8.x.

Please recommend good articles pointing at pitfalls if you can. I found a few for migrations to JBoss 5.x, but not that many for 6.x or even 7.x, and someone else is evaluating 8.x for us now. Feel free to recommend alternatives as well if you think they are relevant, though I'd prefer to focus only on JBoss.

For information, we use a mix of JPF- and OSGi-enabled (using Eclipse Equinox) plugin-based systems, with clients developed in Swing (some deployed via WebStart).

Update: Though this question brought some great answers already, I think it deserves an update for WildFly (and actually, our internal projects delayed making the switch from 4.2.x to 7.x as originally planned to wait for WildFly). New thoughts and answers are welcome.

Solution 1

I've upgraded from JBoss 4 to 5 and from experience the following are the most important to note:

• JBoss 5 (and 6 and 7) are not as forgiving as JBoss 4 with XML files. You must make sure that all your deployment descriptor XML files are valid. You may be using DTDs in some files - I recommend upgrading these to use XML schema instead.
• Some libraries may cause incompatibilities. This can be particularly true if you access web services and/or do XML parsing
• If you precompile your JSPs in JBoss 4, you probably won't be able to in JBoss 6/7.
• JBoss 4 and 5 use different message queue implementations. If you have any message queues or topics defined you will need to redefine them.
• JBoss TreeCache is no longer used. If you use this for caching purposes, you will need to change to use the new JBoss cache instead.
• JBoss 5 security is different. If your remote clients require secured access to JBoss, you will need to configure them differently.

Some useful resources are:

https://dzone.com/articles/migrating-jboss-4-jboss-5 http://venugopaal.wordpress.com/2009/02/02/jboss405-to-jboss-5ga

Officially JBoss 6 is only certified for the Java EE Web Profile, so if you use "legacy" features such as EJB 2.x, they will potentially not be supported in the future. Depending on the lifecycle of your application, this may or may not be a problem. JBoss 6 currently supports EJB2.1 fully, but it is not certified against this.

I have also found that JBoss 5 handles memory a lot better that JBoss 4. With JBoss 4 I see a lot more PermGen errors than I do with JBoss 5.

Solution 2

I can only speak from production experience with JBoss 5.1.0 and some investigation of version 6.

JBoss 5 is Java EE 5 and JBoss 6 and 7 are Java EE 6. The disparity in API features is best documented in those specs. JBoss 6 is likely to have a very short shelf-life; it is only certified for the Java EE 6 web profile and bugfixes are being targeted at version 7 (in its 3rd beta at time of writing).

I think you'd get better answers on the JBoss community forum.

Solution 3

We upgraded from JBoss AS 5 to JBoss AS 7 and are eying towards WildFly AS 8.1. Right now we can't migrate to 8 because there is no MQ Series JMS 2 RAR.

Some of the differences:

• The configuration is so much better and simpler. It's no longer spread over 20 XML files in which you configure aspects in XML files. Instead everything is one central place. All ports are configured in one central place, there is no longer an XSL file that transforms server.xml. You can make sense of the configuration file without knowing the implementation details of classes. It's hard to appreciate this if you've never configured a JBoss 5.x.
• The class loading model looks sane and you get a lot of control through jboss-deployment-structure.xml
• The centralized logging (Slf4j, JUL, JCL, Log4j, …) is really nice.
• The EJB client library looks much more cleaned up. It's down to 10 JARs from 20, half of them are even OSGi bundles (our client is an Eclipse RCP application).
• The EJB client maven dependency mess is gone, instead you now get a BOM POM.
• You get a BOM POM for the server APIs.
• Faster start up and less memory usage. We deploy 80 EJBs and the MQ Series RAR in 6 seconds without much tuning. Our live dataset is somewhere above 200 MB.
• The deployments folder is empty by default
• The (lack of) quality of XNIO is scary. In 7.x it's only used for EJB remoting and we hit several show stopper bugs (deadlocks, double free, socket handle leaks, …). In 8.x it is used for servlets as well instead of Tomcat. There are still a lot of very basic servlet bugs being fixed in undertow.

Changes that we had to do our application:

• change JNDI names to EE 6 standardized names
• migrate from JBoss Cache to Infinispan (part of our code has been migrated to the flat API, some parts still use the tree API)
• security is slightly less flexible (you can no longer fix authenticated and unauthenticated calls)
• some horrible code that relied on details of remote JNDI
• the configuration of the EJB client is different
• all of you scripts for installing, deploying, starting, stopping, …
• ExternalContext is gone, we had to replace it with a different approach
• we replaced MBeans in SARs with @StartUp EJBs
• some ugly hacks for Cocoon

The AS 7.x series has a lot of bugs with fixes only available in the EAP series. If you want go to with 7.x instead of 8.x we strongly recommend you buy EAP 6.