Tomcat's container

Subject:

　It seems a bit abrupt to learn the valve of Tomcat, so let's get to the bottom of a core component of Tomcat container
Container takes the resolved internal request from the previous component connector, carries out a series of logical operations according to the request, until the requested servlet is invoked, and then the response is assembled and returned to Clint.
The whole process is clear. After all, we probably know that tomcat input and output can also guess some of the necessary operations within it.

Let's look at the classification of container:
Engine
Host
Context
Wrapper
Their respective implementation classes are Standardengine, Standardhost, Standardcontext, and Standardwrapper, respectively. They were all under Tomcat's Org.apache.catalina.core bag.

The relationship between them, you can see Tomcat Server.xml also understand (according to the node parent-child relationship), so analogy: in addition to wrapper minimum, can not contain other container, the context can have 0 or more wrapper, Host can have 0 or more host,engine can have 0 to multiple host.

In Tomcat6, these standard container are directly inherited from abstract classes:org.apache.catalina.core.ContainerBase:

From some of the method names in the Containerbase class, we can see how the actions that are contained and contained between each container are implemented, and these are the methods he provides:

public void AddChild (Container child) public
Container Findchild (String name) public
container[] Findchildren ( Public
objectname[] GetChildren () public
Container GetParent () public
objectname Getparentname (
) public void RemoveChild (Container child)

Of course, a container implementation is complex, skip first, the future will have the opportunity to come back to learn.

the mechanism of pipeline:

Its structure and realization is very worth us to learn and draw lessons from.

Take a look at the flow chart from the network (very good diagram):

What a good picture, just look at the picture you can understand about the Tomcat operation, haha.

The first thing to understand is that every kind of container has its own standardvalve
The above four container corresponding four are:
Standardenginevalve
Standardcontextvalve
Standardhostvalve
Standardwrappervalve

Some people compared Vavle to filter, and pipeline compared to filter chain, in fact, is very appropriate. Here's what I understand:

Beginning:
In the Coyoteadapter service method, from the following sentence into the container.
Connector.getcontainer (). Getpipeline (). GetFirst (). Invoke (request, response);
Yes, this is the gate into the container maze, welcome to container.

Pipeline (note the Pipeline wiring of the above structure chart):

Pipeline is like a production line in a factory, responsible for the deployment of workers (valve) position, valve is responsible for different operations on the production line workers.
The completion of a production line requires two steps:
1, transport the raw material to the workers ' side.
2, the workers to complete their own responsible part

and Tomcat's pipeline implementation is this:
1, after the first worker in the production line gets the raw material, apart the next worker, the next worker imitates the first worker, throws it to the next worker until the last worker, and the last worker is arranged as mentioned above Standardvalve, The work he was going to accomplish was to bring the means of production to the container pipeline that he contained.
2, four container is equivalent to four production lines (Pipeline), four Pipeline are doing so until the final standardwrappervalve get the resources to start calling the servlet. After the completion of the return, step-by-step valve according to just lost the production of raw materials is the order of the reverse of a one-time execution. This completes the mechanism of Tomcat's pipeline.

End:

After all the vavle have been executed, the entire response is over.

about Pipeline We look at the source code:

A standardvalve

invoke method from Org.apache.catalina.core.StandardEngineValve:

Public final void Invoke (Request request, Response Response)
        throws IOException, servletexception {

        // Get your own host host
        = Request.gethost ();
        if (host = = null) {
            response.senderror
                (httpservletresponse.sc_bad_request,
                 sm.getstring) (" Standardengine.nohost ", 
                              Request.getservername ()));
            return;
        }

        The last worker in the pipeline is responsible for transporting the raw material to a pipeline
        //This is the key host.getpipeline () that concatenates all the pipeline.
        GetFirst (). Invoke (Request, response);
    }

An ordinary valve.

