What is Tomcat? The original Java servlet container – InfoWorld

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 on the four ways to deploy a Java application with 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 will have the 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 you’ll go to 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 would simply enter a command like

wget https://downloads.apache.org/tomcat/tomcat-10/v<VER>/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

Tomcat. /

• webapps is the location where you will deploy the applications

.

• /logs is where Tomcat generates its logs. Note that Tomcat logs enter /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 you will 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.

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” without arguments to see all available commands.) You should now be able to navigate to the Tomcat welcome screen in a browser, as shown in Figure 1.

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, which means that it still contains all the elements arranged in directories and files. The Tomcat file you unpacked shipped with several examples implemented 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’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 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.