Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Abandon Fish! Migrating from GlassFish to JBoss or TomEE

Chapter II: Migrating your application ecosystem from GlassFish

What are GlassFish users supposed to think–as well as plan–for the future in light of these changes? Will you be patient or pragmatic…or both? In this chapter, we discuss migrating your application code and DB/datasource elements.

How did we choose TomEE and JBoss as options for GlassFish users?

When GlassFish 4 was released, many users were planning to migrate their applications from GlassFish 3 to get advantage of all benefits brought by the Java EE 7 specifications. But now, they have been forced to plan a migration effort towards a different application server instead, pushing the excitement about using Java EE 7 away for now.

GlassFish users are probably facing the following options:

Pragmatism Patience
Meaning Find an alternative to the GlassFish 3 web/full profile and postpone the plans to migrate to Java EE 7 Leave things alone for a while and start evaluating alternatives to GlassFish 4
Why? You’ll probably want to start a relationship with another support team as soon as possible to eliminate all lock-in features and avoid a hurried and risky migration in the future. They will focus all their attention on the migration and stop thinking about Java EE 7 for a while. If you believe your apps are not that locked-in, you’ll want to increase productivity and reduce app complexity, thus it’s ok to stay with GlassFish for a while and postpone the migration opportunity towards an application server that already supports Java EE 7.

At this point, you might may face yet another dilemma: do you continue relying on OSS, or move to a proprietary solution?

Glassfish is an open source software and it is certainly a reason why people decided to use it. These people are probably looking for an open source alternative because they need full transparency, have a lower budget and are able to improve the product if they can to.

Some of you don’t care if the application server is open source or not. You might fear that other open source options will end up like GlassFish, with no long-term technical support for subsequent releases. The lack of transparency and budget are not a problem for them either, and they hardly would have time to look at the code to find the root cause of the problem.

We can combine the options above and identify alternatives for each combination. The following table shows potential candidates to replace your Glassfish installation based on the options above:

Stay using Java EE 6 Also move to Java EE 7
Open source
TomEE 1.6, JBoss EAP 6
WildFly 8 *
Proprietary
WebLogic, WebSphere

* Red Hat doesn’t offer technical support for WildFly yet.
 
It is true that there are many other alternatives out there, such as Jetty, Resin, Geronimo, JOnAS and more; however, we have decided to limit our focus to the tools mentioned above due to the following reasons:

  • The vibrant developer community around these tools, namely JBoss and Tomcat
  • The amount of documentation available on the web
  • The sponsorship and support by market leaders


Open Source options with commercial support – TomEE and JBoss

If you want to stay using Java EE 6 for a while and keep trusting on open source software, we suggest TomEE 1.6 and JBoss AS 7 / JBoss EAP 6 as alternatives to GlassFish.

TomEE is a bundle of Apache implementations of the Java EE 6 specifications. It’s a relatively new product in the market, but it profits from Tomcat’s maturity, making it reliable and competitive. TomEE recently got Java EE web profile certified, which reduces the need for application changes when migrating from another certified product, such as GlassFish. Its official support is provided by Tomitribe, the company started by David Blevins in 2013, who engaged several TomEE committers to interact directly with customers.

Red Hat has a very similar business model. Like TomEE, they offer official support for customers using products under the JBoss brand (i.e. JBoss = JBoss EAP and WildFly, formerly JBoss AS), which has a mature and established codebase. Among the above-mentioned, JBoss also has the largest installation base, documentation and a huge community. They are very competitive–indeed, our own Great Java Application Server Debate awarded 1st place to JBoss–but it doesn’t mean they are competition killers.

As part of Red Hat, they seem to have become slower to respond and more bureaucratic over time as they grow, a syndrome that attacks most growing IT corporations. The much-smaller and more agile Tomitribe is far more efficient in terms of decision making and response time, but cannot compare with resources. At least, that was our perception when we contacted both companies to request a offer for support and training.


