Tomcat source Resolution-Overall Process introduction 2

Tomcat overall flowchart

1. We use a specific example to track Tomcat, and see how it passes the request layer to the next container, and finally to wrapper to handle it.

Take http://localhost:8080/web/login.jsp as an example

(The following examples are based on the TOMCAT4 source code for reference)

This experience is divided into 3 parts: prophase, metaphase, and end.

Early: Explain how to enter a URL in the browser, how is Tomcat caught.

Mid-term: explained by Tomcat caught, and how in each container shuttle, finally reached the final treatment site.

End: Explain to arrive at the final processing place, how to deal with specifically.

2, the early request of the born.

Here I would first say something about the request.

Let's look at this url:http://localhost:8080/web/login.jsp. It uses 8080 ports for socket communication.

We know that through

InputStream in = Socket.getinputstream () and

OutputStream out = Socket.getoutputstream ()

will be able to realize the news of the coming and going.

However, if the stream to the application layer, it is obviously not easy to operate.

So, in Tomcat's connector, the socket is encapsulated as both the request and the response objects.

We can simply see the request as the data that is sent to the server, and see response as the data that wants to emit the server.

But there are other problems. Request this object is to encapsulate the socket, but he has provided too many things.

such as Request.getauthorization (), Request.getsocket (). Developers like authorization are basically less likely to use it, and things like sockets are potentially dangerous to developers. and Ah, the standard communication class in the servlet specification is servletrequest and httpservletrequest, not the request class. So, so and so. Tomcat had to tamper with the request. Finally Tomcat chose to use the tamping mode (which should be called adapter mode) to solve the problem. It org.apache.catalina.Request the org.apache.coyote.tomcat4.CoyoteRequest. And Coyoterequest has realized the ServletRequest and httpservletrequest these two kinds of interfaces. This gives developers the methods they need and just need.

OK, let's set a breakpoint here in Tomcat's top-level container-Standardengin's Invoke () method, and then access

Http://localhost:8080/web/login.jsp, let's take a look at where we'll be passing in the early stages:

1. Run (): 536, Java.lang.Thread, Thread.java

CurrentThread

2. Run (): 666, Org.apache.tomcat.util.threads.threadpool$controlrunnable, Threadpool.java

ThreadPool

3. Runit (): 589, Org.apache.tomcat.util.net.TcpWorkerThread, Pooltcpendpoint.java

Threadworker

4. Processconnection (): 549

Org.apache.coyote.http11.http11protocol$http11connectionhandler, Http11protocol.java

HTTP protocol Parser

5. Process (): 781, Org.apache.coyote.http11.Http11Processor, Http11processor.java

HTTP request processor

6. Service (): 193, Org.apache.coyote.tomcat4.coyoteadapter,coyoteadapter.java

Adapter

7. Invoke (): 995, Org.apache.catalina.core.ContainerBase, Containerbase.java

Standardengin

1. Main thread

2. Start the thread pool.

3. Adjust the thread pool idle work threads.

4. Send 8080 ports from the data encapsulated by the HTTPD protocol, parsing into request and response objects.

5. Use Http11processor to process request

6. Inside the Http11processor, you will call Coyoteadapter to handle the adapter, The request is adapted to implement the coyoterequest of the ServletRequest and HttpServletRequest interfaces.

7. Here, the early hair pull skin work is basically done, you can give standardengin to do the core of the processing work.

3. Medium-term. The shuttle between the various containers.

The shuttle request in each container is roughly the same way:

Each container has a pipe (pipline) that is specifically used to transmit request.

There are several valves (valve) in the pipeline that are designed to filter the request.

A default valve is usually placed at the lower part of the pipe. The valve will at least do one thing, which is to give the request to the child container.

Let's Imagine:

When a request enters a container, it flows inside the pipe, and the wave-rom-wave ~ waves through each valve. When the last valve is flowing, the damn valve throws it to the child container. Then began to wave Luo ~ Wave ~ Wave Luo ~ ...  To gobble up ~ .... Polo ~ Wave ~ Bo Luo ~ .... To gobble up ~ ....

