Home > java, java ee > The curious case of JBoss AS 7.1.2 and 7.1.3

The curious case of JBoss AS 7.1.2 and 7.1.3

At the moment of writing, JBoss AS 7.1.1 is the latest version of JBoss AS that can be downloaded from their usual download page.

This release is nearly 1 year old, and contains quite a lot of really serious bugs. There is a JBoss AS 7.2 in the works, but since not even an alfa, milestone or beta version has been put on the download page, it might not be unrealistic to surmise a release of that is still at least some time away. For JBoss AS 5 it took over two years (2006-11-17 to 2008-12-05), for JBoss AS 6 one year (2009-12-02 to 2010-12-28) and so on. Although for smaller releases the time is typically shorter, e.g. 7.1 was just below three months (2011-11-22 to 2012-02-16).

JBoss AS 7.2 will undoubtedly fix many of the open bugs in 7.1.1, but because it will contain many exciting and fancy new features, it will almost surely also contain many not so exciting new bugs.

So, why doesn’t JBoss just fix a bunch of bugs in 7.1.1 without introducing any new features? Why isn’t there say a JBoss AS 7.1.2, 7.1.3 etc. Why do we have to wait so long for a new version only to get more new bugs?

Well, actually, this is exactly what they do. There is a 7.1.2 and 7.1.3 in which an enormous amount of bugs are fixed. The only thing is, those aren’t put on the regular download page, but on a ‘special’ download page that’s behind a login. Oh, and to make it kind of look like it’s another product the name is changed from JBoss AS to JBoss EAP and the version numbering is changed as well. 7.1.2 becomes 6.0.0 and 7.1.3 becomes 6.0.1. The WTP server runtime offered by JBoss Tools also plays this game along and puts the runtimes for those EAP builds under a different category. So with the “JBoss 7.1 Runtime” you can start JBoss AS 7.1.0 and 7.1.1, but for something that’s effectively JBoss AS 7.1.2 you need the “JBoss EAP 6.0 Runtime”.

Downloads are available from access.redhat.com/downloads, from which you have to click on “Evaluations and Demos”, and then on “JBoss Enterprise Application Platform Evaluation”. The download of the actual Application Server can then be found all the way at the bottom, called “Application Platform 6.0.1” in the case of JBoss AS 7.1.3 (aka EAP 6.0.1). There is a direct link, but it probably won’t work directly as you have to accept an evaluation license first.

But wait, evaluation license? Doesn’t that mean this is a derivate that’s not open source anymore? As it appears, this is not the case. These EAP builds are still fully open source, and a source archive is even provided as a download from the same page. But despite the fact that it’s still open source, the binary build cannot be used freely. I’m not a lawyer, and thus it’s a bit difficult to understand how this can be true. How something can be a derivative of a fully open source product, be a fully open source product it self, but still can not be used freely. Undoubtedly JBoss has this legally covered, but for a simple user such as myself it’s not easy to understand.

There is a large discussion about this on the JBoss community forum and Jason Greene (project lead) goes to great lengths to explain the situation, but a lot of questions remain. One way around the restrictions imposed by the evaluation license is to build the code from source:

Jason Greene:

Self build and support EAP – You get some of the benefits of the enterprise releases (e.g. patches to older major versions and so on), but you have to invest time and energy to build and maintain/verify your app server distribution bits.

However Rich Sharples remarks:

Right now we do not have a way of making EAP easily buildable for the general public (nor does the L-GPL or GPL require us to)

Until thus far this situation has not been resolved. One detail that comes up often is that EAP provides patches for “older” releases. In that thinking, if you want the latest and greatest you can get the community edition (AS), and if you want stability and accept older functionality, then you can buy the enterprise version (EAP). However, for nearly a year now, the EAP version is the latest and greatest. The last community release as mentioned is 7.1.1, so for all intends and purposes, the EAP versions corresponding to 7.1.2 and 7.1.3 are both the latest and greatest as well as the most stable release.

But about how many bugs are we exactly talking? Is all of this really worth the trouble? Let’s take a look.

There were 400 bugs fixed for JBoss AS 7.1.2.Final.

Then there were some 234 fixes for JBoss AS 7.1.3.Final.

