Migrating From Glassfish to Jboss Tomee

1All rights reserved. 2014 ZeroTurnaround O

MIGRATING FROM GLASSFISH TO JBOSS OR TOMEEABANDON FISH!

So long, and thanks for

all the fish!


CHAPTER IV GETTING THE REST OF YOUR ENVIRONMENT BACK ONLINE (REPOSITORY, IDE, CI SERVER AND FRAMEWORKS) 19-28

TABLE OF CONTENTSCHAPTER IA LITTLE HISTORY OF GLASSFISH 1-4

CHAPTER II MIGRATING YOUR APPLICATION ECOSYSTEM FROM GLASSFISH 6-14

CHAPTER III SETTING UP YOUR JAVA EE SPECIFICATIONS/ IMPLEMENTATIONS: EJB, CDI, JSF AND JPA 15-18

Click to goto section

CHAPTER V SUMMARY, CONCLUSION AND GOODBYE COMIC ;-) 29-31


CHAPTER I: A LITTLE HISTORY OF GLASSFISH

"However this announcement and Oracle's 'optimizations' is the perfect opportunity for other vendors like TomEE (with commercial support by Tomitribe), Wildfly (supported by Red Hat) or WebSphere Liberty Profile (supported by IBM), to step in."

ADAM BIEN, In his Blog


From caviar to great white shark

Officially, the tool we all know as GlassFish is really GlassFish Open Source Edition, which is Oracles GPL/CDDL-licensed Java EE application server.

GlassFish came a long way, starting as a Sun Microsystems Inc. project back in mid-2005. It was based on the source code for the Sun Java System Application Server (SJAS) PE 9, which was donated to the community by Sun Microsystems along with Oracles donation of TopLink persistence code. The joint goal was to encourage communication between Sun & Oracle engineers and the community, enabling all developers to participate in the application server development process along with the JCP.

With this donation, developers from all over the world could access source code, nightly builds, discussion groups, and mailing lists. For the very first time in history, developers were able to meaningfully contribute to the application server development process.

Historically, GlassFish has always been backed up by a commercial distribution. Initially named SJAS, it became Sun GlassFish Enterprise Server with the Version 2.1 in mid-2009. At the end of the same year. Sun released the first Java EE 6 compatible version carrying the famous v3 as the version number. It contained the completely rebuilt OSGi foundation created on Apache Felix and delivered an awesome developer experience by cutting down startup-times, providing hot-deployment and preserving http sessions across development redeployments.

GlassFishs main competitor back in the day was the extremely lightweight Apache Tomcat. Developers got attracted to both the new Java EE 6 specification, which finally improved development productivity and ease of use, establishing convenient handling and administration as well. All this happened a year and a half after Oracle completed its acquisition of BEA Systems.

With increasing uptake on Java EE technologies, GlassFish became a solid alternative for even the most attractive and performant commercial application servers. Leading the field by continuously delivering technical innovation and driving specifications on the JCP had always been BEA Systems with their WebLogic server, but the release of GlassFish 2.1 was in more or less direct competition with Oracles and IBMs WebSphere product line. But GlassFish was for free. And much faster.

What? A free, faster competitorto Oracle and IBM?

The release of GlassFish 2.1 was in more or less direct competition with Oracles and IBMs WebSphere product line. But GlassFish was for free. And much faster.


Oracle buys Sun MicrosystemsThe famous Oracle-Sun merger in early-2010 changed the rules. The GlassFish community was afraid of Oracle cutting off GlassFish completely in favor of the commercial WebLogic product they just recently integrated as their foundation for almost all commercial products. But basically nothing happened. Aside from a bunch of extra marketing and re-naming efforts for both the OSS and the commercial edition, pretty much everything else remained the same.

It had seemed that Oracle wanted invest into their new assets by putting up the so called 100-day releases with patches for both 2.1 and 3.0 versions. Unfortunately, this was followed by nothing groundbreaking. The 3.1.0 - 3.1.2 releases brought clustering back to the 3.x branch and delivered on long-overdue component updates and fixes in early 2011.