It was in this way that the Request went through all the containers. (Feeling a bit like the digestive system, the last place a bit like there ~)

OK, let's take a look at what the containers are, what valves are in each container, and what these valves have done to our request:

The pipeline inside the 3.1 Standardengin is: standardenginvalve

Here, Valve did three things:

1. Verify that the request passed over is not httpservletrequest.

2 Verify that the request passed is carried with the host header information.

3 Select the appropriate host to handle it. (Generally we have only one host:localhost, that is, 127.0.0.1).

In this place, our request has completed the historical mission of this part of Engin, the next stop to the uncertain future: host.

The pipline inside the 3.2 standardhost is: standardhostvalve

1. Verify that the request passed over is not httpservletrequest.

2. According to the request to determine which context to deal with.

The context is actually webapp, like http://localhost:8080/web/login.jsp.

The web here is the context ROM.

3. Now that the context is determined, the classloader of that context should be paid to the current thread.

Thread.CurrentThread (). Setcontextclassloader (Context.getloader (). getClassLoader ());

So request can only see the specified context below the classes Ah, jar ah these, and can not see the class of Tomcat itself, what engin ah, valve AH. Or else.

4. Since the request is here, it seems that the user is ready to visit the Web Web app, we have to update the user's session is not. Ok, the manager updates the user's session information

5. Give the specific context container to continue processing request.

6. The context has been processed and the ClassLoader returned.

The pipline inside the 3.3 Standardcontext is: standardcontextvalve

1. Verify that the request passed over is not httpservletrequest.

2. If the request intention is bad, want to visit/meta-inf,/web-inf these directories under the things, oh, no use D!

3. This time will be based on the request in the end is a servlet, or JSP, or static resources to determine exactly what kind of wrapper to deal with this reqeust.

4. Once you decide what kind of wrapper,ok to use, give that wrapper treatment.

4. At the end of the period. How the different needs are handled.

Standardwrapper

Before the wrapper did not have to explain, in fact it is such a thing.

When we are dealing with request, we can divide it into 3 kinds.

Handling Static: Org.apache.catalina.servlets.DefaultServlet

Processing JSP: Org.apache.jasper.servlet.JspServlet

Working with the servlet: Org.apache.catalina.servlets.InvokerServlet

The different request is handled with these 3 different servlet.

Wrapper is a simple encapsulation of them, with wrapper, we can easily intercept each request. You can also easily invoke the servlet's init () and Destroy () methods for easy management.

The specific situation is this drop:

If the request is to find JSP file, Standardwrapper inside will encapsulate a org.apache.jasper.servlet.JspServlet to deal with it.

If the request is to find static resources, the standardwrapper inside will encapsulate a org.apache.jasper.servlet.DefaultServlet to handle it.

If the request is for a servlet, Standardwrapper will encapsulate a org.apache.jasper.servlet.InvokerServlet to handle it.

Standardwrapper is also a container, since it is a container, then it must have left a pipe to request to wear, the lower part of the pipeline must also have a valve (note 1), used to do the last intercept work.

In the bottom of the valve, there are actually two main things to do:

One is to start the filter, let request in the N filter inside sieve a pass, if OK. Pass, then. Or you jump somewhere else.

The second is Servlet.service ((httpservletrequest) request, (HttpServletResponse) response); This method.

If it is Jspservlet, then first compile the JSP file into Servlet_xxx, then invoke the Servlet_xxx Servie () method.

If it is Defaultservlet, find the static resource directly, take out the content and send it out.

If it is Invokerservlet, the service () method of that specific servlet is invoked.

Ok! Complete.

Note 1:standardwrapper inside the valve is the last pass. If this valve desires to hand over the request to Standardwrapper's child container. Sorry, wrapper is considered as the last container at the time of design consideration and does not give wrapper the opportunity to add a child container at all. If you simply want to call Addchild (), throw the illegalargumentexception immediately.