Structure of Tomcat Research
Hello everyone, the last article introduced the "ClassLoader of Tomcat Research", this article introduces the component structure
In the premise of any substantive data, it will be very difficult to study Tomcat, but no matter how OpenSource, we can at least track Tomcat hundred thousand classes, in order to completely solve Tomcat's veil, we Still to continue to work hard.
It is not difficult to see through the UML class diagram. The most important classes in the core package are ContainerBase, and this abstract class implements the Container, Lifecycle, Pipeline, MBeanRegistration, Serializable interface, the Serializable interface, everyone is very familiar, we focus on the study Interface, because we guess the partial architecture of the entire Tomcat may be built on these foundation interfaces.
Before entering the analysis, we recall the config.xml (server.xml) file, from this file and Apache document, we can understand that the Tomcat macro has the following components:
- Server Server Elements are the entry point of JVM, only one of the entire configuration file, because Server is not a container, so you can't nested subcomponents. Services in a specified port. Server can contain one or more services real.
- Service Service has one or more Connectors shared with the same container, and the general service is an engine, but there is no clear specification. Because Service is not a Container, it is not a nesting of subcomponents (such as loggers / valves).
- Connector Connector is a Tomcat and client connection, Tomcat has two typical Connector: HTTP, JK2.http Connector listening to the connection from Browser (usually in our familiar 8080 port), JK2. Requests from other WebServer (default 8009 port listens). The Connector will hand over the obtained request to the ENGINE process.
- Multiple virtual host Virtual Host can be configured under Engine Engine, each virtual host has a domain name when eNGINE gets a request, matches the request to a host, then hand it over to the host to handle Engine There is a default virtual host that will handle the default Host to handle it when the request cannot match any Host.
- Host Host represents a virtual host, default is localhost, Host can deploy multiple web applications, usually consider the problem in our practical application is Host
Org.apache.catalina.lifecycle
A generic component declaration cycle interface, the general Tomcat components must implement this interface (but not necessarily), this interface provides the same START and STOP for all components. The main methods are:
// Add a listener
Public void addlifecycleclelistener (LifecycleListener Listener);
/ **
* This method should be called before any public method is called
* This method sends a START_EVENT event to all registration to
* The listener of this component
* /
Public void start () throws lifeclecleException;
/ **
* This method should be called after all public methods are called
* This method sends a STOP_EVENT event to all registration to
* The listener of this component
* /
Public void stop () throws lifecycleException;
2. Org.apache.catalina. LifecyCleListener This interface is used to listen to some important events (including START, STOP events generated by the LifecyCle interface component)
The main method is:
// Handle the listening event
Public void lifecycleevent (lifecleelent evenet);
3. Org.apache.catalina.Container
The container is an object for acquiring requests from the client and processing requests and replying to the client (response). The container can support (optional) PIPELINE to process requests in the order of configuration at runtime.
In Tomcat, the container exists in the concept:
Engine requests to process entry points, which can contain multiple hosts and context
Host represents a virtual host
Context represents a single servletContext, you can include multiple Wrappers
Wrapper represents a single servlet, if the servlet implements SingLethReadModel, you can represent multiple instances of a single servlet.
Containers In order to implement their own features, some other components are often bound, and these components can be shared, or they can be customized separately, the following is the components used:
Loader ClassLoader, loading java classes
Logger implements the log method of servletContext, used to record the log
Manager manages session pool bound to container binding
Realm User Safety Management
Resources JNDI Resource Access
Main method:
// increase container listener
Public void AddContainerListener (ContainerListener Listener);
// Add Property listener
Public Void AddPropertyChangelistener (PropertyChangelistener Listener);
/ **
* Handling Request and generates corresponding RESPONSE
* Pram Request processing request
* Seponse generated by param Response
* /
Public Void Invoke (Request Request, Response Response) throws oException, servletexception;
4. Org.apache.catalina. ContainerListener
Container event listener, note that START, STOP is a normal lifecycle event (liftcycleevent) is not a container event. Main method:
// Treat container event
Public void containerevent (containerevent eve);
5. Org.apache.catalina. Pipeline
PIPLINE is a collection of Valve. When the Invoke method is called, it calls Valve in the specified order, which always requires a Valve must handle the transferred request (generally the last one) and generate Response, otherwise passing the request to Next Valve.
Generally, a container only binds a PIPLINE instance. Generally speaking that the container encapsulates the feature of the request to a container bound (this VALVE should be performed in PipleLine). To accomplish this feature, PipleLine provides a setbasic () method to ensure that Valve is executed, while other Valve is called in order. 6. Org.apache.catalina.valve
Valve is a request processing component that is bound to a Container, and a set of Valve is bound in a pipleline. The most important way for Valve is:
/ **
* A Valve may perform the following action in a certain order
* 1. Check and (or) Modify the specified request and response properties
* 2. Check the request attribute to generate the corresponding response and return to the control to the caller.
* 3. Check the request and reponse properties, pack these objects and enhance their features, then pass them
To the next component
* 4. If the corresponding response is not generated (and the control is not returned) call pipleline
The next Valve (if any) through method context.invokenext ()
* 5. Check (but do not modify) the response property (call the Valve or Container generated later)
* Valve must not make the following things
* 1. Change some properties of Request (Change Request Properties That Have
Already Been Used to Direct The Flow Of Processing Control
for this request)
* 2. Create a response that has been created and has been passed
* 3. Invokenext () method and return to modify HTTP header information containing Response
* 4. Invokenext () calls return to any call on the output stream of the bound Response
* @ param request will be processed Request
* @ param response will be created Response
* @ param context is used to call the next Valve's Valve Context
Public Void Invoke (Request Request, Response Response,
ValveContext context)
THROWS IOEXCEPTION, SERVLETEXCEPTION;
7. Org.apache.catalina.valveContext
A ValveContext is a mechanism: a Valve can trigger the next Valve call, and do not have to know the internal implementation of the mechanism.
8. Org.apache.catalina.Engine
Engine is a container that is the entry point of the servlet of Cataline.
When publishing a Cataline connected to Web Server, you may not use Engine, because Connectior will use the resource of Web Server to determine which context handles Request.
Sub-containers attached to ENGINE may be Host or Context (single servlet context) according to the different ENGINE implementation.
If eNGine is used, it is a top container in the level of Cataline, so setParent () should throw an IllegaLaRgumentException exception. From the following methods below, we can see its structure:
/ **
* Setting the successful service * @Param Service The Service That OWNS this Engine
* /
Public void setservice; service service;
/ **
* Set the default hostname for this Engine.
*
* @Param defaulthost the new default host
* /
Public void setDefaulthost (string defaulthost);
/ **
* Set the defaultContext
* for new web applications.
*
* @Param DefaultContext The New DefaultContext
* /
Public Void AddDefaultContext (DefaultContext Default ";
ORG.APache.catalina. Host
Host is a container that represents a virtual host.
When you release a Cataline connected to Web Server, you may not use Host, because Connectior will use the resource of Web Server to determine which context process processing request.
The parent container attached to Host is usually engine, and the subs containers attached to Host are usually Context (single servlet context).
The method in the Host interface is mostly about modifying the Host property and setting the default Context. Here we no longer be listed one by one.
10. Org.apache.catalin. Context
Context is a container that represents a servletContext, a single Web Application in a Cataline Engline. The parent container attached to Context is HOST, which is affiliated with Context is Wrapper (Representing a single servlet). Most of the Context interface is a method for setting up the Web Application. We can refer to the method in the Web.xml file study, how many methods are how to read the resources in the web.xml file.
11. Org.apache.catalina.wrapper
Wrapper is a container that represents a single servlet. Wrapper Management Servlet lifecycle, including calling init () and destory () methods.
The parent container attached to Wrapper is Context, and there is no sub-container attached to Wrapper.
The way in the Wrapper interface is about reading the properties of the servlet, you can refer to the definition of the
12. Org.apache.catalina.Server
Server is the entry point of the entire Catalina container, which can contain multiple service and top resource elements. Generally speaking, a class that implements a Server interface should also implement a LifecyCle interface, and call the Service corresponding to the START () and STOP () methods.
Server is responsible for listening to the specified port. When there is a connection being accepted, Server analyzes the first line of requests, if it is ShutDown, STOP service. You can refer to the Server.xml file for the definition of Server.
13. Org.apache.catalina. Service
Service is a collection of Connectiors with Container. JVM can contain one or more service instances, but they are completely independent, they only share the resources of JVM.
14. Org.apache.catalina. Connector
The Connector is a component that receives requests from the client and generates a response. A Connection usually performs the following logic:
1) Accept request from client program
2) Create Request and Response and set the following attributes to these objects.
(1) To all Request, Connector, Protocol, Protocol, Response, Scheme, Secure, ServerName, Serverport, the ServerPort property must be set. ContentLength, ContentType is usually also set.
3) Alternate to all httpRequests, Method, QueryString, RequestedSessionCookie, RequestedSessionId, RequestedSessionURL, Requesturi, and secure properties must be set. Another ADDXXX method must also be called to record cookies, headers, and locals information.
4) For all Responses property connectors, request, Stream properties must be set.
For httpresponses, Connector does not set additional Headers information for it.
Tomcat overall architecture
The next article will introduce Tomcat from the various components of Tomcat.
