Tomcat is an open source lightweight Web application server and an excellent Servlet container implementation. Many developers’ knowledge of Tomcat is limited to running in ide, so this article briefly analyzes the architecture of Tomcat from several aspects in order to have an overall understanding of Tomcat.

Quick learning

Version selection

The 8.5.x release is an intermediate release released after 9.0, with the main architecture continuing from 8.0 and some of the new features of 9.0 being implemented.

Version features:

1. Support Servlet 3.1

Servlet2.X: Project directory structure must have web-INF, WEB. XML folders and files, in WEB. XML configuration servlet,filter,listener, WEB

Servlet 3.x specification: projects can not need web-INF, WEB. XML folders and files, in the absence of WEB. XML files, through annotations to implement servlet, filter, listener declaration, when using annotations, the container automatically scan.

2. NIO is used by default. Remove the BIO

3. Asynchronous log processing improves performance

Therefore, Tomcat 8.5.x is recommended.

Start the way

Download link

Once Tomcat is downloaded locally, it is ready to start. There are two common boot modes:

1. General startup

Run startup under bin\. The IDE encapsulates this step.

2. Embedded boot

You can use the interface provided by Tomcat to invoke methods directly. You can refer to the Boot mode of Spring Boot.

After Tomcat is started, you can access the default Web application page of Tomcat by visiting http://localhost:8080/.

Project deployment

There are two ways to deploy a developed Web project to Tomcat:

1. Implicit deployment

Drop the folder and WAR into the Webapps directory, and Tomcat will automatically convert the war into a folder. Then according to the folder name automatically generated virtual path, after the restart Tomcat, visit http://localhost:8080/filesname to enter.

2. Display the deployment

Add context element

Add a Context to Host in server.xml (specifying path and file address), for example:

The display specifies the virtual path of a WAR package to be accessed through.

Creating an XML file

Create an XML file in conf/Catalina/localhost. The path is the file name, for example:

Create demo. XML in localhost with the following contents:

A summary of the three deployment modes:

Implicit deployment: It can be deployed quickly, but requires people to manually move Web applications into Webapps, which is not very user-friendly in practice.

Add context element: The configuration speed is fast. You need to configure two paths. If path is an empty string, the default value is used. Restart the Tomcat server each time you modify the server.xml file.

Create an XML file: The Tomcat server is automatically deployed on the background. You do not need to start the Tomcat server repeatedly.

It is important to note that restarts are generally encouraged (the JVM may generate errors when a new file is deployed).

The directory structure

Decompress Tomcat to see its directory structure. Here are some of the most common ones:

1.bin

Bat /sh file and invoke the catalina.bat batch file.

Catalina, really start Tomcat file, you can set JVM parameters in it.

2.conf

Server. XML: the most common Tomcat configuration file used to deploy WebApp.

web.xml : The default deployment description file for all applications in Tomcat defines basic servlets and MIME mappings (mime-mapping file types). If the deployed application does not contain web. XML, Tomcat will use this file to initialize the deployment description. Tomcat merges the default description with the defined description configuration at startup.

3.lib

For dependencies that are common to all projects, project personalization imports the current project through Maven.

4.work

When a client user accesses a JSP file, Tomcat generates a Java file from the JSP, and then compiles the Java file to generate a class file. The generated Java and class files are stored in this directory.

Component architecture

Once you’ve looked at Tomcat’s shell, you should take a look at how it works. Let’s start with a structure:

The topmost container in Tomcat is Server, which represents the entire Server. A Server can have multiple services. Each Service represents a specific Service to be provided.

A Service consists of two parts: Connector and Container. They are used as follows:

  1. Connector handles link related matters and provides Socket and Request and Response related transformations.
  2. Container encapsulates and manages servlets and handles Request requests.

A Service has only one Container, but can have multiple Connectors. This is because a Service can have multiple connections, such as HTTP and HTTPS links. So why separate connections from resources?

To decouple network protocols from containers, the Connector encapsulates the protocols into unified interfaces to facilitate Container operations.

The ability to have multiple Host and multiple Context components was designed to allow Tomcat to deploy multiple Web projects, and is now a legacy of The Times. In today’s prevalent virtualization technology, the way used is often to create multiple virtual hosts, a host with a Tomcat, a Tomcat deployment of an independent project.