Why I have planned to move to Apache TomEE, the next-generation Java EE server
By Jonathan Lermitage on Friday 22 March 2013, 16:00 - Java EE / Web - Permalink
After having worked with GlassFish and Tomcat platforms for several years, I recently planned to quit them and learn the TomEE platform. I'll try to explain why and how.
This news is also available at http://www.dzone.com/links/(...).
Why?
> Why I quit the GlassFish Java EE server:
GlassFish is the reference implementation of the Java EE technology. It is rather stable, mature and it has a great graphical administration interface (e.g. you can easily deal with JDBC pools, JNDI, virtual servers, users, security, etc). I think it is an excellent Java EE server for beginners: they don't have to spend time on obscure XML files and DTDs.
So, what's the problem?
GlassFish has a big, a huge problem: infrequent releases. You have to wait months for a new releases. It would not be a problem if the server was totally stable. Unfortunately, you have to deal with some (critical) bugs.
An example: an old (7+ months!) official bug in the GlassFish infrastructure generates an important memory leak in the JAX-WS2 (Web Services) component. It is a very specific problem (it affects some particular Web Services only), but it will lead to a server crash, every time. Developers have planned to fix it for the next GlassFish release: version 4.0. This version is under development since more than 5 months, and we still have to wait. This is unacceptable! How could you seriously explain to a customer his server will continue to crash, and you have to look for a workaround instead of a regular fix-pack?
To summarize:
Pros:
- reference implementation of Java EE
- excellent Web administration interface
- ideal to learn Java EE
Cons:
- bugs
- infrequent releases
- server's startup is slow
- sometimes, the Web administration interface is very slow
> Why I quit the Tomcat Servlet Container:
I love Tomcat. It's pretty fast, stable, well documented and the developers deliver very frequent patches. Meanwhile, this is a Servlet Container only. I have had to add JAX-WS, JAX-RS an some other Java EE functionalities to Tomcat for personal and professional projects. Let's be honest: this was a pain. I always had problems with configuration files, missing parameters, etc. I spent too much time making it work. Ho, you can find many tutorials on the web, but half of them simply don't work :p That's why I decided to abandon Servlet Containers in order to work with full Java EE servers only: you don't have to deal with technologies integration; you install the server, configure it, and it's okay!
To summarize:
Pros:
- blazing fast
- very stable
- well documented (if you like Apache documentations)
- very frequent releases
- everybody know Tomcat, this is the most used Java server (I've not said Java EE server)
Cons:
- poor Web administration interface
- this is a Servlet Container only
- adding Java EE features can be a pain
> What's TomEE?
You can see TomEE has a super-version of Geronimo. Geronimo is a Java EE server based on Tomcat (in older versions you could find packages based on Jetty too). You got the same functionalities as GlassFish with the speed of Tomcat. Unfortunately, the Geronimo project seems to be (a little bit) dead. TomEE is very comparable to Geronimo, but it is more modern, smaller, faster, and it is probably the next super-star of the Apache Java EE servers.
For information, both Geronimo and TomEE are Apache projects.
Pros:
- the speed of Tomcat and the power of a full Java EE server
- very stable
- well documented (if you like Apache documentations)
- based on Tomcat, so you already know how to configure it
- frequent releases, and it may be better once TomEE will be (one of) the most used Java EE server
Cons:
- you'll probably have to install Metro 2.2
- poor Web administration interface
TomEE integration with NetBeans
Good new! TomEE shares the Tomcat structure, so NetBeans currently sees it as a simple Tomcat server. That means you can register and manage (start, stop, deploy, etc) TomEE has a Tomcat server.
I hope NetBeans 8 will add a special support for TomEE (to offer a better support of projects that use JAX-WS, JAX-RS, etc) in order to consider it as a full Java EE server; but this is not urgent. You can already work with TomEE + NetBeans.
JDBC pools
Good new again! If you have declared JDBC pools in your server's configuration files, the migration is not hard. Look at this example, a JDBC pool declared in the conf/context.xml
configuration file of Tomcat 7:
<Resource name="jdbc/demo" type="javax.sql.DataSource" auth="Container driverClassName="org.mariadb.jdbc.Driver" url="jdbc:mysql://localhost:3307/demo" username="demouser" password="mySecret" initialSize="4" maxActive="200" maxIdle="20" minIdle="4" removeAbandoned="true" removeAbandonedTimeout="60" validationQuery="SELECT 1"/>
To make it work on TomEE, simply edit its conf/tomee.xml
configuration file and transpose your Resource:
<Resource id="jdbc/demo" type="javax.sql.DataSource"> auth Container JdbcDriver org.mariadb.jdbc.Driver JdbcUrl jdbc:mysql://localhost:3307/demo UserName demouser Password mySecret initialSize 4 maxActive 200 maxIdle 20 minIdle 4 removeAbandoned true removeAbandonedTimeout 60 validationQuery SELECT 1</Resource>
Update 2013-03-23: henk53 is right, we could use data-source element in web.xml. See comment n°5 :)
JAX-RS RESTful Web Services
Nothing to do; TomEE comes with CXF and its JAX-RS runtime, and it works fine.
JAX-WS SOAP Web Services
TomEE comes with CXF, so it already has a JAX-WS runtime. Unfortunately, if you have learn Web Services with Metro, you'll probably have to provide additional obscure configuration files (according to online documentation, CXF uses Spring to provide XML configuration of services; but I'm a bit lost, I'm still trying to understand it).
Then, and like Tomcat, we still have to install Metro into TomEE. If you come from GlassFish, don't forget to create a sun-jaxws.xml
(JAX-WS RI deployment descriptor) file and update your web.xml
file. Tip: NetBeans will ask you for adding Metro stack support into your webapp. Accept: it will generate and update your two xml files. After that, simply exclude the Metro library from your project's Compile-time Libraries
: uncheck the Metro 2.0
item). If you worked with Tomcat, you already installed Metro 2.2 and did the job on your webapp's configuration files.
EJB and other technologies
I'm working on. See you soon!
Comments
What's the issue with cxf? What hides the outdated (since versions are up to date ;)?
@rmannibucau : You're right, I'll reformulate my post.
Meanwhile, there is still a problem with CXF: many developers (especially beginners) will develop JAX-WS web services with the latest version of Metro. The best way to learn it is probably to use GlassFish or Tomcat + Metro.
- they develop their SEI and SEB. This is easy
- on Tomcat + Metro, they:
---> edit their web.xml file to register a WSServletContextListener listener and WSServlet servlet
---> add a sun-jaxws.xml file to register their web service
It works fine on GlassFish and Tomcat + Metro, and any server based on Metro. It works on WebSphere too and many other Java EE servers, without additional configuration.
Now, deploy your webapp to a server that uses CXF, like TomEE or Geronimo: it won't work. The server can't load the com.sun.xml.ws.transport.http.servlet.WSServlet servlet, etc.
According to the CXF website, this runtime uses Spring to provide XML configuration of services. Why? I have developed a standard JAX-WS web service and it doesn't work.
Configuring a webapp for CXF is a pain and I'm still not able to deploy a simple HelloWorld web service.
Any help is welcome, seriously. Sometimes I have to teach JAX-WS to beginners, and I can't imagine to talk about CXF, it's too complicated :)
This is sad true for Glassfish. I cannot agree more on Glassfish release cycle and I've already faced same issue on v2 and v3. The worst part is no one can tell when (of if) the reported bug will fix.
Nice blog! I definitely experienced the same with Glassfish and Tomcat. I learned Java EE 6 via Glassfish 3.1+ and netBeans 7.0+, and wrote my first and only JSF web app via Glassfish and netbeans, and it has been very very stable, and really there was not much need to migrate to tomcat or tomee, but tomcat/tomee had better websocket support or integration with atmosphere/websocket, so I tried tomcat, was too hard and i was unsuccessful during multiple attempts, but was successful migrating to tomee...of course, tomee committers helped me out! :)
yes, i found glassfish very very slow on startup and was NOT reliable when deploying EJB changes via netbeans, so I had to generate WAR via netbeans plenty of times, and deploy WAR via glassfish admin console for more/definitely reliable WAR deploy.
yes, i love the startup speed of tomee, and you forgot to mention that ActiveMQ/JMS comes bundled with tomee, and recently i wrote some 'simple MDB' software and added to my JSF web app and it is helping my web app run really really well, for the background processing that I have in the app (pushing data to google calendar, connect to email server via IMAP to download emails sent from public website form-mail and inserting data into database, and plan to add more background tasks).
i see/hear what you're saying about webservices and tomee/cxf. i have not developed webservices yet, but hope/plan to do that, soon. looking forward to the webservice development experience 'via tomee'. :)
>If you have declared JDBC pools in your server's configuration files, the migration is not hard
If you had declared them in web.xml using the Java EE 6 standard data-source element there would not be any migration needed at all ;) (of course assuming your app/system structure is build around embedded data sources)
If you need support and fixes for GlassFish you should consider using the oracle version.
Running OSS appservers of any kind on truly critical applications isn't a good plan IMHO.
And I agree, that GlassFish could have a couple of releases more :-)
-m
"adding Java EE features can be a pain". Switching application servers is a pain too. It is a pain once. You figure it out the differences then it is no longer a pain. Adding Java EE features you need to tomcat can be a pain - once. You figure it out then it is no longer a pain. Plus, it is extremely widely used. If you want to do something, there is a very good chance someone has figured it out and posted about it.
While TomEE is a good option, I question this reason to switch from Tomcat.
great post! thanks... i was thinking about doing the same move but i'm way too ignorant for such change. i returned to java last year and i'm still learning,i'd like to ask a couple of questions.
1) when i try to add session beans for my entity classes (jpa/eclipselink) netbeans tells me "Cannot be generated for Java EE 6 sources without server with complete Java EE 6 Web Profile support (at least EJB Lite support)."... is there a way to suppress that thing? what can i do?
2) where can i find more documentation about moving already running apps from GF to tomee?? mostly jsf (i know this works, already tried) and JPA.
thanks again.
@Fred : "there is a very good chance someone has figured it out"
Right, that's exactly what TomEE is -- we figured out how to do the whole Web Profile stack on Tomcat.
We do offer a war you can drop into Tomcat for people who like to do more themselves or have a specific Tomcat version they like.
Even with that, on rare occasion we do here that feedback and I wonder what we could possibly do to satisfy it. Do we need to make it harder to use these things on Tomcat and add some steps with instructions?
I wonder what downside there is to having less work to do to integrate stuff on Tomcat.
@shark : Same problem here. Looks like it is the property: j2ee.server.type=Tomcat
How can i change this without implementing a own server-skelleton?