SPRINGMVC Source Code Learning (ii) process of processing requests within Frameworkservlet

The following content is based on the book: "See through springmvc-Source code analysis and practice" basic copy ... Used to check the memo yourself.

Let's take a look at Dispatcherservlet inheritance tree.

We know that the servlet processing method starts with the HttpServlet service method, and Frameworkservlet overrides the service method of the parent class HttpServlet. The code is as follows:

Frameworkservlet Service

protected void service(HttpServletRequest request, HttpServletResponse response)        throws ServletException, IOException {    /*    因为HttpServlet中是没有定义doPatch方法的，所以规定    if(是doPatch类型)        就交由本类（FrameworkServlet）内的doPatch方法运行。    else        调用父类（HttpServlet）的service方法。    */    if (HttpMethod.PATCH.matches(request.getMethod())) {        processRequest(request, response);    }    else {        super.service(request, response);    }}

The HttpServlet service is called by different do methods depending on the type. such as Doget,dopost. These methods are rewritten within the Frameworkservlet, so the final call is the corresponding method within the Frameworkservlet.
The code is as follows (take Doget as an example):

Frameworkservlet (DOXXX)

protected final void doGet(HttpServletRequest request, HttpServletResponse response)        throws ServletException, IOException {    processRequest(request, response);}

Let's summarize this process and take doget as an example
Get Request->frameworkservlet (service) is not a patch request: It is not->httpservlet (service), what type is judged:get-> HttpServlet (doget)->doget Quilt class rewrite->frameworkservlet (doget)->frameworkservlet (ProcessRequest)

Other DOXXX requests within the Frameworkservlet are similar, eventually processrequest (request, response), to be processed, that is to say Within the service method of HttpServlet, Doxx is first separated by type and then merged into a method in Frameworkservlet Doxx. Around a big bend .

1. The reason for this re-merger is not yet seen, and it should be that different types of requests need to be statistically processed within spring.
2. Why not directly use the service to deal with, the reason is that the book, mainly for the sake of flexibility, written code should be able to understand the students.

Here we look at the ProcessRequest method, the code is as follows:

Frameworkservlet (ProcessRequest)

    ProtectedFinalvoidProcessRequest (HttpServletRequest request, httpservletresponse response)Throws Servletexception, IOException {Long startTime = System.currenttimemillis (); Throwable Failurecause =NullGet Localecontext and requestattributes back up firstFor recovery in finally localecontext Previouslocalecontext = Localecontextholder.getlocalecontext (); Localecontext Localecontext = buildlocalecontext (request); Requestattributes previousattributes = Requestcontextholder.getrequestattributes (); Servletrequestattributes requestattributes = buildrequestattributes (Request, response, previousattributes); Webasyncmanager Asyncmanager = Webasyncutils.getasyncmanager (request); Asyncmanager.registercallableinterceptor (FrameworkServlet.class.getName (),new requestbindinginterceptor ()); //the current localecontext,requestattributes in Initcontextholders (Request, LocaleContext, Requestattributes); try {//the place where the request was actually processed doservice (request, response);} catch (...) {//catch code didn't understand the meaning, I deleted it} finally { //recover relevant information, as the service may also have filter operations Resetcontextholders (Request, Previouslocalecontext, Previousattributes); if (requestattributes! = null) { Requestattributes.requestcompleted (); } //log ... //release event, type is servletrequesthandledevent, this is explained below publishrequesthandledevent (request, Response, StartTime, failurecause); } }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21st
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21st
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35

Looking at the details,
Localecontextholder is an abstract class, there is no implementation of class, the internal method is static, the use is not to instantiate the direct call, through which you can get Localecontext, such as language, such as localization information, such as "ZH-CN". The general method of acquiring locale is Request.getlocale (), the method inside the Localecontextholder is static, can be called anytime, anywhere, more convenient.
Requestcontextholder is the same truth. You can get to request and session via Requestcontextholder.

about publishing and listening events
When Publishevents is set to True, this message is sent when the request processing is complete and publishevents configured when the Web. xml file configures the SPRINGMVC servlet, which is true by default.
How to listen to this event, very simple, the demo is as follows:

//做两件事 1、@Component注解。  2、实现ApplicationListener@Component    public class ServletRequestHandledEventListener implements ApplicationListener<ServletRequestHandledEvent>{    final static Logger logger = LoggerFactory.getLogger("RequestProcessLog");    @override    public void onApplicationEvent(ServletRequestHandledEvent event){        logger.info(event.getDescription());    }}

Doservice (request, response);
This line of statements is the core statement of the actual processing request, it is an abstract method, to the subclass, that is, dispatcherservlet implementation.
So our next blog will look at Dispatcherservlet's code.

SPRINGMVC Source Code Learning (ii) process of processing requests within Frameworkservlet