The HandlerMapping interface is used to find handlers. In SpringMvc, the DispatcherServlet handles many requests, and each request requires a Handler. Which Handler is used when receiving a request? That’s what Handler is going to do. Therefore, the HandlerMapping function is to find the corresponding Handler and Interceptors according to the request.

The HandlerMapping interface in Spring is as follows:

This class can be implemented by application developers, although this is not necessary, as BeanNameUrlHandlerMapping and DefaultAnnotationHandlerMapping are included in the framework. The former is the default if no HandlerMapping bean is registered in the application context. This class can be realized by the application developers, although this is not necessary, because BeanNameUrlHandlerMapping and DefaultAnnotationHandlerMapping have been included in the framework, as the default implementation of HandlerMapping. If there are no registered the application context HandlerMapping bean, BeanNameUrlHandlerMapping is the default.

HandlerMapping implementations can support mapped interceptors but do not have to. A handler will always be wrapped in a HandlerExecutionChain instance, optionally accompanied by some HandlerInterceptor instances.The DispatcherServlet will first call each HandlerInterceptor’s preHandle method in the given order, Finally invoking the handler itself if all preHandle methods have returned true The HandlerMapping implementation can support mapped interceptors, but does not have to. Handlers will always be wrapped in the HandlerExecutionChain instance and can be executed by several instances of the HandlerInterceptor. In a given order, the DispatcherServlet will call the preHandle method of each HandlerInterceptor first, and the handler itself last if all the preHandle methods return true.

The ability to parameterize this mapping is a powerful and unusual capability of this MVC framework. For example, it is possible to write a custom mapping based on session state, cookie state or many other variables. No other MVC framework seems to be equally flexible. The ability to parameterize this mapping is a powerful and unusual capability of the MVC framework. For example, you can write custom mappings based on session state, cookie state, or many other variables. No other MVC framework seems to be as flexible.

Note: Implementations can implement the Ordered interface to be able to specify a sorting order and thus a priority for getting applied by DispatcherServlet. Non-Ordered instances get treated as lowest priority. Note: An implementation can implement the Ordered interface so that it can specify the ordering order and thus the priority applied by the DispatcherServlet. Unordered instances are considered the lowest priority.

1. Interface constants

1.1, PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE

The name of the HttpServletRequest attribute that contains the path in the handler map, such as a pattern match, or a fully related URI(typically in the DispatcherServlet map). This property is not required to be supported by all HandlerMapping implementations. Url-based HandlerMappings will typically support it, but handlers should not expect this request attribute to be present in all scenarios.

/**
 * Name of the {@link HttpServletRequest} attribute that contains the path
 * within the handler mapping, in case of a pattern match, or the full
 * relevant URI (typically within the DispatcherServlet's mapping) else. * 
Note: This attribute is not required to be supported by all * HandlerMapping implementations. URL-based HandlerMappings will *  typically support it, but handlers should not necessarily expect * this request attribute to be present in all scenarios. */ String PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE = HandlerMapping.class.getName() + ".pathWithinHandlerMapping";
Copy the code

1.2, BEST_MATCHING_PATTERN_ATTRIBUTE

The name of the HttpServletRequest attribute, including the best match pattern in the handler map

/** * Name of the {@link HttpServletRequest} attribute that contains the * best matching pattern within the handler mapping. * <p>Note: This attribute is not required to be supported by all * HandlerMapping implementations. URL-based HandlerMappings will *  typically support it, but handlers should not necessarily expect * this request attribute to be presentin all scenarios.
 */
String BEST_MATCHING_PATTERN_ATTRIBUTE = HandlerMapping.class.getName() + ".bestMatchingPattern";
Copy the code

1.3, INTROSPECT_TYPE_LEVEL_MAPPING

The name of the HttpServletRequest attribute, indicating whether type-level mappings should be checked.

/**
 * Name of the boolean {@link HttpServletRequest} attribute that indicates
 * whether type-level mappings should be inspected.
 * <p>Note: This attribute is not required to be supported by all
 * HandlerMapping implementations.
 */
String INTROSPECT_TYPE_LEVEL_MAPPING = HandlerMapping.class.getName() + ".introspectTypeLevelMapping";
Copy the code

1.4, URI_TEMPLATE_VARIABLES_ATTRIBUTE

Contains the name of the HttpServletRequest attribute of the URI template mapping that maps variable names to values.

/** * Name of the {@link HttpServletRequest} attribute that contains the URI * templates map, mapping variable names to values. * <p>Note: This attribute is not required to be supported by all * HandlerMapping implementations. URL-based HandlerMappings will *  typically support it, but handlers should not necessarily expect * this request attribute to be presentin all scenarios.
 */
String URI_TEMPLATE_VARIABLES_ATTRIBUTE = HandlerMapping.class.getName() + ".uriTemplateVariables";
Copy the code

1.5, MATRIX_VARIABLES_ATTRIBUTE

The name of the HttpServletRequest property that contains the mapping with URI matrix variables. This attribute is not required to be supported by all HandlerMapping implementations and may not exist, depending on whether HandlerMapping is configured to retain matrix variable content in the request URI.

/**
 * Name of the {@link HttpServletRequest} attribute that contains a map with
 * URI matrix variables.
 * <p>Note: This attribute is not required to be supported by all
 * HandlerMapping implementations and may also not be present depending on
 * whether the HandlerMapping is configured to keep matrix variable content
 * in the request URI.
 */
String MATRIX_VARIABLES_ATTRIBUTE = HandlerMapping.class.getName() + ".matrixVariables";
Copy the code

1.6, PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE

The name of the HttpServletRequest property that contains the generated collection of MediaTypes available for the mapping handler.

/**
 * Name of the {@link HttpServletRequest} attribute that contains the set of
 * producible MediaTypes applicable to the mapped handler.
 * <p>Note: This attribute is not required to be supported by all
 * HandlerMapping implementations. Handlers should not necessarily expect
 * this request attribute to be present in all scenarios.
 */
String PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE = HandlerMapping.class.getName() + ".producibleMediaTypes";
Copy the code

2. Core methods

There is only one method in the HandlerMapping interface, as follows:

HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;
Copy the code

The getHandler method uses request to get a HandlerExecutionChain. This method is implemented in different subclasses. The specific implementation will be analyzed in detail when the subclass is described later.

3. The HandlerMapping subclass

The yellow parts in the figure indicate obsolete classes and are not recommended to be used during development.

In the system of HandlerMapping, it can be seen that the subclasses of HandlerMapping can be divided into two branches.

  • AbstractHandlerMethodMapping
  • AbstractUrlHandlerMapping

The above two abstract classes are subclasses of AbstractHandlerMapping. AbstractHandlerMapping will be studied in the next article.

If you have any comments or suggestions, leave them in the comments section below, or send us an email ([email protected])! Welcome friends to communicate with us and grow up together.