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

The Great Java Application Server Debate: Tomcat

Update: Since this post was published, RebelLabs has completed the full version of The Great Java Application Server Debate with Tomcat, JBoss, GlassFish, Jetty and Liberty Profile. Feel free to check it out!

Download the full PDF report from RebelLabs

This blog post continues the Great Application Server Debate series, in which we have already covered IBM Liberty Profile as well as Jetty. Today we’re talking about (arguably the most popular application server) Tomcat and also touching on TomEE. As with previous posts, we will be reviewing the application server purely from a developers point of view.

Apache Tomcat is an open source application server that (in version 7.0) implements the Servlet 3.0 and JavaServer Pages 2.2 specifications, and includes many additional features that make it a useful platform for developing and deploying web applications and web services.

tomcat application server

First Impressions – Download and Install

It’s important that the first experiences with a product is clean, clear and easy. OK, it’s really hard to have a first impression with tomcat as it’s the one of the, if not the most popular application server on the market today which most people have used or experienced in one way or another. So although this isn’t my first impression with Tomcat, let’s take a look at it from a neutral first timer perspective.

  1. Start with google, and type in tomcat
  2. First hit is the Apache Tomcat site, click the link
  3. Under the Download menu on the left we click a version of Tomcat
  4. Click the binary we want to download
  5. Unzip – Download and install complete

Because of the epic-lightweight nature of Tomcat (12.8MB) this download and install happens epicly quickly – so much so, here is a 20 second video starting with a google search and ending with a running tomcat server. Yes, 20 seconds.

The eclipse tooling also provides you with an inbuilt wizard so you can download and install Tomcat onto your development environment.

Startup performance – restart/redeploy

Note to JRebel fans – While others read this section you can go enjoy a nice coffee break ;o)

Tomcat essentially contains a servlet container (Catalina) with JSP support (Jasper) and other nice enterprisey add ons such as JNDI, JDBC, Security, MBeans and so on. As a result we’d expect it to start very quickly. Using the pet clinic test, again the app takes approx 8 seconds from “Run As->Run On Server” till my petclinic application was visible. That’s pretty impressive. This again includes deployment time, startup and initialisation. Redeploy, (including reinitialization) takes around 6 seconds.

Read the complete Java Application Server Report where we discuss the pros and cons of App servers such as: Tomcat, Jetty, GlassFish, IBM WAS Liberty Profile and JBoss (aka WildFly):

With our larger Jenkins app, the deployment took around 6 seconds in total, but there seemed to be an amount of initialisation involved in that time as you can see from the snippet below. When I hit the app from a browser it just took a second or so to load. So all in all, very good, fast and reactive times and I also made use of the hot directory, webapps/, for my app deployment which I always like using when writing apps.

INFO: Deploying web application archive /Users/maples/apache-tomcat-7.0.39/webapps/jenkins.war
Jenkins home directory: /Users/maples/.jenkins found at: $user.home/.jenkins
Apr 17, 2013 11:56:23 AM jenkins.InitReactorRunner$1 onAttained
INFO: Started initialization
Apr 17, 2013 11:56:25 AM jenkins.InitReactorRunner$1 onAttained
INFO: Listed all plugins
Apr 17, 2013 11:56:25 AM jenkins.InitReactorRunner$1 onAttained
INFO: Prepared all plugins
Apr 17, 2013 11:56:25 AM jenkins.InitReactorRunner$1 onAttained
INFO: Started all plugins
Apr 17, 2013 11:56:25 AM jenkins.InitReactorRunner$1 onAttained
INFO: Augmented all extensions
Apr 17, 2013 11:56:25 AM jenkins.InitReactorRunner$1 onAttained
INFO: Loaded all jobs
Apr 17, 2013 11:56:29 AM org.jenkinsci.main.modules.sshd.SSHD start
INFO: Started SSHD at port 52972
Apr 17, 2013 11:56:29 AM jenkins.InitReactorRunner$1 onAttained
INFO: Completed initialization
Apr 17, 2013 11:56:29 AM hudson.TcpSlaveAgentListener
INFO: JNLP slave agent listener started on TCP port 52973
Apr 17, 2013 11:56:30 AM hudson.WebAppMain$2 run
INFO: Jenkins is fully up and running