In mid-2012, a micro-release 3.1.2.2 fixed a handful of exceptional issues. No further updates took place until June 2013, with the initial release of GlassFish 4.0 being the reference implementation of Java EE 7. The community stood behind GlassFish the whole time. The NetBeans bundle, the unzip and start packages, the comparably good startup times and the overall availability of examples and documentation made GlassFish the #1 choice not only for beginners but also for people running real applications on it.

Starting in November 2013, things began going downhill for GlassFish. Oracle announced that they were cancelling the commercial supported version and that there will not be an Oracle GlassFish Server 4.0. This essentially means that GlassFish stays the reference implementation for subsequent Java EE versions, but isnt seen as a commercial offering for customers.

There are various interpretations of this announcement. Common sense would dictate that given the actual setup of the GlassFish open source project and the remaining scope as a reference implementation, it is not going to be a fully-competitive app server anymore. The major point of the criticism is that it basically isnt easy to contribute to the open source project. Compared with other leading frameworks (i.e. Spring) or app servers (i.e Tomcat) which have a vital community around them, the hurdles put in front of GlassFish are pretty high.

Also, the steps required to become a contributor (e.g. signing the OCA, finding peers to review patches) are only one reason. The fact that the project uses a comparably outdated infrastructure without todays expected features, nor a user-experience like Github provides, makes it even harder to attract developers.

Oracle pulls commercial support


Transparency is probably another issue. Beside being closely tied to future Java EE releases, there is no clear vision for features and developments beside the scope of the umbrella specification.

Even if GlassFish stays the ideal way to learn the latest Java EE features and build the first applications using them, it will be hard to trust it for production because nobody knows if, when and how bug-fixes for reported issues might find their way into the code-base.

Whew. So, theres more going on here too. Did you realize that there are a bunch of value-added features provided by every application server which are not covered by any specification? Clustering features are probably the most prominent example. Talking about administration features or adding new supported data sources or other products makes it even harder to imagine that GlassFish will stay the first choice without having a commercial payout for Oracle and without laying the ground for a vital community to deliver patches and contributions. So if we assume that Oracle is just moving slowly and things will keep moving in the right direction, there is still another complex set of questions to be answered. Both GlassFish and WebLogic share a bunch of components (Jersey, Tyrus, etc.) and proposed community changes might potentially interfere with the needs of a future WebLogic product visions. This would require either a real product management team, some kind of extension points or much-increased transparency on the project management level. We think you can judge on your own how likely you think these things might happen.

Ok, enough with the history, lets talk about the future! In upcoming chapters, youll see how to migrate your application and DB connections and datasource, plus what to do now with your Java EE implementations of EJB, CDI, JSF, JPA, plus all the changes youll need to make to your repositories, IDE, Continuous Integration server and frameworks. Go!

Other barriers to the longevity of GlassFish


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:

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

PRAGMATISM PATIENCE

MeaningFind 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?

Youll 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, youll want to increase productivity and reduce app complexity, thus its ok to stay with GlassFish for a while and postpone the migration opportunity

towards an application server that already supports Java EE 7.


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:

* Red Hat doesnt 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. Its a relatively new product in the market, but it profits from Tomcats 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 doesnt 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.

STAY USING JAVA EE 6

ALSO MOVE TO JAVA EE 7

Open source TomEE 1.6, JBoss EAP 6 WildFly 8 *

Proprietary WebLogic, WebSphere -


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 GlassFishs 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. Thats why we have decided to explore only the technical details of JBoss and TomEE in the following sections.

But...if you really wanted to implement an expensive WebLogic or WebSphere installation, you probably would have done it already!


You next app server: Installing JBoss and TomEE

Anyone who wants change in the market should support TomEE. Not because it's better than JBoss, but because we need another Red Hat. Another strong open-source vendor in there alongside Red Hat can change the market. It's currently a two against one scenario, with Oracle and IBM challenging Red Hat--though adding TomEE to the mix makes an even strong combination.

DAVID BLEVINS, creator of TomEE and Tomitribe

The good new for us, being the intelligent, community-supportive, good-looking developers that we are, installing TomEE or JBoss is nice and straightforward: to get TomEE and JBoss up and running it's enough to download the zip file, unzip it on your machine and run one of the files in the bin folder.

