GlassFish Vs. JBoss

GlassFish and JBoss Clarify Lifecycles After Accusatory Comment

Jessica Thornsby
GlassFish-and-JBoss-Clarify-Lifecycles-After-Accusatory-Comment

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.”

Author
Comments
comments powered by Disqus