Proprietary options – WebLogic and WebSphere

Outside of the open source world, you find WebLogic and WebSphere as the two main proprietary players, provided respectively by Oracle and IBM. These companies have large developer bases and equally large contracts. In terms of service agility, we can apply the rule “the bigger you are, the slower you move”. It means their support works according to the agreed terms, but it might take more iterations to finally get a solution to the issues.

There is a very low probability that you are going to talk directly with a WebLogic/WebSphere committer (one of the people in charge of programming the application server), which is the opposite case with TomEE and, to some extent, JBoss. On the other hand, WebLogic and WebSphere have much more means to invest into their products for achieving higher levels of reliability, stability, optimizations, vendor support, HW/SW cost efficiency, and so on.

Oracle is tempting users with a claim that the easiest path away from GlassFish is directly to WebLogic, since it supports GlassFish’s deployment descriptors and share some of the libraries already.

However, the open source alternatives already support those deployment descriptors as well and JBoss also shares most of those libraries too. Therefore, the most logical decision when migrating from GlassFish is opting for an equivalent open source alternative. That’s why we have decided to explore only the technical details of JBoss and TomEE in the following sections.


Download the PDF

  • JL

    I hope you can have support for TomEE with LiveRebel, i use TomEE but liverebel dont support it.

  • Hi JL,

    I wish we could support most of the popular application servers out there. Right now we are looking if we can support Weblogic and Websphere for example. Yes, these are still missing from our offering.

    I know that TomEE is not in the LiveRebel roadmap for this year but if there is enough interest we can re-prioritise the roadmap. Now this will depend on the market. We’ll live and see!

    Toomas

  • henk53

    Nice report! I have a few small comments:

    >The JNDI name on JBoss is also different from Glassfish. You need to append the prefix java:/or java:jboss/, resulting in java:/jdbc/appds or java:jboss/jdbc/appds respectively.

    OR… you could just use the standard java:global or java:app namespaces AND you could make use of the Java EE standardized datasource definition. See:

    http://henk53.wordpress.com/2012/04/#step10
    http://henk53.wordpress.com/2012/06/30/the-state-of-datasourcedefinition-in-java-ee
    http://smokeandice.blogspot.com/2009/12/datasourcedefinition-hidden-gem-from.html

    >Both WildFly and JBoss EAP have implementations of JSF based on Mojarra,[…]

    This is not entirely true.

    The above seems to assume that JBoss has a modified Mojarra version, but JBoss HAS NOT modified Mojarra! The version of Mojarra they package is identical to the released binary. They only thing they do is build it from source themselves, which necessitates splitting it into the API and implementation parts. The jars that Mojarra releases are optionally available with this split, but for the source you have to do this yourself. Other than some line endings (Unix/Windows) which are automatically corrected by their build tool, the source is 100% identical. See https://github.com/jboss/mojarra

    Even without the multi-jsf feature you could always just replace the mojarra jars inside JBoss with a different version and this has always worked.

    They do have some integration code for JSF that is JBoss specific, but this just implements the required JSF SPI (see the spec document). Every AS has to implement that, and for JSF it’s a relative small amount of code. CDI also requires a SPI to be implemented and it’s much bigger.

    To my knowledge the only server that ships with a modified JSF version is Liberty, which ships with an (antiquated) modified MyFaces 2.0.Ancient version.

  • ide

    And now NetBeans has be scuttled but this move won’t be announced.

  • Yannick Majoros

    For my part, I see no reason to trust jboss devs more than oracle on fixing bugs. In fact, the latter needs to keep going on to be able to provide a Java EE 8 reference implementation.

    I migrated to GF4 / Java EE 7 as soon as I could, and that’s always more difficult with jboss. Wildfly is just out, GF4 was released back in june last year and had been in continuous development for years.

  • Esteban

    JBoss EAP 6 is Open Source but you have to get a subscription (you have to pay money in other words) for using it in a Production environment.