Well leave the decision about the best location to install it up to you, since it depends on the operating system, the server configuration and personal preferences. At this time, its best to ensure you stopped Glassfish and any other application server(s) to avoid TCP/IP port conflicts.

INSTALLING TOMEE (ACTUALLY, WERE USING TOMEE+)Did you just see a + attach itself to TomEE? This is because we assume you are migrating from Glassfish full profile, not only web profile. So, download the TomEE+ (plus) installation package, available at http://tomee.apache.org/downloads.html and unzip it in a place you can easily remember. Create the environment variable $CATALINA_HOME pointing to the exact location where you unzipped TomEE+.

Check if it's correctly installed starting the server with the command:

Windows #> %CATALINA_HOME%\bin\catalina.bat runUnix #> ./%CATALINA_HOME%/bin/catalina.sh run

You know when the startup finishes when you see the following message:

INFO: Server startup in 1344 ms

Open a web browser and access the url http://localhost:8080 to see the TomEE+ welcome page. We still have to create an admin user to be able to operate the admin console, and unlike Glassfish, TomEE+ comes with no user defined. Go to %CATALINA_HOME%\conf and edit the file tomcat-users.xml. You find at the end of the file the default security configuration for TomEE+. You just have to uncomment those lines to make it work:

According to the configuration above, you can authenticate within the application manager using the username tomee and password tomee.


INSTALLING JBOSSDownload the latest installation package from http://www.jboss.org/jbossas/downloads. In case of JBoss, there are two options:

1. JBoss Enterprise Application Platform (EAP): commercial support by RedHat, more stable and with consistent releases of bug fixes.

2. WildFly: supported by the community through the mailing list and forums, infrequent bug fixes but with the newest features available faster.

Both versions are installed the same way: just unzip the downloaded file in a place you can easily remember. Create the environment variable %JBOSS_HOME% pointing to the exact location where you unzipped JBoss.

Check if it's correctly installed starting the server with the command:

Windows #> %JBOSS_HOME%\bin\standalone.bat

Unix #> ./$JBOSS_HOME/bin/standalone.sh

You know when the startup finishes when you see the following message in the console:

(EAP) JBoss EAP 6.1.0.GA (AS 7.2.0.Final-redhat-8) started in 2659ms

(AS) JBoss AS 7.1.1.Final "Brontes" started in 2053ms

Open a web browser and access the URL http://localhost:8080 to see the JBoss welcome page. We still have to create an admin user to be able to operate the admin console, since JBoss also comes with no admin user defined. To create one, follow the instructions in the console URL: http://localhost:9990.


Migrating your database connectionThe database connection is by far the most frequently accessed component for Java EE applications. We will use MySQL to illustrate the deployment and the creation of a module for the JDBC Driver. If you use another database, youll probably go through the same steps, but using different parameters.

INSTALLING THE JDBC DRIVER ON TOMEE+TomEE+ follows pretty much the same principle of Glassfish. The JDBC driver becomes available when it is visible in the classpath. The practical way of doing it is dropping the MySQL driver (mysql-connector-java-5.1.23-bin.jar) in the %CATALINA_HOME%\lib folder. Restart the server to make it available for the creation of the datasource.

INSTALLING THE JDBC DRIVER ON JBOSS On JBoss, you have two ways of doing it: 1) you can deploy it as any other application package or 2) you can install it as a module.

For clustered environments, we recommend option #1 and deploy the driver, since the deployments are automatically propagated to all servers. If your driver is not JDBC4-compliant, youll have problems. In this case, take

option #2 and create a module for your driver. The advantage of the JDBC driver as a module is the possibility of creating a custom JBoss bundle for your organisation--this way, you can repeat exactly the same installation throughout several machines, preserving the same configuration.

1. Deploying the JDBC DriverIn the admin console, go to Runtime > Server > Manage Deployments and click on Add Content to deploy the MySQL driver. Upload the driver and give it a new name. Any JDBC4-compliant driver is automatically recognized by JBoss and made available for new datasources. If you are not using a JDBC4 driver, then click on En/Disable right after the deployment.


2. Creating a Module for the JDBC DriverTo create a module:

1. Go to %JBOSS_HOME%/modules/system/layers/base/com and create the folder mysql/main

