Analysis of requestmapping in SPRINGMVC

In the study of source code, we should look at the highest level, so we first look at the definition of this interface:

Package Org.springframework.web.servlet;import javax.servlet.http.HttpServletRequest;/**
1. Define an interface to map the request to the processor.
Developers can also implement this interface themselves, although this is not necessary, because now the SPRINGMVC has provided a large number of implementations, the most typical is
Beannameurlhandlermapping,simpleurlhandlermapping,requestmappinghandlermapping and so on, in the previous version, if we don't have the settings displayed
So that is the previous two requestmapping, but now the version is beannameurlhandlermapping,defaultannotationhandlermapping two, configured with MVC: Annotation-driven annotations are
Requestmappinghandlermapping
)
2. In the results of the mapping can include 0 or more interceptors, before executing the processor will be executed first prehandle, if the interceptor returns TRUE, the processor logic will be executed
The ability to process parameters at the same time is also very powerful, we can define requestmapping processing various parameters (but obviously do not do so, we can directly define the parameter converter)

3. Because the system can set a number of handlermapping, so we should implement ordered this interface, representing a respective priority, the smaller the higher the priority. The default is Integer.max_value. Priority is the lowest
*/
 Public Interfacehandlermapping {//This property represents the URL corresponding to the handlermappingString Path_within_handler_mapping_attribute= handlermapping.class. GetName () +". pathwithinhandlermapping"; This request has the highest matching degree of hanldermappingString Best_matching_pattern_attribute= handlermapping.class. GetName () +". Bestmatchingpattern"; Whether class-level mappings are supported like our defaultannotationhandlermapping uses this property to represent the support class level. (If we don't have the settings, it's supported by default.)
@see annotationmethodhandleradapter$servlethandlermethodresolver.usetypelevelmapping ())String introspect_type_level_mapping= handlermapping.class. GetName () +". introspecttypelevelmapping"; is also the key name in the request, the value of the map, stored in the key value pairString Uri_template_variables_attribute= handlermapping.class. GetName () +". Uritemplatevariables"; Similar to the above, but the categories have some different storage is the matrix Variable (that is, the value can be used; the split one)String Matrix_variables_attribute= handlermapping.class. GetName () +". Matrixvariables"; Media types supported by HandlermappingString Producible_media_types_attribute= handlermapping.class. GetName () +". Produciblemediatypes"; /**
The only method of this class, according to the single principle of responsibility, we understand that Handlermapping's only duty is to apply a request to a different strategy
Eventually converted to an object such as Handlerexecutionchain, this is not an interface, but a class, which encapsulates the processor and a series of
Interceptor, and proxies the pre-and post-processing of this series of processing
*/handlerexecutionchain gethandler (HttpServletRequest request) throws Exception;}

Through the above analysis has probably understood the purpose of handlermapping, his purpose is a request to come, we need to construct a follow-up environment through handlermapping, which includes our definition of the supported media type, with the various parameters of the request, Interceptors set up in the system and so on. If you want me to say, this step is equivalent to the entrance of SPRINGMVC.

We look at a basic abstract class, which is to provide some basic facilities, leaving a major work for subclasses to implement, this is a abstracthandlermapping. Because of this many methods, I will not post the class, the main analysis of what this class realizes what functions, and where we focus on where to expand.
This abstract class not only implements the handlermapping, but also implements the ordered interface, which in handlermapping prompts us to define our own order. And inherits the spring's base settings class to provide references to some of these servletcontext and Webapplicationcontext. So, if we are going to implement our own handlermapping, we suggest that this abstract class is OK.

We look at one of the most important methods:

@Override Publicfinal Handlerexecutionchain gethandler (HttpServletRequest request) throws Exception {Object handler=gethandlerinternal (Request); if(Handler = =NULL) {Handler=Getdefaulthandler (); }        if(Handler = =NULL) {            return NULL; }        //Bean name or resolved handler?        if(Handler instanceof string) {string HandlerName=(String) handler; Handler=Getapplicationcontext (). Getbean (HandlerName); }        returnGethandlerexecutionchain (handler, request); }

In fact gethandlerinternal (...) is a template method that allows the subclass to return the processor, and if it is empty, it returns the default processor. But if we want to set the default processor ourselves, we have to inject it ourselves. The default is null. If we provide a string type of processor, he will go to the current container to find the processor, oddly enough, I found that the subclass also did such a thing ==!, and this code is still written by the same buddy. It seems that the great God thought we still do not understand it.  And the last Gethandlerexecutionchai is very important, interceptors are acquired in this method. In addition to these important points, this abstract class also leaves a sub: extendinterceptors (list<object> interceptors) leaves the subclass to do some operations on the interceptor.

The next step is to treat each of the different types of handlermapping, but ultimately return to Handlerexecutionchain, which includes processors, interceptors, etc.

Analysis of requestmapping in SPRINGMVC