Migrating From Glassfish To Jboss Tomee

ABANDON FISH!
MIGRATING FROM GLASSFISH TO JBOSS OR TOMEE

or
f
s
k
n
a
h
t
d
S o lo ng, atnhe fis h!
all
All rights reserved. 2014 ZeroTurnaround O
TABLE OF CONTENTS
CHAPTER I
A LITTLE HISTORY OF GLASSFISH 1-4
Click
to se to go
ct i on
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
CHAPTER IV
GETTING THE REST OF YOUR ENVIRONMENT BACK ONLINE

(REPOSITORY, IDE, CI SERVER AND FRAMEWORKS)
CHAPTER V
SUMMARY, CONCLUSION AND GOODBYE COMIC ;-)
19-28
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
What? A free, faster competitor

to Oracle and IBM?
Officially, the tool we all know as GlassFish is really GlassFish Open Source
Edition, which is Oracles GPL/CDDL-licensed Java EE application server.
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.
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.
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.
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.
Oracle buys Sun Microsystems
Oracle pulls commercial support
The 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.
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.
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 longoverdue 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.
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.
Other barriers to the longevity of GlassFish

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!
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.
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.
GlassFish users are probably facing the following options:
PRAGMATISM
Meaning
Find an alternative to the GlassFish 3 web/full profile

and postpone the plans to migrate to Java EE 7
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.
PATIENCE
Leave things alone for a while and start
evaluating alternatives to GlassFish 4
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.
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.
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 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.
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.
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.
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.
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.
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
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 opensource 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, goodlooking 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_HOMEpointing 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 run
Unix #> ./%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:

<role rolename="tomee-admin" />
<user username="tomee" password="tomee" roles="tomeeadmin,manager-gui"/>
According to the configuration above, you can authenticate within the

application manager using the username tomee and password tomee.
10
INSTALLING JBOSS
Download 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.

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.
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
11
Migrating your database connection

The 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+
1. Deploying the JDBC Driver

In 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.
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-java5.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.
12
2. Creating a Module for the JDBC Driver

To 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:
<?xml version="1.0" encoding="UTF-8"?>

<module xmlns="urn:jboss:module:1.1" name="com.mysql">
<resources>
<resource-root path="mysql-connector-java5.1.23-bin.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
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.
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.
13
CONFIGURING THE DATASOURCE ON JBOSS

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.
{...}
<driver name="mysql" module="com.mysql">
<driver-class>com.mysql.jdbc.Driver</driver-class>
</driver>
</drivers>
</datasources>
You can create a datasource by directly changing one of these files:

Restart the server to make it available for the application.
%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
APPLICATION CONFIGURATION FOR THE DATASOURCE

Because of differences in the JNDI naming rules, it's necessary to change all
occurrences of the previous JNDI name to the new one.
with a single JBoss instance, add it to the file standalone.xml.

<datasources>
{...}
<datasource jndi-name="java:/jdbc/AppDS" pool-name="AppDS"
enabled="true" use-java-context="true">
<connection-url>jdbc:mysql://localhost:3306/app</
connection-url>
<driver>mysql</driver>
<pool>
<min-pool-size>5</min-pool-size>
<max-pool-size>15</max-pool-size>
<prefill>true</prefill>
</pool>
<security>
<user-name>db_user</user-name>
<password>user_password</password>
</security>
</datasource>
{...}
<drivers>
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.
14
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! ;-)
15
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.
16
Enterprise JavaBeans (EJB)
Context and Dependency Injection (CDI)
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 welltrusted and tested implementation.
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.
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.
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.
17
JavaServer Faces (JSF)
Java Pesistence API (JPA)
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.
The reference implementation for JPA is EclipseLink, a little-known

JPA implementation compared to Hibernate or OpenJPA, but its the
implementation that GlassFish uses.
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.
Interestingly, TomEE+ and JBoss each choose different implementations