2. Copy the file mysql-connector-java-5.1.23-bin.jar to the new folder %JBOSS_HOME%/modules/system/layers/base/com/mysql/main

3. Create the file module.xml in the same folder with the following content:

The name of the driver file may vary, so make sure you declare exactly

the same name in the resource-root tag. Restart the server to make it accessible using the name com.mysql elsewhere in the configuration.

CONFIGURING THE DATASOURCE ON TOMEE+The configuration of a datasource on TomEE+ is really simple. All you have to do is to open the tomee.xml file and add the following configuration:

JdbcDriver com.mysql.jdbc.Driver JdbcUrl jdbc:mysql://localhost:3306/app UserName app_user Password user_password

Restart the server to make it available for the application.

The JNDI name is used by the application to reference the datasource, and here is a fundamental difference between Glassfish and TomEE+. Your current JNDI name may look like jdbc/appds in Glassfish, but in TomEE+ you need to append the prefix openejb:Resource/, resulting in openejb:Resource/jdbc/appds.


CONFIGURING THE DATASOURCE ON JBOSSThe 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.

You can create a datasource by directly changing one of these files:

%JBOSS_HOME%/domain/configuration/domain.xml OR %JBOSS_HOME%/standalone/configuration/standalone.xml

If you have a clustered environment, which usually happens in production,

then add the following configuration to the file domain.xml. To do the same with a single JBoss instance, add it to the file standalone.xml. {...} jdbc:mysql://localhost:3306/app mysql 5 15 true db_user user_password {...}

{...} com.mysql.jdbc.Driver

Restart the server to make it available for the application.

APPLICATION CONFIGURATION FOR THE DATASOURCEBecause of differences in the JNDI naming rules, it's necessary to change all occurrences of the previous JNDI name to the new one.

For TomEE+, search for jdbc/AppDS and change it to openejb:Resource/jdbc/AppDS.

For JBoss, change to java:/jdbc/AppDS. If you are using JPA, you will find a reference to the datasource in the file persistence.xml. You may also find such references in @Resource annotations.


CHAPTER III:SETTING UP YOUR JAVA EE SPECIFICATIONS/ IMPLEMENTATIONS: EJB, CDI, JSF AND JPA

You might assume that your Java EE specs, being standardized, will port directly and easily over to your new application set up...but you know what they say: if it seems too good to be true, then it probably is! ;-)


Ooh, these standards should migrate seamlessly, right?One of the great things about specifications is that every developer who reads and implements them will understand them in exactly the same way, thus providing an implementation which isnt just accurate, performant and bug free, but is entirely interoperable with any other implementation.

That is to say, an application which runs on implementation A of a specification will equally work when ported to implementation B of the specification. Isnt that great! So well just assume everything will just port across and work.WAIT, WHAT? Thats not what actually happens in reality?!? Shock! Horror! *Drops donut on the floor*

In reality, there are always going to be differences in how developers implement a specification irrespective of how a spec is written, because were human, we have different viewpoints and our brains make assumptions, where perhaps they shouldnt. We need to understand the jump between specification and implementation.

The only way to guarantee a reasonable level of interoperability is to be assured that the implementations act the same, which means they need to be tested effectively. As a result, the key isnt so much in the specification, but in the Technology Compatilibity Kit (TCK), which is a set of tests designed to confirm an implementation of a JSR as compliant. If the TCK for a specification is bulletproof, it doesnt matter how loose the specification is, as the implementation is all we really care about. OK, its a lot easier if we have a good spec to write from, but the TCK holds the key. When we have 2 vendors which both implement a standard or spec, and interop is a pain, do not blame the vendor, blame the TCK. Oh and by the way, you cant access the TCK as a user, its all under wraps.

Were going to go through each of these specifications and see which implementations each application server uses and reflect on the migration paths between these variations.


Enterprise JavaBeans (EJB)The EJB specification is one which many vendors actually choose to implement themselves, rather than use existing implementations. TomEE on the other hand has a history with Tomcat, which needs to be respected. This is from Tomcat users who already latch an EJB implementation onto the existing Tomcat base for use in a broader application environment. As a result, TomEE uses the Apache OpenEJB implementation. This was also a good choice, as for a new application server its important that it uses a well-trusted and tested implementation.

