0: Preface
We know that Tomcat's overall framework is also understood that there are some components inside, and what the components are doing.
http://www.9cbs.net/develop/read_article.asp?id=27225
I think, let's take a look at how Tomcat processes JSP and Servlet requests.
1. We trace Tomcat with a specific example to see how it is handed over to the next container at a layer of REQUEST, and finally handle it to Wrapper.
As an example of http: // localhost: 8080 / web / login.jsp
(The following example is referenced by Tomcat4 source code)
This experience is mainly divided into 3 parts: the previous, medium, and end.
Period: Try to enter a URL in the browser, how is Tomcat seized.
Mid term: After explaining the Tomcat, how to shuttle in each container, and finally reach the final processing location.
During the end: After explaining the last processing location, how is it handled.
2, the pre-period Request's Born.
Here, I will talk about Request this.
Let's look at this URL: http: // localhost: 8080 / web / login.jsp It is an 8080 port to make Socket communication.
We know that through
InputStream in = socket.getinputStream () and
OutputStream out = socket.getOutputStream ()
It is often possible to achieve the message.
But if you look at the Stream to the application layer, it is clear that it is inconvenient.
So, in Tomcat's Connector, Socket is packaged into two objects of Request and Response.
We can simply see the data sent to the server to the server, and look the response as the data you want to send.
But then have other questions? The object is encapsulated by the Socket, but what he provides is too much.
REQUEST.GETAUTHORIZATION (), requEST.GETSOCKET (). This kind of AUTHORIZATION developers is basically not too much, and like Socket, it has potentially dangerous to expose to developers. Moreover, the standard communication class in Servlet Specification is ServletRequest and HttpServletRequest, not this Request class. SO, SO, SO. Tomcat must have to smash the Request. Finally, Tomcat chose to use the mortgage mode (should be called an adapter mode) to solve this problem. It smashes org.apache.catalina.Request into org.apache.coyote.tomcat4.coyoteRequest. The CoyoteRequest has implemented two interfaces of ServletRequest and HttpservletRequest. This provides the development personnel need and just needs.
OK, let us set a breakpoint here in Tomcat's top container - StandardEngin's Invoke () method, then access
Http: // localhost: 8080 / Web / login.jsp, let's take a look at where you have passed:
Run (): 536, java.lang.thread, thread.java
CurrentThread
2. Run (): 666, org.apache.tomcat.util.threads.threadpool $ Controlrunnable, Threadpool.javathreadPool, 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, CoyoteApterapter.java
Adapter
7. Invoke (): 995, org.apache.catalina.core.containerbase, Containerbase.java
StandardEngin
Main thread
2. Start the thread pool.
3. Turn out the idle work thread in the thread pool.
4. Transfer the 8080 port over the data encapsulated by the HTTPD protocol, parse into the Request and Response objects.
5. Use http11processor to handle Request
6. In Http11Processor, Call CoyoteAdapter will make adaptation processing, and put the request in the CoyoteRequest that implements the servletRequest and HTTPSERVLETREQUEST interface.
7. When you get here, the pre-hair pouring work will basically get it, you can hand it over to StandardEngin to do the core process.
3. Medium. Shuttle between various containers.
The shuttle in each container is roughly a way:
There is a pipe in each container, specifically used to transmit request.
There are several valves (Valve) inside the pipe, which is specifically used to filter Request.
The low of the pipe is usually placed on a default valve. This valve will do at least one thing, just deliver the Request to the child container.
Let us think about it:
When a request enters a container, it flows inside the pipe, Bolo ~ Polo ~ Polo ~ ground through each valve. When flowing to the last valve, let's throw it it to the child container. Then start in Polo ~ Polo ~ Bolo ~ .... 唧 ~ .... Polog ~ Polo ~ Polo ~ .... 唧 ~ ....
In this way, Request has finished all containers. (I feel a bit like a digestive system, and the last place is a bit like there ~)
OK, let us take a look at what container, what valves in each container, what do these valves have done our request:
3.1 StandardENGIN's Pipeline is: StandardEnvalve
Here, Valve has made three things:
1. Verify that the passed Request is httpservletRequest.
2 Verify that the passed REQUEST carries the host header information.
3 Select the corresponding Host to process it. (Generally we have only one host: localhost, which is 127.0.0.1). At this place, our Request has completed the historical mission of the ENGIN this section, and the next stop in the future: Host.
3.2 STANDARDHOST Pipline is: StandardHostValve
1. Verify that the passed Request is httpservletRequest.
2. Which context is determined based on Request to handle it.
Context is actually webApp, such as http: // localhost: 8080 / web / login.jsp
Here Web is Context Luo!
3. Since it is determined which context is, then pay the CLAssLoader of that context to the current thread.
Thread.currentthread (). SetContextClassLoader (). GetClassLoader ();
This REQUEST only looks at the Classes, Jar, which is not seen below the specified Context, and I can't see the Tomcat itself, what ENGIN, Valve. Otherwise it is still there!
4. Since Request is here, it seems that the user is ready to access the web app, you have to update this user's session! OK, update the user's session information by manager
5. Give the specific Context container to continue to process the request.
6. The Context is processed, and the ClassLoader is still coming back.
3.3 STANDARDCONTEXT PIPLINE is: StandardContextValve
1. Verify that the passed Request is httpservletRequest.
2. If the Request intent, you want to access / meta-inf, / web-inf, huh, huh, no D!
3. At this time, it will be based on the REQUEST is servlet, or JSP, or static resources to determine which Wrapper uses which Wrapper to handle this ReqEut.
4. Once it is determined which Wrapper, OK is used to hand over the Wrapper process.
4. The end. How different needs are dealt with.
StandardWrapper
It didn't have explanations for Wrapper before, in fact it is such a thing.
When we handle the request, you can divide them into three.
Handling static: org.apache.catalina.servlets.defaultServlet
Processing JSP: Org.apache.jasper.Servlet.jspservlet
Handling servlet: org.apache.catalina.servlets.invokerServlet
Different Request use these three different servlets to process.
Wrapper is a simple package for them. After Wrapper, we can easily intercept each Request. It is also easy to call the servlet's init () and destroy () method for easy management!
The specific situation is so dripping:
If Request is looking for a JSP file, you will pick up an org.apache.jasper.servlet.jspservlet in STANDARDWRAPPER.
If Request is looking for static resources, the StandardWrapper will encapsulate an org.apache.jasper.servlet.defaultServlet to process it. If Request is looking for a servlet, a Org.Apache.jasper.Servlet.invokerServlet is encapsulated in StandardWrapper.
StandardWrapper is also a container. Since it is a container, then there must be a pipe to wear a pipe to remove, and the pipe is low must have a valve (Note 1), used to do the last interception.
In the bottom of the bottom of the valve, it is actually two things:
First, start the filter, let the request to screen one through the N filters, if OK! That is Pass. Otherwise, you will jump to other places.
The second is servlet.service (httpservletRequest) RESPONSE); this method.
If it is jspservlet, then compile the JSP file to servlet_xxx, then the servie () method of Invoke servlet_xxx.
If it is a defaultServlet, you will find the static resource directly, remove the content, and send it out.
If it is an InvokerServlet, then the specific servlet's service () method is called.
OK!
Note 1: The valve inside StandardWrapper is the last level. If this valve is desirable to hand over the subscale process of StandardWrapper. Sorry, when design is considered, Wrapper is considered to be the last container, and the roots will not add a sub-container to Wrapper! If it is hard to call AddChild (), immediately throw IllegaArgumentException!
reference:
Tomcat Source Code Analysis (Startup Framework)
