Why the use of JBoss AS is a high risk in projects

Posted in jee with tags jboss jee -

For a half year I have worked with the JBoss 5.1 application server and I have got some experience with it. JBoss 5.1 seems to be a beta, but is labeled as final release. It has a lot of well-known bugs that are not fixed yet. One example is the classpath resource loading, which caching mechanism has a critical bug. After the cache timeout, the elements does not get evicted and the cache gets bigger and bigger. The result is the OutOfMemoryException. Till now the solution is to set the cache timeout very high. If you use Apache Wicket, you will get this problem very fast.

JBoss 5.1 uses the Apache Tomcat 5.5. So I think this is the only usable and required component of the whole application server. I don’t know the exact version of Apache Tomcat in JBoss. The latest JBoss 5.1 was released on 23th May 2009. From this date, there have been four releases of Apache Tomcat 5.5 with over 180 solved issues. Assume there are just a few security issues which are unfixed. These security issues are not fixed in JBoss, but the issues are well-known. That is a very high security risk. You are forced to use obsolete libraries. This affects the Apache Tomcat, Hibernate and more. I know you can replace the hibernate version, but this can cause other behaviour and side effects. Furthermore development on JBoss is very expensive compared to Apache Tomcat (with a Spring application). Why? Assume we have an application and we will deploy it on Apache Tomcat and JBoss. In JBoss the application startup takes 70 seconds and in Tomcat just 8 seconds on my machine. This will stretch the development turnaround. The JBossAS tools for Eclipse with its incremental deployment support are not an option. JBossAS tools are very buggy too and you need a lot of luck to get a working version. We tried to use JBoss in combination with JRebel (a hot code replacement extension for Java), but this results after a very short time in an OutOfMemoryException. Next point: JBoss comes with a lot of stuff which the most users do not need and know. This makes the configuration of JBoss very complex. Most people do not know all configuration possibilities. This can cause security and operation problems. Apache Tomcat is lightweight. It is easy to configure. You just add the features and libraries you need. Less features leads to less configuration and a minimization of security and operation issues. This minimizes the technical risk. The JBoss deployment is not deterministic. When I deployed the same EAR file on the same application server, it does not work on every deployment. Mostly it worked, sometimes not. The reasons are not transparent, because JBoss additionally has very bad error messages.

Such randomly occurring behaviours and bad error feedbacks in combination causes a very stretched development turnaround and costs a lot of time and money. My experience is to spend 3 of 20 days on such things. On top comes the additional administrative effort through its complex and extensive configuration.

Here is the current release situation of JBoss:

  • JBoss 5.1 final, but quality is beta and it is not production ready yet
  • JBoss 6.0 Milestone
  • JBoss 7.0 Alpha

Currently there is no usable final release. They are working on new releases, but have not fixed critical issues on its „final“ 5.1.


There is no benefit using JBoss. Far from it! It just provides technical risks and a slower development turnaround. Instead I recommend to use a plain Apache Tomcat with the Spring application framework or an embedded EJB container. So you have a lightweight, easy to use and well-known web container. You have the full control over frameworks and libraries. At least you can get new releases of the Apache Tomcat directly and react on security issues very fast.

Update Nov 21th 2010: The stuff described above is just my own opinion and experience. Here is a link which describes the JBoss product lifecycle in detail: http://blog.softwhere.org/archives/1035

Written by Carsten Hufe
Older article
About the author