GlassFish uses its own EJB implementation, as does JBoss, but the EJB TCK is pretty strong and while its not rare to find interop problems during migration between vendors, its certainly not one of the bigger areas to worry about.

The reference implementation of CDI in Java EE is called Weld, a project driven mostly by RedHat, but included in both GlassFish and JBoss, whereas TomEE uses OpenWebBeans. Lets take a look at the different versions supported by the different levels of application servers

GlassFish 3.1.2 embeds Weld 1.1.4, while GlassFish 4 embeds Weld 2.0.0 SP1--although, if youre using JSF as well, you may have upgraded to SP2 due to a Weld GF issue. JBoss EAP 6 uses Weld 1.1.8 and WildFly 8 uses Weld 2.1.1. TomEE, as we said, uses Apache OpenWebBeans as its CDI implementation.

When we look at the differences in these implementations, there are a couple of things to look out for. Firstly, you should ultimately care if the implementations are actually different projects, but you should also take note of the versioning, as sometimes that can offer up different problems based on the version migration path. This is very much up to the vendor / implementer though.

With CDI, both GlassFish and JBoss have the same implementations by CDI project, but at different versions. Weld is backwards compatible, and has a well-trodden path for upgrading versions, so you should have few CDI migration issues going from GlassFish to JBoss. TomEE meanwhile uses OpenWebBeans from Apache, so does have greater potential for migration problems.

Context and Dependency Injection (CDI)


JavaServer Faces (JSF)The Java EE reference implementation of JSF is Mojarra. GlassFish embeds this directly into its runtime, whereas JBoss has a JSF implementation which contains Mojarra inside it. GlassFish 3.1.2 contains Mojarra 2.1.6, but of course you may have upgraded this to 2.2 to test-drive some of the new Java EE 7 features. GlassFish 4 contains Mojarra 2.2 out the box.

Both WildFly and JBoss EAP have implementations of JSF based on Mojarra, so you should get a very similar experience with your vanilla Mojarra-based applications. JBoss now ships with a feature called Multi-JSF, which allows you to install multiple JSF implementations at different versions from JSF 1.2 up to and beyond JSF 2.2. This includes Mojarra or Apache MyFaces and so on. This gives you great flexibility for changing the JSF implementation in the future or using an implementation closest to GlassFish to migrate to initially; however, their default wrappered implementation shouldnt prove that tricky to move to.

As you may guess, TomEE+ uses Apache MyFaces and ships with version 2.1.13, so its at the Java EE 6 level and if youre already using JSF 2.2, youd need to try to patch TomEE+ with MyFaces 2.2 which some have tried, or simply wait for TomEE to support it. As a migration from Mojarra to MyFaces, Mojarra tends to allow things which MyFaces does not, such as nested forms, actionListener validation, and more, so be prepared to do some work here during your migration.

The reference implementation for JPA is EclipseLink, a little-known JPA implementation compared to Hibernate or OpenJPA, but its the implementation that GlassFish uses.

Interestingly, TomEE+ and JBoss each choose different implementations also, with TomEE+ opting for Apache OpenJPA (predictably) and JBoss using Hibernate (core).

So realistically there isnt going to be a plain and simple migration regardless of the route you take here, although the truly painful path of migrating from Hibernate to X, which is heavy on customizations, isnt being considered. Of all the specifications, JPA migration looks to be the worst, with many experiencing exceptions throughout their persistence units during the migration.

Java Pesistence API (JPA)


CHAPTER IV:GETTING THE REST OF YOUR ENVIRONMENT BACK ONLINE (REPOSITORY, IDE, CI SERVER AND FRAMEWORKS)

Getting close to the end--here we go over getting your general development infrastructure back online, from repository to web framework.


Your repositoryWe hope at this point youve stopped the thought process whereby you are thinking, Well, at least I dont need to do anything regarding migration of X, where X = repository ;-)

Luckily, we dont really see any problems with repositories. We include this for the sake of completeness, unless of course you work on a product that uses the application server as a dependency. In that case, the dependency is probably wired deeply into the logic of your code and only your team could have enough insight to predict the pain this migration might bring.