also, with TomEE+ opting for Apache OpenJPA (predictably) and JBoss
using Hibernate (core).
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.
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.
18
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.
19
Your repository
Your IDE
We 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 ;-)
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.
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!
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.
20
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.
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.
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, now it should run without any problems.
21
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.
22
INTELLIJ IDEA
Whats 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
IntelliJ IDEA with JBoss

Its 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.
and presents all the information clearly.

IntelliJ IDEA with TomEE+
The server now can be started with just a click of the Run button. And the
application is deployed as one would expect.
In all other aspects it just works so after a couple of clicks youll get your
server up and running.
23
NETBEANS
For 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.
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 JBoss
Out 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.
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.
24
The NetBeans wizard automatically goes through another screen to

configure instance parameters.
YOUR CI SERVER
Like we reported in Why Devs <3 CI: A guide to loving Continuous
Integration, Continuous Integration is the key to successful development
and project monitoring--your software project simply isnt healthy or reliable
if you dont use this pretty-much standard concept. Arguably, there are not
so many differences for between application servers that affect CI servers
like Jenkins, Hudson, Bamboo, TeamCity and others.
However, for the sake of completeness, wed love to provide some insight
about how to configure your CI server to deploy build artifacts to JBoss or
TomEE application servers, using Apache Cargo.
So in order to deploy, you should open project properties, select the Run
tab and specify what application server should NetBeans use.
Apache Cargo
Different projects have different needs and have to be treated personally.
Were going to focus on a default Maven web-application project setup,
just to give you hints where to look when you want to set up your new
application server from within your CI server.
In the Java world, Apache Cargo is a de facto leader among application
server manipulation tools. Cargo provides a Java API, Ant tasks and Maven
plugins to manage your application servers and you can see in the feature
matrix that it has support for GlassFish 3.x/ 4.x, JBoss and TomEE (though
Tomcat connectors).
25
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.
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>${cargo.version}</version>
<configuration>
<container>
<containerId>wildfly</containerId>
<artifactInstaller>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-dist</artifactId>
<version>8.0.0.Final</version>
</artifactInstaller>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.hostname>HOSTNAME</cargo.hostname>
<cargo.jboss.management-native.port>9990
</cargo.jboss.management-native.port>
</properties>
</configuration>
<dependencies>
<dependency>
<groupId>org.jboss.as</groupId>
<artifactId>jboss-as-controller-client</
artifactId>
<version>7.0.2.Final</version>
</dependency>
</dependencies>
[...]
</plugin>
</plugins>
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:
<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>apache-tomee</artifactId>
<version>1.6.0</version>
</dependency>
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.
</build>
26
YOUR JAVA FRAMEWORKS

Most 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
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:
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.
Arquillian
Arquillian 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.
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.
<dependency
<groupId>org.apache.openejb</groupId>
<artifactId>arquillian-tomee-embedded</artifactId>
<version>1.0.0</version>
</dependency>
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.
27
You can also configure which ports your TomEE instance should bind with
another XML snippet:
<container qualifier="tomee" default="true">
<configuration>
<property name="httpPort">9090</property>
<property name="stopPort">9099</property>
</configuration>
</container>
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 :-)
28
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...
29
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.
REGARDING REPOS, IDES, CI SERVERS AND FRAMEWORKS
MIGRATING APPLICATION, DB AND DATASOURCE
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.
Installing 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.
Most 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.
JAVA EE SPECIFICATIONS EJB, CDI, JSF AND JPA

TomEE 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.
Source: http://xkcd.com/583/
30
What to expect when migrating to JBoss
Final thoughts
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.
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.
MIGRATING APPLICATION, DB AND DATASOURCE

Migration 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 JPA

JBoss 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.
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.
REGARDING REPOS, IDES, CI SERVERS AND FRAMEWORKS

