可以参考：
https://www.cnblogs.com/zhouyuqin/p/5143121.html
架构流程
下面主要介绍几个关键的接口：
1.AccessLog.java（日志）
* Intended for use by a {@link Valve} to indicate that the {@link Valve}
* provides access logging. It is used by the Tomcat internals to identify a
* Valve that logs access requests so requests that are rejected
* earlier in the processing chain can still be added to the access log.
* Implementations of this interface should be robust against the provided
* {@link Request} and {@link Response} objects being null, having null
* attributes or any other 'oddness' that may result from attempting to log
* a request that was almost certainly rejected because it was mal-formed.
2.valve.java(阀门)
* <p>A <b>Valve</b> is a request processing component associated with a
* particular Container. A series of Valves are generally associated with
* each other into a Pipeline. The detailed contract for a Valve is included
* in the description of the <code>invoke()</code> method below.</p>
*
* <b>HISTORICAL NOTE</b>: The "Valve" name was assigned to this concept
* because a valve is what you use in a real world pipeline to control and/or
* modify flows through it.
3.Pipeline .java（管道）
* <p>Interface describing a collection of Valves that should be executed
* in sequence when the <code>invoke()</code> method is invoked. It is
* required that a Valve somewhere in the pipeline (usually the last one)
* must process the request and create the corresponding response, rather
* than trying to pass the request on.</p>
*
* <p>There is generally a single Pipeline instance associated with each
* Container. The container's normal request processing functionality is
* generally encapsulated in a container-specific Valve, which should always
* be executed at the end of a pipeline. To facilitate this, the
* <code>setBasic()</code> method is provided to set the Valve instance that
* will always be executed last. Other Valves will be executed in the order
* that they were added, before the basic Valve is executed.</p>
4.Container.java（容器）
* A <b>Container</b> is an object that can execute requests received from
* a client, and return responses based on those requests. A Container may
* optionally support a pipeline of Valves that process the request in an
* order configured at runtime, by implementing the <b>Pipeline</b> interface
* as well.
* <p>
* Containers will exist at several conceptual levels within Catalina. The
* following examples represent common cases:
* <ul>
* <li><b>Engine</b> - Representation of the entire Catalina servlet engine,
* most likely containing one or more subcontainers that are either Host
* or Context implementations, or other custom groups.
* <li><b>Host</b> - Representation of a virtual host containing a number
* of Contexts.
* <li><b>Context</b> - Representation of a single ServletContext, which will
* typically contain one or more Wrappers for the supported servlets.
* <li><b>Wrapper</b> - Representation of an individual servlet definition
* (which may support multiple servlet instances if the servlet itself
* implements SingleThreadModel).
* </ul>
* A given deployment of Catalina need not include Containers at all of the
* levels described above. For example, an administration application
* embedded within a network device (such as a router) might only contain
* a single Context and a few Wrappers, or even a single Wrapper if the
* application is relatively small. Therefore, Container implementations
* need to be designed so that they will operate correctly in the absence
* of parent Containers in a given deployment.
* <p>
* A Container may also be associated with a number of support components
* that provide functionality which might be shared (by attaching it to a
* parent Container) or individually customized. The following support
* components are currently recognized:
* <ul>
* <li><b>Loader</b> - Class loader to use for integrating new Java classes
* for this Container into the JVM in which Catalina is running.
* <li><b>Logger</b> - Implementation of the <code>log()</code> method
* signatures of the <code>ServletContext</code> interface.
* <li><b>Manager</b> - Manager for the pool of Sessions associated with
* this Container.
* <li><b>Realm</b> - Read-only interface to a security domain, for
* authenticating user identities and their corresponding roles.
* <li><b>Resources</b> - JNDI directory context enabling access to static
* resources, enabling custom linkages to existing server components when
* Catalina is embedded in a larger server.
* </ul>
5.Engine.java（引擎）
* An <b>Engine</b> is a Container that represents the entire Catalina servlet
* engine. It is useful in the following types of scenarios:
* <ul>
* <li>You wish to use Interceptors that see every single request processed
* by the entire engine.
* <li>You wish to run Catalina in with a standalone HTTP connector, but still
*want support for multiple virtual hosts.
* </ul>
* In general, you would not use an Engine when deploying Catalina connected
* to a web server (such as Apache), because the Connector will have
* utilized the web server's facilities to determine which Context (or
* perhaps even which Wrapper) should be utilized to process this request.
* <p>
* The child containers attached to an Engine are generally implementations
* of Host (representing a virtual host) or Context (representing individual
* an individual servlet context), depending upon the Engine implementation.
* <p>
* If used, an Engine is always the top level Container in a Catalina
* hierarchy. Therefore, the implementation's <code>setParent()</code> method
* should throw <code>IllegalArgumentException</code>.
6.Host.java（主机）
* A <b>Host</b> is a Container that represents a virtual host in the
* Catalina servlet engine. It is useful in the following types of scenarios:
* <ul>
* <li>You wish to use Interceptors that see every single request processed
* by this particular virtual host.
* <li>You wish to run Catalina in with a standalone HTTP connector, but still
* want support for multiple virtual hosts.
* </ul>
* In general, you would not use a Host when deploying Catalina connected
* to a web server (such as Apache), because the Connector will have
* utilized the web server's facilities to determine which Context (or
* perhaps even which Wrapper) should be utilized to process this request.
* <p>
* The parent Container attached to a Host is generally an Engine, but may
* be some other implementation, or may be omitted if it is not necessary.
* <p>
* The child containers attached to a Host are generally implementations
* of Context (representing an individual servlet context).
7.Context.java（上下文）
* A <b>Context</b> is a Container that represents a servlet context, and
* therefore an individual web application, in the Catalina servlet engine.
* It is therefore useful in almost every deployment of Catalina (even if a
* Connector attached to a web server (such as Apache) uses the web server's
* facilities to identify the appropriate Wrapper to handle this request.
* It also provides a convenient mechanism to use Interceptors that see
* every request processed by this particular web application.
* <p>
* The parent Container attached to a Context is generally a Host, but may
* be some other implementation, or may be omitted if it is not necessary.
* <p>
* The child containers attached to a Context are generally implementations
* of Wrapper (representing individual servlet definitions).
* <p>
8.Wrapper.java（）
* A <b>Wrapper</b> is a Container that represents an individual servlet
* definition from the deployment descriptor of the web application. It
* provides a convenient mechanism to use Interceptors that see every single
* request to the servlet represented by this definition.
* <p>
* Implementations of Wrapper are responsible for managing the servlet life
* cycle for their underlying servlet class, including calling init() and
* destroy() at appropriate times, as well as respecting the existence of
* the SingleThreadModel declaration on the servlet class itself.
* <p>
* The parent Container attached to a Wrapper will generally be an
* implementation of Context, representing the servlet context (and
* therefore the web application) within which this servlet executes.
* <p>
* Child Containers are not allowed on Wrapper implementations, so the
* <code>addChild()</code> method should throw an
* <code>IllegalArgumentException</code>.
*
9.Lifecycle.java（生命周期）
/**
* Common interface for component life cycle methods. Catalina components
* may implement this interface (as well as the appropriate interface(s) for
* the functionality they support) in order to provide a consistent mechanism
* to start and stop the component.
* <br>
* The valid state transitions for components that support {@link Lifecycle}
* are:
* <pre>
* start()
* -----------------------------
* | |
* | init() |
* NEW -»-- INITIALIZING |
* | | | | ------------------«-----------------------
* | | |auto | | |
* | | \|/ start() \|/ \|/ auto auto stop() |
* | | INITIALIZED --»-- STARTING_PREP --»- STARTING --»- STARTED --»--- |
* | | | | |
* | |destroy()| | |
* | --»-----«-- ------------------------«-------------------------------- ^
* | | | |
* | | \|/ auto auto start() |
* | | STOPPING_PREP ----»---- STOPPING ------»----- STOPPED -----»-----
* | \|/ ^ | ^
* | | stop() | | |
* | | -------------------------- | |
* | | | | |
* | | | destroy() destroy() | |
* | | FAILED ----»------ DESTROYING ---«----------------- |
* | | ^ | |
* | | destroy() | |auto |
* | --------»----------------- \|/ |
* | DESTROYED |
* | |
* | stop() |
* ----»-----------------------------»------------------------------
*
* Any state can transition to FAILED.
*
* Calling start() while a component is in states STARTING_PREP, STARTING or
* STARTED has no effect.
*
* Calling start() while a component is in state NEW will cause init() to be
* called immediately after the start() method is entered.
*
* Calling stop() while a component is in states STOPPING_PREP, STOPPING or
* STOPPED has no effect.
*
* Calling stop() while a component is in state NEW transitions the component
* to STOPPED. This is typically encountered when a component fails to start and
* does not start all its sub-components. When the component is stopped, it will
* try to stop all sub-components - even those it didn't start.
*
* Attempting any other transition will throw {@link LifecycleException}.
*
* </pre>
* The {@link LifecycleEvent}s fired during state changes are defined in the
* methods that trigger the changed. No {@link LifecycleEvent}s are fired if the
* attempted transition is not valid.
*
10.Server.java
* A <code>Server</code> element represents the entire Catalina
* servlet container. Its attributes represent the characteristics of
* the servlet container as a whole. A <code>Server</code> may contain
* one or more <code>Services</code>, and the top level set of naming
* resources.
* <p>
* Normally, an implementation of this interface will also implement
* <code>Lifecycle</code>, such that when the <code>start()</code> and
* <code>stop()</code> methods are called, all of the defined
* <code>Services</code> are also started or stopped.
* <p>
* In between, the implementation must open a server socket on the port number
* specified by the <code>port</code> property. When a connection is accepted,
* the first line is read and compared with the specified shutdown command.
* If the command matches, shutdown of the server is initiated.
* <p>
* <strong>NOTE</strong> - The concrete implementation of this class should
* register the (singleton) instance with the <code>ServerFactory</code>
* class in its constructor(s).
12.Service.java
* A <strong>Service</strong> is a group of one or more
* <strong>Connectors</strong> that share a single <strong>Container</strong>
* to process their incoming requests. This arrangement allows, for example,
* a non-SSL and SSL connector to share the same population of web apps.
* <p>
* A given JVM can contain any number of Service instances; however, they are
* completely independent of each other and share only the basic JVM facilities
* and classes on the system class path.
13.Executor.java
* Executes the given command at some time in the future. The command
* may execute in a new thread, in a pooled thread, or in the calling
* thread, at the discretion of the <tt>Executor</tt> implementation.
* If no threads are available, it will be added to the work queue.
* If the work queue is full, the system will wait for the specified
* time until it throws a RejectedExecutionException
14.Realm.java
* A <b>Realm</b> is a read-only facade for an underlying security realm
* used to authenticate individual users, and identify the security roles
* associated with those users. Realms can be attached at any Container
* level, but will typically only be attached to a Context, or higher level,
* Container.
网友评论