But if youre really interested in it, heres with the source code for JBoss and the SVN repo for TomEE+. Both provide enough instructions to get started, build the project, start and run some tests. And hey, if youre in the mood, you can contribute a bugfix or two!

Brace yourself though, IDE configuration requires probably the most changes out of all the sections of your development environment. Changes here are IDE-specific, so we divided this chapter into relevant parts covering the three most widely-used IDEs: Eclipse, Intellij IDEA and NetBeans.

ECLIPSE As you probably know, Eclipse is the most popular open source IDE for Java development, with an enormous community behind it. Eclipse is an excellent IDE, as we wrote in Using Eclipse for Java Development, but its also a platform for rich applications and has the largest number of plugins available.

Eclipse and TomEE+Managing your application server and deploying to it from within Eclipse is supported for nearly all of the app servers out there. For some of them, however, integration is more complex: for example, TomEE+ deployments work fine, however it uses Apache Tomcats connector to make it done.

Your IDE


When you configure a TomEE+ installation, just pick Apache Tomcat 7s connector and point your Eclipse to a directory where youve unpacked a TomEE+ archive. As a tip, wed recommend naming this server runtime TomEE or something to distinguish it from the regular Tomcat instances.

Your next steps are straightforward and are the same for all the servers: Just

click on the application and make it Run on server, then select your TomEE+ instance and check Always use this server when running this project.

Thats it! And when the server starts, it will deploy your application. If instead of starting the server, Eclipse mumbles something about Runtime Environment not being configured, open the server configuration and ensure that one is configured.

Thats it, now it should run without any problems.


Eclipse and JBoss Now lets configure a JBoss instance to be up and running as well. Eclipse has an excellent JBoss Tools plugin, which is actually an umbrella project for several tools to support JBoss, Drools, JBoss Portal, Seam and other JBoss technologies.

Installing JBoss tools will bring tons of plugins to your Eclipse instance, however, these come from a single source and are verified to work together well. So dont worry about performance, they bring value if youre using JBoss.

Configuring a JBoss instance works like the same way as for the others servers. Just select the server type and point it to some unpacked JBoss location:

By dragging-n-dropping your project to a configured server on the

Servers tab, it will create a configuration to deploy the application. Starting the server will bring that application up now.


INTELLIJ IDEAWhats good about Intellij IDEA is that, being a commercial IDE with rapid release cycles, it almost always comes with batteries included. IntelliJ has a good integration with TomEE+, so that when you specify a location of your TomEE server directory, IntelliJ parses versions of the libraries youre using

and presents all the information clearly.

IntelliJ IDEA with TomEE+

In all other aspects it just works so after a couple of clicks youll get your server up and running.

IntelliJ IDEA with JBossIts also pretty much a breeze in the case of JBoss. IntelliJ offers a sample configuration and the only thing needed is to point it to a location of local JBoss home directory and specify what artifact to deploy.

The server now can be started with just a click of the Run button. And the application is deployed as one would expect.


NETBEANSFor this report, we tried out and configured a beta build of NetBeans 8.0.

Allegedly, its stable and faster than its predecessors.

NetBeans and TomEE+TomEE integration requires the Java EE Base plugin to be installed, which is a good thing since we actually set up JBoss first and realized that since we didnt have it installed, we were prevented from deploying to the application server configured. However, installing the plugin solved the issues... When you develop web or enterprise applications, you want the first class support for it in your IDE.

Lets say you have a TomEE+ instance unpacked and ready to be configured. When you select TomEE as a server type in NetBeans 8.0, it asks a bit more details than just a location of binaries.

You can optionally specify which directory you want to have as $CATALINA_BASE, so different server configurations wont compete with each other. Additionally, you can specify the manager user credentials, so they can be used for deployment.

Compared to WildFly, which is a certified Java EE 7 application server, TomEE at the time of this report being written only supports Java EE 6. So it might be smart to review this option in the NetBeans run dialog.

NetBeans and JBossOut of the box NetBeans 8.0 doesnt have any support for JBoss servers, so to

fix this problem, go through Tools > Plugins > Available plugins > WildFly application server and install this support. As we mentioned above, the Java EE Base plugin is completely necessary here to avoid major headaches.

