Tomcat Architecture and Configuration

Inside tomcat, there are a lot .xml configurations. like server.xml, context.xml, web.xml.  For each Config File, it could be placed in different places. Today, I found one useful diagram which explain the tiered layout of tomcat architecture. it’s provided by marakana. I will provide more details from the perspective of programmers.

Tomcat Listener: 

A Listener element defines a component that performs actions when specific events occur, usually Tomcat starting or Tomcat stopping. Listeners may be nested inside a Server, Engine, Host or Context. Some Listeners are only intended to be nested inside specific elements. These constraints are noted in the documentation below.

HERE are all the listener implementations, Listener interface only has one method. LifeCycleEvent public abstract interface LifecycleListener {   public abstract void lifecycleEvent(LifecycleEvent paramLifecycleEvent); }

Services:
 

A "Service" is a collection of one or more "Connectors" that share a single "Container" Note:  A "Service" is not itself a "Container", so you may not define subcomponents such as "Valves" at this level

A Service element represents the combination of one or more Connector components that share a single Engine component for processing incoming requests. One or more Service elements may be nested inside a Server element
 

Connectors:

Connectors that allow browsers to connect directly to the Tomcat and connectors that do it through a Web Server. typically will be http connector and AJP connector (connect through web server like IIS or Apache.)
   each connector has a thread settings.(shared thread executor pool)

Each incoming request requires a thread for the duration of that request. If more simultaneous requests are received than can be handled by the currently available request processing threads, additional threads will be created up to the configured maximum (the value of the maxThreads attribute). If still more simultaneous requests are received, they are stacked up inside the server socket created by the Connector, up to the configured maximum (the value of the acceptCount attribute. Any further simultaneous requests will receive "connection refused" errors, until resources are available to process them
 

So each connector take care different protocols.
 

Engines:

The Engine element represents the entire request processing machinery associated with a particular Catalina Service. It receives and processes all requests from one or more Connectors, and returns the completed response to the Connector for ultimate transmission back to the client.

Exactly one Engine element MUST be nested inside a Service element, following all of the corresponding Connector elements associated with this Service.

each engine has several HOSts, and Also Engine can be routed via jvmroutes> By default, it use the StandEngine.

Hosts:

The Host element represents a virtual host, which is an association of a network name for a server (such as "www.mycompany.com" with the particular server on which Catalina is running. In order to be effective, this name must be registered in the Domain Name Service (DNS) server that manages the Internet domain you belong to - contact your Network Administrator for more information.

In many cases, System Administrators wish to associate more than one network name (such as www.mycompany.com and company.com) with the same virtual host and applications. This can be accomplished using the Host Name Aliases feature discussed below.

One or more Host elements are nested inside an Engine element. Inside the Host element, you can nest Context elements for the web applications associated with this virtual host. Exactly one of the Hosts associated with each Engine MUST have a name matching the defaultHost attribute of that Engine.

Host Maps URl to Contexts.

Contexts:

The Context element represents a web application, which is run within a particular virtual host. Each web application is based on a Web Application Archive (WAR) file, or a corresponding directory containing the corresponding unpacked contents, as described in the Servlet Specification (version 2.2 or later). For more information about web application archives, you can download the Servlet Specification, and review the Tomcat Application Developer's Guide.

The web application used to process each HTTP request is selected by Catalina based on matching the longest possible prefix of the Request URI against the context path of each defined Context. Once selected, that Context will select an appropriate servlet to process the incoming request, according to the servlet mappings defined in the web application deployment descriptor file (which MUST be located at /WEB-INF/web.xml within the web app's directory hierarchy).

there are two contexts implementation in tomcat, standard vs the replicated. (Tomcat Clustering. session state keep sync between different contexts across different HOSTs)

Context takes care the Filters, JSPS.  the final logic executio of all JSPs, like welcome page. watched resource. serverlet mappings.  status page mappings. all those configurations in web.xml located in web-inf

Valves:

A Valve element represents a component that will be inserted into the request processing pipeline for the associated Catalina container (Engine, Host, or Context). Individual Valves have distinct processing capabilities, and are described individually below.

there are a lot of vales available in tomcat, like AccessLog , Authenticator. JVMrouting.