Additionally there are even more fixes done. Namely, the mentioned 7.1.2.Final and 7.1.3.Final are just tags in the JBoss AS repository. This tag is presumably cloned into another repository, and there more fixes are done. Eventually, 7.1.2.Final became 7.1.2.Final-redhat-1 when it was released and 7.1.3.Final became 7.1.3.Final-redhat-4. Those additional fixes are mostly publicly tracked. Mostly, because there seems to be some tracking going on at restricted pages.

For 7.1.2.Final-redhat-1 there are 40 issues mentioned.

For 7.1.3.Final-redhat-4 there are 36 issues mentioned, but there are 3 intermediate versions with 126, 34 and 86 issues fixed.

Of those additional issues, further complicating the AS/EAP split is that an amount of them are direct clones from issues in the JIRA for AS. Those start with the word “CLONE”.

In total we have thus at least 634 fixes, and then some estimated 150 additional fixes (guessing the overlap is about 50%). So this are approximately 750 fixes, among which are some that are just by themselves a blocker for using JBoss AS 7.1.1 (depending on your use case). It thus definitely seems to be worth it to go for the 7.1.3 release instead of the 7.1.1 one.

Even though the EAP builds are open source and have their source available for download, there doesn’t seem to be a public repository for those ‘additional fixes’. The 7.1.2.Final and 7.1.3.Final tags however are directly accesible on Github. Since those are just tags, and not actual releases, there are no artifacts available for them in a Maven repository. For the EAP builds, there is as mentioned above no source repository available. Instead there is a public FTP server where the source is hosted (this is the same source as is also available as an archive from the restricted download page). Additionally, there is a Maven repository. There is the following somewhat disheartening disclaimer though at the root:

Red Hat reserves the right to modify the behavior and content of this repository or remove it completely with little or no notice.

The question after all of this is though, why does JBoss do all of this? Why does it hide the releases with bug fixes and why does it try so hard to keep up the illusion that JBoss AS and JBoss EAP are two completely different products?

The answer as stated in the above referenced forum discussion is that it mostly has to do with monetization. JBoss as any other company does have to pay its developers. Even open source developers of course need to be able to buy food at the end of the day. The thinking goes that if all binary builds were freely available, then less people would be inclined to buy a support contract. The support contract not only provides you with support, it also gives you access to the binary builds without the restrictions as opposed by the evaluation license. So with this setup, JBoss benefits from open source in that a lot of people from the community are able to report bugs with a detailed analysis of where things go wrong in source, possibly even with patches attached that fix said problem. Simultaneously they also, kind of, benefit from the closed source model, where you can charge customers for the software itself.

It’s undoubtedly a difficult balance, since as said even the restricted JBoss EAP builds are still open source and JBoss remains an open source company. The split between AS and EAP must eat away at least some resources as well. The clone into another repository, the merging of changes done there back to the mainline, keeping duplicated (cloned) issues, creating Eclipse server runtimes that are nearly identical, a separate Maven repository, etc etc.

Personally I wonder if in the end all of this is really worth the trouble. Why not just release every version as “JBoss AS”, put every version on the public download page, and then offer a support contract independent of access to the binary builds. If it’s really needed, some versions could be tagged as being specifically allegeable for support. Just like Canonical does with Ubuntu. Every version is freely downloadable and support can be bought separately. Some versions are supported for a longer time and get the “LTS” tag.

At the very least, JBoss could probably do a better job in advertising that there even is a 7.1.2, 7.1.3 etc available that are bug fix releases. I’ve been a JBoss user for some time and it wasn’t after some years that I finally discovered what was going on with EAP. Before that I just thought that EAP was the name of their support program. I literally had no idea that there were entire series of JBoss releases that were only available via EAP and thus didn’t appear on the public download page.