After an IDE restart, you can start configuring JBoss instances. The menu to

add servers is located under the Tools > Servers item. Configuration closely resembles that in all IDEs mentioned above: just point to the location of JBoss and continue.


The NetBeans wizard automatically goes through another screen to configure instance parameters.

So in order to deploy, you should open project properties, select the Run tab and specify what application server should NetBeans use.

YOUR CI SERVERLike we reported in Why Devs


Here are a couple of sample configurations for the Cargo-Maven plugin. First of all, we want to install the application server automatically. Luckily, most of the servers are available as Maven artifacts, so we can use Cargos default installer here.

org.codehaus.cargo cargo-maven2-plugin ${cargo.version} wildfly org.wildfly wildfly-dist 8.0.0.Final runtime HOSTNAME 9990 org.jboss.as jboss-as-controller-client 7.0.2.Final [...]

The installer will download and unpack the application server artifact. The configuration section specifies which port Cargo should use to deploy your

application to the WildFly.

Respectively, if youre interested in the TomEE+ configuration, you just need to change a couple of lines. For example, Mavens artifact with a TomEE+ distribution is:

org.apache.openejb apache-tomee 1.6.0

Other settings are also somewhat specific to the connector that Cargo uses to manage the server, however there are no dramatic differences. With Apache Cargo you can easily include an application server setup into your continuous integration builds.


YOUR JAVA FRAMEWORKSMost frameworks youre using are not directly tied to an implementation of the application server, but there can be differences. In general, every application server allows overwriting its default configuration to specify the versions of libraries to use for a given deployment. So one of the easiest ways

to migrate your application to another application server is to bundle all the implementations within the archive and make the server prioritize these.

However there are exceptions to a lot of rules. When we talk about frameworks that are required to manage servers themselves, its different story. Lets take a look at whether your tests can be executed on another application server.

ArquillianArquillian is a testing platform for Java maintained by Red Hat, which works best for integration tests that run in an actual application server environment. Its a different approach from unit testing, where you want to ignore or mock as much of the external environment as possible.

Luckily, Arquillian is designed to handle application server environments where you need to:

Manage the lifecycle of the container;

Deploy the archive to the container;

Execute the tests inside or against it.

In general, all server-related activities are done by a specific component inside Arquillian, a container adapter. Naturally, there are adapters for the most established application servers.

Another cool thing is that Arquillian is a Maven project, so specifying an adapter is a matter of pom.xml fiddling--here is an example of a configuration taken from the useful Java EE samples repository on GitHub:

Configuring JBoss involves some additional actions to unpack files and prepare the deployments, but its not a dramatic difference from what the GlassFish configuration looks like.

TomEE also enjoys Arquillian love, and being an Apache project it naturally has support for other open-source technologies. To use an Arquillian adapter for TomEE, just specify another dependency in the pom.xml.


You can also configure which ports your TomEE instance should bind with another XML snippet:

9090 9099

Other frameworks that manage servers have also probably thought about integrations with different application servers, but as you can see with GlassFish, JBoss or TomEE, Arquillian got it covered.

If you are undergoing or planning a migration, we recommend that you create at least some acceptance tests to run in both application servers. Such minimal test coverage cannot catch all the bugs, but it will show you if things will blow up in your new app server environment.

Hopefully this brief introduction to getting your repositories, IDEs, CI servers and frameworks up and running with your new application server was helpful. Now time for closing thoughts :-)


CHAPTER V:SUMMARY, CONCLUSION AND GOODBYE COMIC ;-)

Looking for a recommendation on whether to use TomEE+ or JBoss? Well, you wont find one here--both options are good depending on your needs--but this summary may help consolidate your thoughts...


What to expect when migrating to TomEE+Bolstered with the long-term market and community spirit of Tomcat, and given some new life with the young, ambitious Tomitribe for providing commercial support, TomEE is a promising choice for development continuing with Java EE 6 backed by an array of Apache implementations. Weve heard that Java EE 7 certification is in the plans for 2014, but it shouldnt be hard to get a hold of someone at Tomitribe to ask more questions.

