< Magazine />


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

Sunday, November 21, 2010 by Carsten Hufe   Tags:  application   jboss   server   tomcat 

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.

Conclusion

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
 

Follow me on Twitter

Friday, November 12, 2010 by Carsten Hufe   Tags:  devproof   twitter 

You can follow me on twitter http://twitter.com/devproof and get the newest status updates.

Planned features for the next Devproof Portal release

Friday, November 12, 2010 by Carsten Hufe   Tags:  devproof   portal 

There are a lot of new features for the next release of Devproof Portal.

  • Historization and versionizing for content, e.g. for blog and articles
  • More mountable urls for one article and make it changable
  • A lot of technical stuff:
    • Default spring transaction handling, no transaction per request anymore
    • Full spring annotation support
    • Better module scanning
    • Mount pages by annotation
    • Find generic repositories by annotation
    • An own spring namespace to define a new module
    • Switching from Maven to Gradle

Here are some samples:

Sample for a module definition in spring:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:devproof="http://www.devproof.org/schema/devproof/portal"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.devproof.org/schema/devproof/portal
        http://www.devproof.org/schema/devproof/portal-1.1.xsd">
    <!--
      This scans the Devproof components (pages, entities and generic repository) 
      and does the same as <context:component-scan/>
   -->
    <devproof:module-scan
            base-package="org.devproof.portal.module.blog"
            module-name="Blog"
            author="devproof - Carsten Hufe" author-url="http://devproof.org"
            module-version="1.0" portal-version="1.0"/>
</beans>

Sample for a generic repository definition:

@GenericRepository("blogRepository")
public interface BlogRepository extends CrudRepository<Blog, Integer> {
    
    @Query("select b.allRights from Blog b where b.modifiedAt = (select max(modifiedAt) from Blog)")
    List<Right> findLastSelectedRights();
}

Sample for mounting a page:

@ModulePage(mountPath = "/blog", registerMainNavigationLink = true, defaultStartPage = true)
public class BlogPage extends BlogBasePage {
 // some code
}

The next release takes a bit more time. Hope you will enjoy the changes.

Release: Final Release 1.0.0 is out

Saturday, July 17, 2010 by Carsten Hufe   Tags:  devproof   portal   release 

The final release 1.0.0 of Devproof Portal is now available. Here is a short overview of the changes:

  • Final Release, no critical changes
  • Several exception fixes
  • Enable caching statistics by default
  • pom.xml cleanup, removed the redundant stuff
  • Tomcat version updated to 6.0.28

Getting started: Devproof Portal with Tomcat 6

Overview: Devproof Portal

Enjoy the final release smiley

Moved the source code to Github

The source code of Devproof Portal is now available on Github. Some weeks ago I decided to move the source code to a distributed revision control system. There were to candidates: Git and Mercurial.  I decided in favour of Git, because I only know people who are using Git. It seems to be more popular than Mercurial (see Google Trends and compare Github with BitBucket). Furthermore Git is faster and more flexible.

Please visit Devproof on Github

# Create a clone from Github
git clone git://github.com/devproof/portal.git devproof

If you like, you can fork the project.

For the hardcore SVN users, you can still use it:

# Checkout from SVN
svn checkout https://svn.github.com/devproof/portal/ devproof

The source code from Google Code SVN has been removed, but the Google Code Project Page (incl. Bug Tracker, Downloads etc.) is still active!


© 2009-2012 - www.devproof.org