from the Org.apache.catalina.valves.ErrorReportValveinvoke method:

 public void Invoke (Request request, Response Response) throws IOException, Servletexception {//Has come
        Just throw the raw material to the next vavle. Execution, which is the key GetNext () to concatenate all vavle into a pipeline. Invoke (request, response); Wait until the above valve all execute well, only then starts own real work: throwable throwable = (throwable) request.getattribute (globals.exceptio
        N_ATTR);
        if (response.iscommitted ()) {return;
            } if (Throwable!= null) {//The response is a error response.seterror ();
            Reset the response (if possible) try {response.reset ();
            catch (IllegalStateException e) {;
        } response.senderror (Httpservletresponse.sc_internal_server_error);
        } response.setsuspended (FALSE);
        try {(Request, response, throwable);
        catch (Throwable tt) {; }
    }

The above describes the pipeline mechanism, do not know whether you will doubt (anyway I have): Vavle in front of the servlet or after execution, look at the above source code example seems to be after the implementation of OH. Actually is not necessarily, take remoteaddrvalve as an example:

Remoteaddrvalve can restrict access based on the IP address, which is appended with some configuration steps from the network.

Remoteaddrvalve Source:

Package org.apache.catalina.valves;
Import java.io.IOException;
Import javax.servlet.ServletException;
Import Org.apache.catalina.connector.Request;

Import Org.apache.catalina.connector.Response; Public final class Remoteaddrvalve extends Requestfiltervalve {//----------------------------------------------
     -------Instance Variables/** * The descriptive information related to this implementation.
    * * private static final String info = "org.apache.catalina.valves.remoteaddrvalve/1.0"; -------------------------------------------------------------Properties/** * Return descriptive information
     About this Valve implementation.
    */Public String GetInfo () {return (info); }//---------------------------------------------------------public Methods/** * will invoke Invoke method * p Ublic void invoke (Request request, Response Response) throws IOException, Servletexception {//Calling the parent class proc Ess method, we're going to look at the parent class's case process (Request.getrequest () getremoteaddr (), request, response); }
}

The process method for the parent class above:

    protected void Process (String property,
                           request request, Response Response)
        throws IOException, servletexception {
        //In the next valve is a judgment isallowed (property) This method is used to restrict the IP address of the
        if (isallowed) {
            GetNext (). Invoke (request, response);
            return;
        }
        Restricted access, all made an error
        Response.senderror (Httpservletresponse.sc_forbidden);
    }

Only the specified host or IP address can access applications deployed under Tomcat. Tomcat provides two parameters for you to configure: Remotehostvalve and Remoteaddrvalve, which are used to restrict the hostname, which is used to restrict the IP address.

By configuring these two parameters, you can filter the host or IP address from the request and allow or deny which host IP

Global settings, effective for all applications under Tomcat

Server.xml, restart the server by adding the following line:

<valve classname= "Org.apache.catalina.valves.RemoteAddrValve" allow= "192.168.1.*" deny= ""/>

Note: This row is placed before </Host>.

Cases:

1, allow only 192.168.1.10 access:

<valve classname= "Org.apache.catalina.valves.RemoteAddrValve" allow= "192.168.1.10" deny= ""/>

2, only allow 192.168.1.* network segment access:

<valve
classname= "org.apache.catalina.valves.RemoteAddrValve"
allow= "192.168.1.*" deny= ""/>

3, only allow 192.168.1.10, 192.168.1.30 access:

<valve classname= "Org.apache.catalina.valves.RemoteAddrValve"
allow= "192.168.1.10,192.168.1.30" "deny=" " >

4, according to the host name limit:

<valve classname= "Org.apache.catalina.valves.RemoteHostValve" allow= "abc.com" deny= ""/>

Second, the local settings, only for the specific application of the implementation of the project according to the configuration settings:

1, using the Conf directory to configure the XML file ${tomcat_root}\conf\proj_1.xml
2, set directly in the Server.xml ${tomcat_root}\conf\server.xml
Add the following line to the </Context> before the corresponding item in the above file:

<valve classname= "Org.apache.catalina.valves.RemoteAddrValve" allow= "192.168.1.*" deny= ""/>

Summary:

The 1,pipeline mechanism is like a queue of configurable methods, similar to the way a linked list is implemented. Useful, reliable.

The 2,valve configuration is also a part of the Tomcat configuration and has value.