Note, don’t try this through the admin manager, as I was just over the size limit! D’oh!

org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because its size (53863971) exceeds the configured maximum (52428800)

Tooling support – how good is the best, how good is the worst

The big three IDEs, Eclipse, IntelliJ IDEA and Netbeans, all have integration support for Tomcat out the box. This means you can import a server into the tooling and deploy projects onto the server. NetBeans offers a distribution which wraps a Tomcat image so that you can deploy as soon as NetBeans installs :o) Eclipse also has the additional download feature which allows you to download and install Tomcat from within your tooling, meaning you don’t have to do it via a browser and later import it.

Tomcat seems to be very tightly integrated with Ant. It’s easy to link taskdefs to Tomcat classes and then drive them, as shown below:

  <taskdef name="deploy"    classname="org.apache.catalina.ant.DeployTask"/>
  <taskdef name="list"      classname="org.apache.catalina.ant.ListTask"/>
  <taskdef name="reload"    classname="org.apache.catalina.ant.ReloadTask"/>
  <taskdef name="findleaks" classname="org.apache.catalina.ant.FindLeaksTask"/>
  <taskdef name="resources" classname="org.apache.catalina.ant.ResourcesTask"/>
  <taskdef name="start"     classname="org.apache.catalina.ant.StartTask"/>
  <taskdef name="stop"      classname="org.apache.catalina.ant.StopTask"/>
  <taskdef name="undeploy"  classname="org.apache.catalina.ant.UndeployTask"/>

  <target name="deploy" description="Install web application" depends="compile">
    <deploy url="${url}" username="${username}" password="${password}"
            path="${path}" war="file:${build}${path}.war"/>

Open standard’s compliance

As Tomcat is very lightweight the standards of interest it supports are Servlet 3.0 and JSP 2.2 standards. A common practice is to use tomcat as a base and extend it with whichever packages of function they require. This typically results in projects like OpenEJB and OpenJPA and others being gaffer taped to the side and plastering over the top. This works and many people run like this, but they need to maintain the gaffer tape themselves. So the Open standards compliance really comes from the decisions which the user makes. This is now a great point to switch and talk about TomEE (pronounced Tommy).

TomEE (pron. Tommy)

TomEE is also an Apache born project which does all of the integration work described above for you and provides an “all-Apache stack aimed at Java EE 6 Web Profile certification where Tomcat is top dog”. The last part is key, as the flavour of this project is very much to keep the Tomcat look and feel, experience, performance as close as possible while providing the extra functionality some Tomcat users would like out the box.

appache tomEE

There are two distributions currently available, TomEE and TomEE+ which provide the following feature set:

TomEE – WebProfile version

The Web Profile (35.9MB download) version of TomEE contains

CDI – Apache OpenWebBeans
EJB – Apache OpenEJB
JPA – Apache OpenJPA
JSF – Apache MyFaces
JSP – Apache Tomcat
JSTL – Apache Tomcat
JTA – Apache Geronimo Transaction
Servlet – Apache Tomcat
Javamail – Apache Geronimo JavaMail
Bean Validation – Apache BVal

TomEE+ (55.2 MB download) – Contains Tomcat, plus…

JAX-RS – Apache CXF
JAX-WS – Apache CXF
JMS – Apache ActiveMQ
Connector – Apache Geronimo Connector

These features don’t run on top of Tomcat without integration, they make use of Tomcat’s underlying infrastructure, for example, servlets now get access to JPA and Transactions, EJBs get access to Tomcat provided Security. Any Tomcat provided resources, say from a context.xml, can be looked up or injected by any managed component in the system.

These are great additions to tomcat which make it an attractive offering for the more enterprisey applications. I attended a DevoxxFr presentation on TomEE by David Blevins, who incidentally used to work on the IBM Liberty Profile team, and listened to him explain that TomEE doesn’t try to only run exactly what your app needs. Instead components should be so fast and lightweight you don’t even notice them being loaded, and if that’s not the case, then a problem exists which needs to be fixed. I found this interesting as it takes the opposite direction to the Liberty Profile’s ‘use only what you need’ approach. But TomEE isn’t out to change how Tomcat works, it’s there to bolster it with the functionality an Enterprise developer needs.

