Apache Tomcat is a long-lived, open source Java servlet container that implements core Java enterprise (now Jakarta EE) specifications, including the Jakarta Servlet, Jakarta Server Pages, and Jakarta WebSocket specs.
Tomcat was first released by the Apache Software Foundation in 1998, just four years after Java itself. Tomcat started as the reference implementation for the original Java Servlet API and JavaServer Pages specification. Today, it remains the most widely used Java application server, boasting a well-tested and proven core engine with good extensibility.
In this short introduction, you'll learn why many developers choose Tomcat for running Java web applications. You'll get an overview of Tomcat and how it's used, installation instructions, and a brief guide to the four ways to deploy a Java application using Tomcat.
Is Tomcat an app server or a web server?
The Java ecosystem supports several kinds of application server:
- A servlet container is an implementation of the Jakarta Servlet specification, used primarily for hosting servlets.
- A web server is a server designed to serve files from the local system, like Apache.
- A Java enterprise application server is a full-blown implementation of the Jakarta EE specification.
At heart, Tomcat is a servlet and JSP container:
- A Java (or Jakarta) servlet defines endpoints for HTTP requests and routes them to business logic code for handling.
- JSP, or Jakarta Server Pages, is a server-side view-rendering technology that allows defining HTML interfaces using data from inside the server and information from the request and response. As the developer, you write the servlet or JSP page, define rules for the requests and responses, then let Tomcat handle the routing.
Tomcat also contains the Coyote web server. Coyote makes it possible to use Tomcat to serve static files in combination with Apache web server (more about that shortly).
An extended version of Tomcat, called TomEE, includes a wider variety of Jakarta specifications and capabilities, including the Jakarta Persistence API. (TomEE is Jakarta Web Profile 9.1 certified.)
Next, we'll look at how to use Tomcat to host servlets and JSPs.
Download and install Tomcat
Being a hoary ancient of the software world, Tomcat has several active versions available. For most purposes, you can just use the latest stable version.
To get started, download the latest version of Tomcat. You'll have a choice of downloading Tomcat as an archive (.zip or tar.gz), or as an installed service. The best choice is up to you unless you are not running on Windows, in which case you'll go for the archive. We'll use the archive for this article.
You can also download the archive at the command line with a tool like wget. In this case, you'd just enter a command like
wget https://downloads.apache.org/tomcat/tomcat-10/v<VER>/bin/apache-tomcat-<VER>.tar.g
where <VER> is the version you want.
Windows installation for Tomcat
The following instructions assume you are installing from an archive. If you are running Windows and want to use the installer, simply download the .exe file and run it. Tomcat will install itself as a service with reasonable defaults. It will then inform you of where the install is, and you can proceed as though you had unpacked the archive there.
Step 1. Command-line installation
Go to the command-line and type gunzip apache-tomcat-10.0.22.tar.gz followed by tar -xf apache-tomcat-10.0.22.tar. This command creates the following directories:
- /bin contains the scripts for executing Tomcat.
- /webapps is the location where you will deploy your applications.
- /logs is where Tomcat outputs its logs. Note that Tomcat's logs go into
/logs/catalina.outby default. You can use this file to debug problems in conjunction with application-specific log files. - /lib is where Tomcat looks for JARs. This is where you'll store additional packages not included with Tomcat, such as JPA.
- /conf is the config XML for Tomcat, where you can do things like adding users and roles for Tomcat.
Step 2. Start Tomcat
If you installed Tomcat as a service, it is already running. Otherwise, go ahead and start it up by entering ./catalina.sh start at the command line. (Type "./catalina.sh" with no arguments to see all of the available commands.) Now, you should be able to browse to Tomcat's welcome screen in a browser, as shown in Figure 1.
Figure 1. The Tomcat welcome page.
How to deploy an application in Tomcat
Tomcat's webapps directory is where you will deploy your applications. You can drop a .war file there and Tomcat will run it. A .war file is the standard packaging for a web application resource; it is essentially a Java archive (.jar) file with some additional files telling the container how to run it.
Next, we'll look at three additional ways to deploy static files and web applications in Tomcat.
Exploded deploy
An "exploded" web application is one that isn't compressed into a .war file, meaning it still contains all the elements laid out in directories and files. The Tomcat archive you unpacked shipped with several examples deployed in this manner, which you'll find in the /webapps/examples directory. The advantage of an exploded deploy is you can look at the files there without worrying about compression.
If you navigate to http://localhost:8080/examples, you'll find a list of links. This page is rendered by Tomcat from the /webapps/examples/index.html file. Tomcat is serving an HTML file from the file system, which is an instance of Tomcat's Coyote engine acting as a web server.
The examples on this page provide a good overview of Tomcat's capabilities for serving servlets, JSPs, and WebSockets. Tomcat also includes a management application by default, found under the /manager path. Among other things, this application allows you to start, stop, and redeploy applications from a web console.
Reverse proxy with Tomcat
Tomcat can serve static files off the disk (and offers the APR library for doing so more efficiently) but it's also quite common to combine Tomcat with the flagship Apache web server (httpd) for static files.
There are a couple of ways to use Tomcat and the Apache server together. The first is what’s known as a “reverse proxy,” wherein Apache handles the requests for static files and then hands off other resource requests (/webapp/**, for example) to Tomcat. The Apache server then passes the response back to the client. This is really just a proxy, but it’s called a reverse proxy to distinguish it from the typical client-side role of a proxy.
It isn't difficult to arrange a reverse proxy by setting up the Apache config file. A simple config is found here.
Another approach is to use what’s called AJP (Apache JServe Protocol), which makes it easier to deal with metadata-like headers. AJP has the same architecture setup (apache<->Tomcat) and qualifies as a reverse proxy. This approach avoids some manual wrangling but requires more configuration up front. You can learn more about AJP here.
Similar setups are possible with MicroSoft IIS.
Embedded Tomcat
For a long time, Jetty was the only server capable of running as an embedded server. That has changed, and now Tomcat can also run embedded. The idea in using an embedded server is that instead of the server containing the application files, as you've seen so far, you have an application with a main class (that is, a standalone Java application), that invokes the server capabilities from inside its code base. Overall, this offers a more simple and portable development model, and has rapidly become the norm. (Spring Boot, for example, uses an embedded Tomcat instance running in dev mode.)
Running an embedded server can net simplicity in terms of operations, since you are now dealing with just a single component (the application) instead of both the application and a server deployment. On the other hand, the setup where Tomcat runs as an independent host is still very common.
To run Tomcat embedded, you include the server libraries via a dependency manager like Maven or Gradle. Then, you programmatically start the server in-code, as shown in Listing 1.
Listing 1. Embedded Tomcat
package foo;
import java.io.File;
import org.apache.catalina.WebResourceRoot;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.startup.Tomcat;
import org.apache.catalina.webresources.DirResourceSet;
import org.apache.catalina.webresources.StandardRoot;
public class Main {
public static void main(String[] args) throws Exception {
Tomcat tomcat = new Tomcat();
tomcat.setPort(Integer.valueOf(8080));
StandardContext ctx = (StandardContext) tomcat.addWebapp("/", new File("src/main/webapp/").getAbsolutePath());
File additionWebInfClasses = new File("target/classes");
WebResourceRoot resources = new StandardRoot(ctx);
resources.addPreResources(new DirResourceSet(resources, "/WEB-INF/classes",
additionWebInfClasses.getAbsolutePath(), "/"));
ctx.setResources(resources);
tomcat.start();
tomcat.getServer().await();
}
}
The main point of Listing 1 is to instantiate a Tomcat object and supply it with necessary parameters such as the port to listen on and the location of the application and class files, and then start the server. You can learn more about running Tomcat as an embedded server here.
Tomcat vs. TomEE
If you want to use more of the standard Java EE or Jakarta EE capabilities with Tomcat, one option is to add those libraries to Tomcat or your application dependencies. Another option is using TomEE. TomEE is the same Tomcat engine with additional Java enterprise support, including the popular JPA and CDI APIs. TomEE's specification is based on the Java EE web profile, so it gives you more than Tomcat but isn't a full-blown Java EE application server like WildFly or GlassFish.
How Tomcat compares with other servers
You might wonder how Tomcat compares with other servers. Let’s take a quick look below.
Tomcat vs. Jetty
As an alternative to Tomcat, Jetty tends to focus on performance, while Tomcat focuses on staying up to date with the Jakarta EE specifications. Jetty is also known for popularizing running a servlet container embedded. Like Tomcat, Jetty offers a core servlet/JSP engine that can be extended with plugins. In general, Tomcat remains more popular but both are solid options.
Tomcat vs Nginx
Nginx is a popular, high-performance web server. It is similar to the Apache web server in its capabilities. Nginx can also be used as a reverse-proxy server with Tomcat.
Tomcat vs WildFly
WildFly is Red Hat’s Jakarta EE implementation. It is also a long-running project (previously known as JBoss) and once used Tomcat as its Servlet/JSP container.
Tomcat vs Httpd
Httpd is another name for the Apache web server discussed earlier. Httpd is the process name in Apache web server. You can use this server as a reverse proxy with Tomcat.
Conclusion
Tomcat remains actively developed, keeping pace with change, and delivering a solid and reliable platform for deploying web apps. Both its continued popularity and choice as the default Java platform for many PaaS systems testify to its ongoing success.