GlassFish Vs. JBoss

GlassFish and JBoss Clarify Lifecycles After Accusatory Comment

Jessica Thornsby

Release of GlassFish 3.0.1 Patch 1 sparks controversy as JBoss accuses Oracle of descrediting them.

GlassFish and JBoss have both been drawn into a lifecycle debate, over a single comment posted at the announcement of a commercial patch for GlassFish. GlassFish 3.0.1 Patch 1 is a commercial (restricted) patch release for GlassFish 3.0.1, and its release caused visitor S. Ali Tokmen to question whether GlassFish planned to split their efforts between an open source branch with few releases and no corrective versions, and commercial versions which fix critical issues – “just like JBoss.” The GlassFish team replied by clarifying that the base of the commercial and public releases will be the same, but the commercial version will contain additional (IPS) packages. Furthermore, the fixes that appear in these releases will be integrated back into the next public release. They did not offer a schedule for the public releases, as “it will vary depending on many factors.” The team do acknowledge that Oracle GlassFish Server does have closed source AddOns, unlike JBoss, but if you do not wish to use these AddOns, then you simply do not buy them.

The Director of Product Management for JBoss Application Platforms and Developer Tools, Rich Sharples has posted a blog that accuses Oracle employees of attempting to “discredit JBoss” with their reply – which included a link to an unflattering blog post concerning JBoss. He then attempts to clarify the relationship between the upstream projects JBoss utilises, and the downstream products it supports. For every Red Hat product, there is at least one upstream open source project. Rich Sharples is enthusiastic about these upstream open source projects, calling them “where the innovation happens.” He perceives them as “technology incubators” that focus on “agility, speed, innovation.” The downside is that any given release may not be suitable for running business critical applications, which is actually stated on the JBoss website. The JBoss Community is referred to as “community driven projects featuring the latest innovations for cutting edge apps.” By contrast, the JBoss Enterprise section is defined as “stable, supported products certified on multiple platforms for mission critical applications.”

When it comes to moving a community release into a platform release, there is a “productization” process, which was seen recently when JBoss AS 5.1.0 essentially became the Alpha Release for JBoss EAP 5. This process included refining the dependencies, removing duplicates and performing testing that went beyond the previous community testing, focusing on areas such as scalability, security and longevity. There is also a traditional Early Access Program. “The result of this process is an Enterprise Platform GA that differs from the upstream binary release we started with,” says Rich Sharples. Fixes are made available upstream and will eventually make their way into upstream binary releases, but the upstream project cannot guarantee that these fixes will be isolated from more substantial changes. “Community releases typically don’t distinguish compatible bug fixes from more intrusive changes that provide the innovation.”

Rich Sharples’ conclusion is that you should examine your goals before deciding on a JBoss solution: “if you want to deploy your business critical applications and receive long term support from Red Hat then the JBoss Enterprise Platforms are what I would recommend – if you’re more interested in seeing how those platforms will evolve and more interested in emerging technology but willing to take on more risk then upstream projects are where you should be looking.”

Inline Feedbacks
View all comments