MIGRATING APPLICATION, DB AND DATASOURCEInstalling and configuring TomEE+ is a simple thing, from .zip download to JDBC driver installation, JNDI name changes and datasource config. Some minor naming conventions are to be changed.

JAVA EE SPECIFICATIONS EJB, CDI, JSF AND JPATomEE benefits from long-standing Tomcat reference points, using OpenEJB effectively but requiring OpenWebBeans and MyFaces in place of the GlassFishs own Weld and Mojarra implementations, shared by JBoss. GlassFishs EclipseLink JPA implementation makes it an ugly migration regardless of app server.

REGARDING REPOS, IDES, CI SERVERS AND FRAMEWORKSMost of this is easy, as your repositories, CI server and frameworks dont need to be migrated in a way, but connecting everything and ensuring its all working is another story. For CI servers, we recommend Apache Cargo, and using Arquillian to run integration tests to ensure that your frameworks arent breaking your code is a great idea.

Regarding IDEs, configuring Eclipse with TomEE requires Tomcat 7s connector, IntelliJ IDEA is a piece of cake once the TomEE server directory is specified, and NetBeans is a bit trickier, requiring Java EE Base plugin to be installed and needs more info than the others.

Source: http://xkcd.com/583/


Both WildFly and JBoss EAP have a well-established history of providing commercial support on top of excellent products. For development teams looking to use the latest Java EE 7 features, WildFly is the only certified implementation at the time of this writing. With an enormous community and wide installation base, Red Hat is the poster-child in enterprise open source solutions.

MIGRATING APPLICATION, DB AND DATASOURCEMigration to JBoss is more or less as simple as it is with TomEE, with only minor differences emerging when it comes single vs. clustered instances of JBoss EAP or WildFly for your environment.

JAVA EE SPECIFICATIONS EJB, CDI, JSF AND JPAJBoss uses its own EJB implementation, relying on the EJB TCK for interoperability. Regarding CDI and JSF, JBoss shares Weld with GlassFish, and now contains a handy multi-JSF feature that lets it work from Mojarra (Java EEs JSF implementation) or MyFaces equally. JBoss uses Hibernate as its JPA implementation, which being different from GlassFishs can lead to difficulties.

REGARDING REPOS, IDES, CI SERVERS AND FRAMEWORKSAs with TomEE, we gave the source code for setting up your repositories, and with Apache Cargo and a bit extra code, your CI server will be hooked up. Arquillian is literally built by Red Hat, so this is a breeze too. IDE support with Eclipse is handled by JBoss Tools, which is an excellent umbrella group of plugins. IntelliJ IDEA has first class support as well, and set up is simply pointing to your home directory. NetBeans 8.0 doesnt support JBoss out of the box, so it needs some extra installation, and also that Java EE Base plugin.

Looking for a quick answer? Sorry, this report isnt designed for that! The decision to migrate at all is still probably being discussed in most organizations--perhaps some of you were not even aware that Oracle has planned to discontinue commercial support for GlassFish! Regardless, this is a decision that requires planning and the ability to accept that your decision will probably be unpopular with some developers. Considering these factors, we suggest that you take the path of least resistance, be it TomEE or JBoss.

Editors note: Many thanks to Hildeberto Mendonca and Markus Eisele, two excellent Java engineers that donated their time and brains to make this report possible. This report was brainstormed, edited and written by (in alphabetical order) Markus Eisele, Simon Maple, Hildeberto Mendonca, Oleg Shelajev and Oliver White.

What to expect when migrating to JBoss Final thoughts


Report Authors:Markus Eisele, Simon Maple, Hildeberto Mendonca, Oleg Shelajev and Oliver White

Report Designer: Ladislava Bohacova

Contact Us

Estonialikooli 2, 4th floorTartu, Estonia, 51003Phone: +372 653 6099

Twitter: @RebelLabs

Web: http://zeroturnaround.com/rebellabs

Email: [email protected]

USA399 Boylston Street, Suite 300, Boston, MA, USA, 02116Phone: 1(857)277-1199

Czech RepublicOsadn 35 - Building BPrague, Czech Republic 170 00Phone: +372 740 4533

Documents

Migrating From Glassfish to Jboss Tomee