> 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:


  • reference implementation of Java EE
  • excellent Web administration interface
  • ideal to learn Java EE


  • 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:


  • 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)


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


  • 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


  • 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:

  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

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!