Apache Tomcat is a long-lived open source Java servlet container that implements the core specifications of the Java enterprise (now Jakarta EE), including the Jakarta Servlet, Jakarta Server Pages, and Jakarta WebSocket specifications.
Tomcat was first released by the Apache Software Foundation in 1998, just four years after Java. Tomcat began as the reference implementation for the original Java Servlet API and the JavaServer Pages specification. Today, it is still the most widely used Java application server, with a well-tested and proven core engine with good extensibility.
Tomcat and
Jakarta EE
Like other Java enterprise tools, Tomcat has migrated from the original Java EE specification to Jakarta EE. Tomcat 9 and earlier were based on Java EE; Tomcat 10 and later are based in Jakarta USA. All versions of Tomcat 10 and up support renaming the package to jakarta.*. The most recent version at the time of writing is Tomcat 10.0.23.
In this short introduction, you will learn why many developers choose Tomcat to run Java web applications. You’ll get an overview of Tomcat and how to use it, installation instructions, and a brief guide to the four ways to implement a Java application using Tomcat.
Is Tomcat an application server or a web server?
The Java ecosystem supports several types
of application server:A servlet container is an implementation of the
- Jakarta Servlet specification, primarily used to host servlets
- A web server is a server designed to serve files from the local system, such as Apache
- A Java enterprise application server is a complete implementation of the Jakarta EE specification.
.
.
At its core, Tomcat is a
servlet and a JSP container:
- a Java (or Jakarta) servlet defines the 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 you to define HTML interfaces using data from within the server and request and response information. As a developer, you write the servlet or JSP page, define rules for requests and responses, then let Tomcat handle routing.
.
Tomcat also contains the Coyote web server. Coyote makes it possible to use Tomcat to serve static files in combination with the Apache web server (more on this 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 an old of the software world, Tomcat has several active versions available. For most purposes, you can only use the latest stable version.
To get started, download the latest version of Tomcat. You’ll have an option to download Tomcat as a file (.zip or tar.gz), or as an installed service. The best option is up to you unless you’re not running on Windows, in which case ‘ll go for the file. We will use the file for this article.
You can also download the file on the command line with a tool such as wget. In this case, you’d just enter a command like
wget https://downloads.apache.org/tomcat/tomcat-10/v<VIEW>/bin/apache-tomcat-<VER>.tar.g
where <VIEW> is the version you want
. Migrating from Java to Jakarta EE If you migrate from Tomcat 9 to 10, you will need to change any call from java.*
to jakarta
.
*. As an example, javax.servlet-api becomes jakarta.servlet-api. If you are migrating a large project, see the Apache Tomcat migration tool for Jakarta EE.
Installing Windows for Tomcat
The following instructions assume that you are installing from a file. If you are running Windows and want to use the installer, just download the .exe file and run it. Tomcat will be installed as a service with reasonable defaults. It will then inform you of where the installation is, and you can proceed as if you had unzipped the file 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 to run
- webapps is the location where you will deploy the applications
- /logs is where Tomcat generates its logs. Note that Tomcat logs go to /logs/catalina.out by default. You can use this file to debug issues along with application-specific log files.
- /lib is where Tomcat looks for JARs. This is where ‘ll store additional packages not included with Tomcat, such as JPA.
- /conf is the configuration XML for Tomcat, where you can do things like add users and roles for Tomcat.
Tomcat. /
.
Step 2. Start
Tomcat
If you installed Tomcat as a service, it is already running. Otherwise, go ahead and launch it by entering ./catalina.sh startup on the command line. (Type “./catalina.sh” with no arguments to see all available commands.) Now, you should be able to navigate to Tomcat’s welcome screen in a browser, as shown in Figure 1.
Figure 1. The Tomcat welcome page.
How to deploy an application to Tomcat
The Tomcat 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 package for a Web application resource; it’s essentially a Java (.jar) archive file with some extra 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.
Exploited implementation
An “
exploited” web application is one that is not compressed into a .war file, meaning that it still contains all the elements arranged in directories and files. The Tomcat file you unzipped was sent with several examples implemented in this way, which you can find in the /webapps/examples directory. The advantage of an exploited implementation is that you can see the files there without worrying about compression.
If you navigate to http://localhost:8080/examples, you will find a list of links. Tomcat renders this page 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 that acts as a web server.
The examples on this page provide a good overview of Tomcat’s capabilities for serving servlets, JSP, and WebSockets. Tomcat also includes a management application by default, which is located in 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 disk (and
offers the APR library to do so more efficiently) but it is 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 Apache server together. The first is what’s known as a “reverse proxy,” in which Apache handles static file requests and then delivers other resource requests (/webapp/**, for example) to Tomcat. The Apache server then returns the response 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 is not difficult to organize a reverse proxy by configuring the Apache configuration file. Here you will find a simple setup.
Another approach is to use what’s called AJP (Apache JServe Protocol), which makes it easier to handle metadata-like headers. AJP has the same architecture configuration (apache<->Tomcat) and qualifies as a reverse proxy. This approach avoids some manual disputes, but requires more setup up front. You can learn more about AJP here.
Similar configurations are possible with MicroSoft IIS.
Integrated Tomcat
For a long time, Jetty was the only server capable of running as an integrated 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 (i.e. a standalone Java application), which invokes the server’s capabilities from within its codebase. Overall, this offers a simpler and more portable development model, and has quickly become the norm. (Spring Boot, for example, uses an embedded Tomcat instance running in development mode.)
Running an
embedded server can bring simplicity in terms of operations, as it is now a single component (the application) rather than the application and deployment of a server. On the other hand, the configuration in which Tomcat runs as a standalone host is still very common.
To run Tomcat embedded, include the server libraries through a dependency manager such as Maven or Gradle. Then, programmatically start the server in code, as shown in Listing 1.
Listing 1. Integrated 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 provide it with the necessary parameters, such as the port to listen 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 to use TomEE. TomEE is the same Tomcat engine with additional Java enterprise support, including the popular JPA and CDI APIs. The TomEE specification is based on the Java EE web profile, so it gives you more than Tomcat, but it’s not a full Java EE application server like WildFly or GlassFish.
High
availability and clustering
Tomcat supports high availability and clustering. High availability is essentially the ability to fail over to another server instance and re-create the session as if nothing had gone wrong. Clustering is the ability to create multiple versions of the same server to handle high-volume traffic.
How
Tomcat compares to other servers
You may be wondering how Tomcat compares to other servers. Let’s take a quick look below.
Tomcat vs. Tomcat
Jetty As an alternative to Tomcat, Jetty
tends to focus on performance, while Tomcat focuses on keeping up with Jakarta EE specifications. Jetty is also known for popularizing running an integrated servlet container. Like Tomcat, Jetty offers a central servlet/JSP engine that can be extended with plugins. Overall, Tomcat is still more popular, but both are solid options.
Tomcat vs
Nginx
Nginx is a popular and 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 deployment in Jakarta USA. It is also a long-running project (formerly 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 above. Httpd is the name of the process on the Apache web server. You can use this server as a reverse proxy with Tomcat.
Conclusion
Tomcat continues to actively develop, keeping pace with change and offering a robust and reliable platform for deploying web applications. Both its continued popularity and its choice as the default Java platform for many PaaS systems testify to its continued success.
