This page describes how the Tomcat server starts up. There are several different ways to start tomcat, including:
- From the command line.
- From a Java program as an embedded server.
- Automatically as a Windows service.
description
A text description of the startup procedure created for Tomcat 5. The updated version of this description for Tomcat 11 will be included in the updated diagrams and diagram descriptions in the following section. This text file will be removed when that update is complete.
diagram
The UML sequence diagram of the startup procedure created for Tomcat 5 is gradually being replaced with updated diagrams based on Tomcat 11. The scope of these diagrams may be adjusted as they are produced.
A series of UML diagrams have been created to document the start-up process for Tomcat.
Diagram 1 shows an overview of how Tomcat start, serves requests and then stops. Once the class loaders have been initialized, Tomcat parses server.xml using the Digester and the Digester creates the objects defined in server.xml, configures them using the property values defined in server.xml and the starts the Server. The main Java thread waits in the await() method for a shutdown signal. Once a shutdown signal is received, the Server object is stopped and then destroyed. The JVM then exits.
Diagram 2 shows how Tomcat initalizes the objects created by the Digester in the previous step and when additional key objects are created. A Server may have several Services although it typically only has one. Each Service may have multiple Connectors. A Connector instance is associated with a single Protocol instance and a single CoyoteAdapter instance.
Diagram 3 shows how Tomcat starts the objects created by the Digester that were initialized in the previous step. This diagram also shows when lifecycle events are fired. There is more detail to the starting of the Engine (and other Containers) which is shown in the following diagram.
Diagram 4 shows how Containers (Engines, Hosts, Contexts and Wrappers) start along with any supporting Clusters, Realms and Valves.
Diagram 5 shows the start process for Context elements as it is rather more involved that the other Containers.
Diagram 6 shows how the HostConfig component responds to lifecycle events triggered by the Host to deploy web applications to the Host.
Diagram 7 shows how the ContextConfig component responds to lifecycle events triggered by the Context to parse the global and application provided configuration files to create a merged web.xml file that is then used, along with other settings, to configure the web application.
comments
The startup process can be customized in many ways, both by modifying Tomcat code and by implementing your own LifecycleListeners which are then registered in the server.xml configuration file.