Categories: java, java ee
  1. Rupert
    January 10, 2013 at 9:56 am

    Very informative!

    An alternative explanation is that Red Hat only creates EAP releases that are commercial. Just like Apple and Microsoft they have a public beta program.

    Jboss 7.0 is then actually EAP 6 beta 1, 7.0.1 is beta 2, 7.1.0 is beta 3 and 7.1.1 is rc 1.

    With every potential beta or rc release the current status is assessed. If another round of community testing is deemed to be necessary then the beta or rc appears on the public download page, otherwise no public build is made and within a short period a commercial GA release is made.

    If you’re only using the Jboss releases from the public download page, you’re always using a beta/rc and never a final.

  2. January 14, 2013 at 8:03 pm

    Even worse for them… when I saw that the EAP versions were always one behind, I interpreted that as meaning that it took them a dog’s age to commercialize a version. It never occurred to me that the version numbers didn’t correspond.

  3. January 16, 2013 at 9:26 pm

    Very nice post.

    After reading it, I just wanted to try to build EAP 6… Here’s my attempt : https://github.com/hasalex/eap-build

    • February 18, 2013 at 8:08 pm

      It seems like a very solid attempt!

      I noticed the changes were mostly necessary in the tools used to build EAP 6, not the actual libraries that make up EAP (the fallback version of Hibernate 3 seems one the main exceptions, but it’s only a fallback, not the main version).

      What do you think, will those slightly different tools really generate a “somewhat” different version of JBoss EAP?

      • February 18, 2013 at 9:06 pm

        Oh yes, the result is not really far from the goal. The differences in the result is Hibernate 3, SLF4J and Byteman.

  4. me2
    February 14, 2013 at 9:48 pm

    Alexis, you should totally make a JBoss CentOS distro out of this.

    • February 18, 2013 at 8:05 pm

      Me2, A distro is one step more. I’m not a lawyer, but I’m pretty sure that a distro absolutely necessitates removing the RH trademark. See this article on Wikipedia: http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux_derivatives

      • February 18, 2013 at 9:04 pm

        Hey, a CentAS distro !
        Seriously, a distro would be a hard work to maintain, and bring much less value to the community than an AS version very close to the EAP one.

      • struberg
        September 8, 2013 at 5:55 pm

        well, the problem with the distribution fork is not a JBoss one but a JavaEE Sun/Oracle issue.
        Publishing an official release of a Java EE server requires that you pass the full JavaEE TCK suite. And those bits are pretty costy. Of course Oracle grants TCK licenses for free if they agree that the project is OSS for public good – but it’s up to them to if they like it or not. There is no guaranteed right that you will get it.

        What basically remains is a kind of gentoo approach or to buy EAP – or use another JavaEE server like TomEE, Glassfish, etc .

        PS: I think jbossas7 is actually pretty ok technically. At least compared to JBoss5 and 6 which were pretty much a disaster imo.

  5. February 18, 2013 at 8:09 pm

    p.s. See this for another post about this topic: http://blog.kaltepoth.de/posts/2013/02/12/building-jboss-as7.html

  6. Frederic Filiatrault
    March 7, 2013 at 8:48 pm

    Great article! It finally made sense with all I was searching on the web. Actually, Red Had should hire a marketing guru to help them out.

    Having an higher release number in the community which is about 1 year old, compared to the newest EAP release which have a LESSER releaser number. Great call guys…

  7. September 18, 2013 at 11:51 am

    struberg :

    well, the problem with the distribution fork is not a JBoss one but a JavaEE Sun/Oracle issue.
    Publishing an official release of a Java EE server requires that you pass the full JavaEE TCK suite.

    Sure, such a fork additionally couldn’t be called Java EE then, at least not easily.


    struberg :

    I think jbossas7 is actually pretty ok technically. At least compared to JBoss5 and 6 which were pretty much a disaster imo.

    I personally didn’t like the particular version of JBoss AS 7.1.1, as it contained many bugs. Maybe the majority of the bugs where just in functionality that I happened to use, and it works pretty good for others. From an architectural point of view the AS 7 series is much lighter and faster to startup. Both AS 5 and 6 were said to be faster than AS 4, but in practice were much slower, especially when starting up. A medium size app (100k loc) took nearly 2 minutes to startup on the fastest hardware of the time.

    In the meantime JBoss has clarified a lot, but self-building remains an issue. Although they themselves deny it, I can’t escape the feeling that they sabotage the build scripts on purpose to make it more difficult to build EAP our selves.

  8. glassfish better
    October 8, 2013 at 4:11 pm

    Glassfish \o/

  9. Jim
    October 25, 2013 at 10:39 pm

    Nice to see this confirmation of the journey my team made as well. We needed a solid stable release of 7, liked all the things it did right but couldn’t find a bugfix version. We built it from tags in github once we understood the approach, but I agree it just seems like it’s making it extra hard. Glassfish is always an option,..

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: