The container container for Tomcat architecture analysis

Tomcat provides four kinds of containers for engine,host,context and wrapper. The containment relationship between them has been elaborated in the overall structure. These four containers inherit a container base class, so they can be customized. Of course, Tomcat also provides a standard implementation. Engine:org.apache.catalina.core.StandardEngine Host:org.apache.catalina.core.StandardHost Context:org.apache.catalina.core.StandardContext Wrapper:org.apache.catalina.core.StandardWrapper

The so-called container is that it carries a number of logical units and runtime data. Like, the entire hotel is a container, it contains the various floors and other facilities, each floor is also a container, it contains the various rooms, each room is also a container, it contains a variety of home appliances and so on.
First, consider the class structure of the container class.

base class Containerbase
Containerbase is an abstract base class. Its classpath is: Java code org.apache.catalina.core.ContainerBase

Here are just a few of the components and methods for comparing core functions. It is important to note that there are many methods and properties in the class, which are limited to the length of the list.
Enigne
The engine is the topmost container, which is a combination of the host container. Its standard implementation class is: Java code org.apache.catalina.core.StandardEngine

Take a look at the main logical unit concept diagram for Standardengine.

As you can see from the diagram, the engine has four components: Cluster: The ability to implement Tomcat clusters, such as session sharing, can be implemented by configuring Server.xml, which is optional for all host applications contained in it. Its implementation is based on the Pipeline+valve model, there is time will be dedicated to a Pipeline+valve mode application series; Realm: Implement User Rights Management module, such as user login, access control, etc. It can be implemented by configuring Server.xml, which is optional for all applications contained in the host, and Pipeline: Here is a brief introduction, followed by a special document description. Each container object has a pipeline, which is not generated by the Server.xml configuration and is required. It is the skeleton of the container object to implement the logical operation, the configuration of different valve on the pipeline, when the need to invoke this container implementation logic, it will be in order to call all Valve on this pipeline once, here can refer to the responsibility chain model; Valve: Implement a specific business logic unit. Valve can be customized (implementing a specific interface) and then configured in Server.xml. Valid for all applications contained in the host. The custom valve is optional, but each container has a default valve, such as the engine's standardenginevalve, which is brought in from the Standardengine, It mainly implements the invocation of the standardhostvalve of its child host object, and so on.

Examples of configurations are: XML code <engine name= "Catalina" defaulthost= "localhost" > <valve classname= "MyValve0"/> <valve classname= "MyValve1"/> <valve classname= "MyValve2"/> ...

It is important to note that the valve array on the pipeline is loaded in the order of configuration, in the runtime environment, but regardless of whether there is a custom-configured valve or how many custom valve, each container default valve, For example, the standardenginevalve of the engine will be the last one in the array.
Host
Host is the child container of the engine, which is a collection of context containers. Its standard implementation class is: Java code org.apache.catalina.core.StandardHost

The core module of Standardhost is similar to Standardengine. Only the scope is not the same, its module is only valid for the child context it contains. In addition to this, there are some special logic, such as the deployment of the context. The deployment of the context is still more, mainly divided into: War Deployment Folder Deployment configuration deployment, etc.

Sometimes I'll say it alone. Stick to a core module concept diagram as usual.

Context
The context is a child container of host, which is a collection of wrapper containers. Its standard implementation class is: Java code org.apache.catalina.core.StandardContext

It should be said that Standardcontext is the largest class in Tomcat. It encapsulates every web app.
Take a look at Standardcontext's main logic unit concept map.

Pipeline,valve,realm is the same as the container above, only the scope is not the same, not much to say. Manager: It is mainly the session management module of the application. Its main functions are session creation, session maintenance, Session persistence (persistence), and cross-context session management. The Manager module can be customized, and Tomcat also gives a standard implementation; Java Code Org.apache.catalina.session.StandardManager

The Manager module is a must-have, can be configured in the Server.xml, if not configured, will generate a manager object in the program. Resources: It is the package of the deployment structure for each Web app, for example, some of the apps are subdirectories in the WebApps directory of Tomcat or other directories configured in the context node, or the structure of the war file deployment. It is required for each web app. Loader: It is an own ClassLoader package for each web App. Specific content related to Tomcat's ClassLoader system, which is described separately in a document. Tomcat is a complete classloader system that ensures that every web app can operate independently, share certain objects, and so on. It is required for each web app. Mapper: It encapsulates the mapping between the request resource URI and each corresponding processing wrapper container.

Take a web app's own XML configuration as an example; <servlet> <servlet-name>httpserver</servlet-name> <servle t-class>com.gearever.servlet.testservlet</servlet-class> </servlet> <servlet-mapping> < ;servlet-name>httpserver</servlet-name> <url-pattern>/*.do</url-pattern> </ Servlet-mapping>

For a Mapper object, it can be abstracted as a map structure whose key is an access resource, such as/*.do, and its value encapsulates a wrapper object that handles the testservlet of the resource. When the/*.do resource is accessed, Testservlet is positioned in the Mapper object. It is particularly noted here that there is only one case for locating a particular wrapper object through this Mapper object, which is used when accessing resources through forward in a servlet or JSP. For example, Java code request.getrequestdispatcher (URL). Forward (request, response)

About the mapper mechanism will be specifically described in a document, here a brief introduction, easy to understand. As shown in the figure.

The Mapper object exists in Tomcat in two places (note, not that only two mapper objects exist), one is each context container object, which only records the mapping of the access resources within this context to the corresponding wrapper sub-containers; is the connector module, which is the Tomcat global variable, which records a complete mapping correspondence, which is the wrapper container that is based on which context is located under which host, depending on how the full URL is accessed.
Thus, the first kind of mapper is used to access the resource through the forward method mentioned above, and in addition, all other ways are handled by the mapper of the second approach to wrapper. That is, forward is a redirect inside the server and does not need to go through the network interface, so it can only be done through in-memory processing. This is what is often said about the forward and the Sendredirect way to redirect the root of the difference.
Take a look at the source code of the Request.getrequestdispatcher (URL) method. Java Code    public requestdispatcher getrequestdispatcher (String path)  {          // Validate the path argument       if  (path == null)         return  (null);       if  (!path.startswith ("/"))         throw new  IllegalArgumentException          (sm.getstring             ("ApplicationContext.requestDispatcher.iae",  path));          // Get query string       string querystring = null;      int pos = path.indexof (' ?’);       if  (pos >= 0) &NBSP;{&NBSP;&NBsp;      querystring = path.substring (pos + 1);        path = path.substring (0, pos);      }          path = normalize (path);      if  ( Path == null)         return  (null);          pos = path.length ();         // use the  thread local URI and mapping data      dispatchdata  dd = dispatchdata.get ();      if  (dd == null)  {         dd = new dispatchdata ();         dispatchdata.set (DD);      }          messagebytes urimb = dd.urimb;      urimb.recycle ();         // Use the thread local mapping data       mappingdata mappingdata = dd.mappingdata;         // map  the URI      charchunk uricc = urimb.getcharchunk ();       try {        uricc.append (Context.getpath (),  0, context.getpath (). Length ());      /*     *  ignore any trailing path params  (separated by  '; ')  for mapping     * purposes     */        int semicolon = path.indexof (';');           if  (Pos > = 0 && semicolon > pos)  {           semicolon = -1;        }         uricc.append (Path, 0, semicolon > 0 ? semicolon : pos);        <span style= "color:  #ff0000;" > context.getmapper (). Map (urimb, mappingdata); </span>        if  (mappingdata.wrapper == null)  {           return  (NULL);        }         /*       * Append any trailing path params  ( separated by  '; ')  that were       * ignored for mapping purposes,  so that&nBsp;they ' re reflected in the       * requestdispatcher ' s  requestURI       */        if  ( semicolon > 0)  {          uricc.append (Path,  semicolon, pos - semicolon);        }      } catch  (exception e)  {       // should  never happen       log (sm.getstring ("ApplicationContext.mapping.error" ),  e);       return  (null);      }          <span style= "color:  #ff0000;" >Wrapper wrapper =  (Wrapper)  mappingData.wrapper; </span>      string wrapperpath = mappingdata.wrApperpath.tostring ();      String pathInfo =  MappingData.pathInfo.toString ();         mappingdata.recycle ();          // construct a requestdispatcher to process this  request      return new ApplicationDispatcher            (<span style= "color:  #ff0000;" >wrapper</span>, uricc.tostring (), wrapperpath, pathinfo,               querystring, null);      }   

The red section of

marks the wrapper child container from the Mapper object in the context and encapsulates it inside a dispatcher object and returns. The above explanation also explains why the forward method cannot access resources across the context. The

Wrapper
Wrapper is a child container of the context that encapsulates each specific servlet that handles the resource. Its standard implementation class is: Java code    org.apache.catalina.core.standardwrapper  

The

should say that Standardwrapper is one of the more important classes in Tomcat. When you first know it, it is easier to confuse.
Take a look at the main logical unit concept diagram of Standardwrapper first.  

Pipeline,valve the same as the container above, except that the scope is not the same, not much. The
mainly speaks of the Servlet object and the Servlet stack object. These two objects only exist in the wrapper container, meaning that only one of them is not empty. When a Servlet object exists, this servlet is supported for multi-threaded concurrent access, that is, there is no process for thread synchronization, this wrapper container contains only one Servlet object (this is our common pattern), and when the servlet stack object exists, Note that servlets do not support multithreaded concurrent access, and only one thread can invoke each Servlet object at any one time, so that the servlet stack implements a simple thread pool that contains only a set of Servlet objects in the wrapper container. Its basic prototype is the worker thread pattern implementation.  
So, how do you decide whether to store it as a Servlet object or as a servlet stack? In fact, as long as the servlet class is developed, a Singlethreadmodel interface can be implemented.
If a servlet class is required for thread synchronization, for example: Java code    public class loginservlet extends httpservlet  implements javax.servlet.SingleThreadModel{ ...... }  

However, it is important to note that this synchronization mechanism is only a function from the servlet specification point of view, in the actual application does not completely solve the thread security problem, for example, if there is static data access in the servlet, so if the thread security is more stringent, It is best to use some other custom solutions.

The basic function of wrapper has been said. Then again a wrapper more important concept. Strictly speaking, not every access resource corresponds to a wrapper object. Instead, each access resource corresponds to a wrapper object. It can be broadly divided into three types: a wrapper that handles static resources: wrapper for static resources such as Html,jpg, which contains a tomcat implementation of the default servlet that handles static resources:

Java Code Org.apache.catalina.servlets.DefaultServlet

A wrapper that handles a JSP: for example, all of the JSP files accessed, which contains a tomcat implementation that handles the JSP's default servlet:

Java Code Org.apache.jasper.servlet.JspServlet