As 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.
31
t
Co ntac
Us
Twitter: @RebelLabs
Web: http://zeroturnaround.com/rebellabs
Email: labs@zeroturnaround.com
Estonia
likooli 2, 4th floor
Tartu, Estonia, 51003
Phone: +372 653 6099
USA
399 Boylston Street,
Suite 300, Boston,
MA, USA, 02116
Phone:
All rights reserved. 2014 ZeroTurnaround
O 1(857)277-1199
Czech Republic
Osadn 35 - Building B
Prague, Czech Republic 170 00
Phone: +372 740 4533
Report Authors:
Markus Eisele, Simon Maple, Hildeberto
Mendonca, Oleg Shelajev and Oliver White
Report Designer: Ladislava Bohacova
32

Migrating From Glassfish To Jboss Tomee

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Migrating From Glassfish To Jboss Tomee

Hochgeladen von

Copyright:

Verfügbare Formate

ABANDON FISH!

MIGRATING FROM GLASSFISH TO JBOSS OR TOMEE

All rights reserved. 2014 ZeroTurnaround O

A LITTLE HISTORY OF GLASSFISH 1-4

MIGRATING YOUR APPLICATION

SETTING UP YOUR JAVA EE SPECIFICATIONS/

GETTING THE REST OF YOUR ENVIRONMENT BACK ONLINE

SUMMARY, CONCLUSION AND GOODBYE COMIC ;-)

All rights reserved. 2014 ZeroTurnaround O

A LITTLE HISTORY OF GLASSFISH

All rights reserved. 2014 ZeroTurnaround O

From caviar to great white shark

What? A free, faster competitor

Historically, GlassFish has always been backed up by a commercial distribution.

GlassFish came a long way, starting as a Sun Microsystems Inc. project

The release of GlassFish 2.1 was in more or

All rights reserved. 2014 ZeroTurnaround O

Oracle buys Sun Microsystems

Oracle pulls commercial support

There are various interpretations of this announcement. Common sense

All rights reserved. 2014 ZeroTurnaround O

Other barriers to the longevity of GlassFish

All rights reserved. 2014 ZeroTurnaround O

All rights reserved. 2014 ZeroTurnaround O

MIGRATING YOUR APPLICATION

All rights reserved. 2014 ZeroTurnaround O

GlassFish users are probably facing the following options:

Find an alternative to the GlassFish 3 web/full profile

Youll probably want to start a relationship with another

All rights reserved. 2014 ZeroTurnaround O

TomEE 1.6, JBoss EAP 6

* Red Hat doesnt offer technical support for WildFly yet.

The vibrant developer community around these tools,

The amount of documentation available on the web

The sponsorship and support by market leaders

All rights reserved. 2014 ZeroTurnaround O

OPEN SOURCE OPTIONS WITH COMMERCIAL SUPPORT TOMEE AND JBOSS

PROPRIETARY OPTIONS - WEBLOGIC AND WEBSPHERE

is opting for an equivalent open source alternative. Thats why we have

However, the open source alternatives already support those deployment

But...if you really wanted to implement an

All rights reserved. 2014 ZeroTurnaround O

You next app server: Installing JBoss and TomEE

All rights reserved. 2014 ZeroTurnaround O

INSTALLING TOMEE (ACTUALLY, WERE USING TOMEE+)

According to the configuration above, you can authenticate within the

WildFly: supported by the community through the mailing list

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

All rights reserved. 2014 ZeroTurnaround O

Migrating your database connection

INSTALLING THE JDBC DRIVER ON TOMEE+

1. Deploying the JDBC Driver

INSTALLING THE JDBC DRIVER ON JBOSS

All rights reserved. 2014 ZeroTurnaround O

2. Creating a Module for the JDBC Driver

<?xml version="1.0" encoding="UTF-8"?>

CONFIGURING THE DATASOURCE ON TOMEE+

Restart the server to make it available for the application.

All rights reserved. 2014 ZeroTurnaround O

CONFIGURING THE DATASOURCE ON JBOSS

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

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

APPLICATION CONFIGURATION FOR THE DATASOURCE