User Interface

Tomcat provides an administrative webapp called the manager app out the box. You’ll need to configure the conf/tomcatusers.xml file to grant access to roles first as access is gated. This is a nice feature as it provides different roles for different levels of admins. The manager-status only let’s you view the server status page, where as the manager-gui role gives full access to the web interface. There are others that allow scripting and JMX access as well. The manager app isn’t flashy or anything special, but let’s you do what you need, from application deployments and changes to listing OS and JVM properties.

Config Changes

Configuration in Tomcat is scattered across a number of files in the tomcat/conf directory but mainly resides in the server.xml file. This file can be modular to allow reuse and sharing across a development team. If you wanted to make a quick change, perhaps one that needed to be undone on next restart for a test, the best way is to add a system property when starting the JVM up as system properties override xml configuration. It’s important to note that with tomcat everything is up and running. There is no modular environment where you start what you need. But hey, it’s all fast, so is it a problem? Not really.

I find the configuration very verbose, but this is actually mostly commented ‘how-to’s. This is great when you’re just starting to use Tomcat as the server.xml contains a bunch of example configuration that you’d simply uncomment when you needed to do something similar rather than have to google for docs or someone else’s example. I imagine this verbosity is as useful to new starters as it is annoying to super users who don’t want examples and would prefer a clean server.xml. If you look at the active lines of xml, it’s actually a very small file.

Every server.xml file will require you to recycle the server as the configuration files are only checked by the core runtime during server startup. Let’s look at a simple config change. In our Jetty post we changed the server HTTP port, so lets look at the same config in Tomcat, changing our port to 8888:

<Connector port="8888" protocol="HTTP/1.1" 
               redirectPort="8443" />

TomEE introduces native feature config to the mix as well. This means that if you choose to use and configure certain features that are bundled in TomEE, you’ll need to configure them in their own config file in the conf directory, which isn’t ideal.

Documentation & Support

The documentation for Tomcat is very good (particularly for new users) as is supported from a vast community. This community is where the Tomcat support comes from, both as descriptive help as well as code changes and bug fixes. Most people will be comfortable with this, but if you need more of a guarantee, there are vendor support contracts available, which very often include Tomcat committers and often do a lot of testing for you.

TomEE docs are reasonable but clearly the community is much smaller, so you might not get the same kind of response times 24/7. That being said, because TomEE bases itself on the Tomcat runtime, if you find a base bug, you’re still leaning on the good ol’ Tomcat folks for assistance.

Things that didn’t fit into other sections

There are many Tomcat embedders out there that you should also consider if you wanted to look into Tomcat, namely (TomEE!), SpringSource tc server and Tcat. A developer would typically be very happy to work with Tomcat or any of it’s embedders, typically because it has become somewhat the industry standard for a lightweight, fast container.

Tomcat is free to use in development and production and has a very nice Apache 2 license. Free? Well that’s an interesting term, as it depends on who is asking. If you were to ask the finance team which buy licenses, yes it’s free. But asking the support managers and infrastructure teams and you may get a slightly different answer as there are always costs involved to host, run and maintain a stable platform which may have been put together piece by piece by an internal team. Changes are inevitable which involve testing and migration – this does not come for free!


It’s easy to see why Tomcat has grown in popularity to be the most popular application server around the world today. Tomcat has been around for a fair time now, with it’s very stable runtime and large, responsive community, including other vendors basing their products on the Tomcat core. It’s fast has has good tooling built into many IDEs but for me it lacks in it’s config. Yes, if you’re used to Tomcat and have used it for a while it may not be a problem, but having worked for IBM and seeing how the WebSphere config structure/mess has shrunk into a single file, I believe Tomcat has a fair bit of room for improvement. If IBM can do it… ;o)

The support is community based, but as mentioned if you need more, there are guaranteed vendor contracts that are available. The final big plus for Tomcat is the price. It’s free and opensource – that’s awesome! Everything open source is great, right?…..