Tomcat : Who I am and What I do

5 min readNov 15, 2019

It has been little over an year since I started my career with a software Job. As it is with most software jobs there are things that you can only learn and understand when you get your hands dirty. So in the past one year as a junior developer I got a chance to work with various technologies about which I had no clue of. I will try to share my understanding about these technologies/ topics through these posts so that they don’t go undocumented.

My first Encounter

As with any developer even before you start writing code for your project, it is required that you get your local set up done. It is during one such endeavor that I observed that we were using one peculiar piece of software, on which we ran almost all of our Java based web applications. It was Apache Tomcat. In the beginning I thought that it was a Application server. But I was wrong.

Tomcat an Application Server?

No, Tomcat is not a full fledged application server, though we can do more than just deliver static content using Tomcat, but it doesn’t meet all the requirements of J2EE compliant application server. For instance Tomcat doesn’t support J2EE EJB specification. So currently consider it to be a beefed up version of a Web server or a Servlet Container.
The following table shows the support Tomcat provides out of the Box.

As mentioned in Oracle’s Docs
A Java EE application server, also known as a Java EE container, is any server that is fully compliant with the J2EE or Java EE platforms. Unlike a regular web server, an application server can run full enterprise applications, EJB modules, and web services. It can also manage transactions of persistent entity objects and communicate with databases.

But to know how we our Java applications actually run on Tomcat, it is important that we have an understanding about it’s architecture.

Tomcat and it’s Architecture

Tomcat is developed and maintained by an open community of developers under the belt of the Apache Software Foundation, released under the Apache License 2.0 license.

As mentioned in Apache’s website
The Apache Tomcat software is an open source implementation of the Java Servlet, JavaServer Pages, Java Expression Language and Java WebSocket technologies. It is often categorized as a web Server. Out of all the implementations this post focusses on Catalina which implements Java specifications for servlet and JavaServer Pages (JSP).

Tomcat contains multiple components. But whenever we refer to Tomcat server, we refer to all the components as a whole. Jasper, Cayote, Catalina are some of the main components. But the core component of Tomcat that we are concerned about is the Catalina component which is a Servlet container as it implements Java specification for Servlet API. Whenever we say that we have started our Tomcat it means we have actually started the Catalina instance.

Catalina as a Servlet Container

One of the key requirements worked into the Servlet specification is that they only are expected to handle certain parts of the total data transaction process. For example, the servlet code itself will never listen for requests on a certain port, nor will it communicate directly with a client, nor is it responsible for managing its access to resources. Rather, these things are managed by Tomcat, the servlet container.

Whenever we try to deploy our java application to Tomcat, it searches for the Deployment Descriptor(Web.xml) file which contains information about URL and servlet mappings.
Based on the configuration in deployment descriptor file, Tomcat can load/ initialize the servlet classes on startup or as a response to a request.
When Tomcat receives a request, it decides on which servlet should handle the request.
Once the request has been mapped to the appropriate servlet, Tomcat checks to see if that servlet class has been loaded. If it has not, Tomcat compiles the servlet into Java bytecode, which is executable by the JVM, and creates an instance of the servlet.
Tomcat invokes the service method of the servlet, to handle client’s request.

Apart from web.xml we must remember that there is one more configuration file i.e. server.xml, which has the details regarding what components need to be included in the server, their configuration like what ports to open, how to interconnect them and how to boot up the tomcat instance.

Coyote as a Connector

But aren’t we forgetting something in the first place? Catalina by itself is just a servlet container How does Tomcat even receive the client request? This is facilitated by Tomcat’s connector component — Coyote.

As mentioned in Apache’s website
The Coyote HTTP/1.1 Connector element represents a Connector component that supports the HTTP/1.1 protocol. It enables Catalina to function as a stand-alone web server, in addition to its ability to execute servlets and JSP pages. A particular instance of this component listens for connections on a specific TCP port number on the server. One or more such Connectors can be configured as part of a single service.

Understanding the underlying architecture of Tomcat helps us understand why it can do more than just serve static content.

Why Tomcat?

There are few options an enterprise can choose for their java server solution.
web servers: Jetty, Tomcat
application servers: Glassfish, WebSphere, WildFly.
Even though Tomcat doesn’t provide all the features of an application server like IBM’s WebSphere, it has become the most popular choice for Java application deployments. Mostly due to:

It is Lightweight, with short load and redeploy times
Open source software which has been around for a long time
Tomcat is free, compared to high cost associated with some of the other popular application server solutions
Even for the features that Tomcat doesn’t come with we can include them as external dependencies.
Tomcat is very flexible and extendable — scaling to Enterprise support via TomEE, JBoss, WildFly is possible.
It can be easily integrated with different Java frameworks like Spring.