Dispatcherservlet Learning in Contextloaderlistener and spring MVC

Dispatcherservlet Introduction

Dispatcherservlet is the implementation of the spring front-end controller that provides the central access point for spring Web MVC, and is responsible for assigning responsibilities that are seamlessly integrated with the spring IOC container to get all the benefits of spring.

Dispatcherservlet is mainly used for responsibility scheduling, itself mainly for the control process, the main responsibilities are as follows:

1, File upload parsing, if the request type is multipart will be through the Multipartresolver file upload parsing;
2, through the handlermapping, map the request to the processor (return a handlerexecutionchain, which includes a processor, multiple handlerinterceptor interceptors);
3. Support multiple types of processors (processors in handlerexecutionchain) through Handleradapter;
4, through the Viewresolver analytic logical view name to the concrete view realization;
5, localization analysis;
6, rendering the specific views, etc.;
7, if the execution process encountered an exception will be given to Handlerexceptionresolver to resolve.

Dispatcherservlet uses Webapplicationcontext as the context by default, and the spring default profile is "/web-inf/[servlet name]-servlet.xml".

Dispatcherservlet can also configure its own initialization parameters, overriding the default configuration:

Parameters	Describe
Contextclass	The class that implements the Webapplicationcontext interface, which is used by the current servlet to create the context. If this parameter is not specified, Xmlwebapplicationcontext is used by default.
Contextconfiglocation	A string that is passed to the context instance (specified by Contextclass) to specify the location of the context. This string can be broken into multiple strings (using commas as delimiters) to support multiple contexts (in multi-context cases, if the same bean is defined two times, the next one takes precedence). Default is/web-inf/[server-name]-servlet.xml
Namespace	The Webapplicationcontext namespace. The default value is [Server-name]-servlet.

As follows:

<servlet>        <servlet-name>demo</servlet-name>        <servlet-class> Org.springframework.web.servlet.dispatcherservlet</servlet-class>        <load-on-startup>1</ load-on-startup>        <init-param>            <param-name>contextConfigLocation</param-name>            <param-value>classpath:spring-servlet-config.xml</param-value>        </init-param></servlet ><servlet-mapping>        <servlet-name>demo</servlet-name>        <url-pattern>/</ Url-pattern></servlet-mapping>

Servlet Context Relationship

The context of Dispatcherservlet is loaded by configuring the contextconfiglocation of the servlet, and the default implementation is Xmlwebapplicationcontext.

It is worth noting that the context of the dispatcherservlet is just the context of spring MVC, and that the spring loaded context is loaded by Contextloaderlistener. Both contexts are used in the General Spring Web project, which is responsible only for the configuration management of the MVC-related beans (such as viewresolver, Controller, Multipartresolver, etc.). The latter is responsible for the configuration management of the entire spring-related bean (e.g. related service, DAO, etc.).

Therefore, the bean configured in/web-inf/[server-name]-servlet.xml is generally valid only for spring MVC, while the bean configured under the Contextloaderlistener configuration file is valid for the entire spring.

When the context is created, it is placed in the ServletContext object, where the Contextloaderlistener loaded context is placed in the ServletContext key for Webapplicationcontext.root_web_ The Application_context_attribute property, and the context loaded by Dispatcherservlet will put a copy of the request object's key at each requested Web_application_context_ The attribute property. Thus the acquisition of the two ways is not the same, the former can be through Webapplicationcontextutils.getrequiredwebapplicationcontext (ServletContext) or Webapplicationcontextutils.getwebapplicationcontext (ServletContext) or Webapplicationcontextutils.getwebapplicationcontext (Servletcontext,attrname) method to obtain the corresponding ApplicationContext, The latter is through Requestcontextutils.getwebapplicationcontext (request) or Webapplicationcontextutils.getwebapplicationcontext (Servletcontext,attrname) method to obtain the corresponding applicationcontext.
Note: For Contextloaderlistener loaded contexts, Attrname is the webapplicationcontext.root_web_application_context_attribute mentioned above , whereas for Dispatcherservlet the context is FrameworkServlet.class.getName () + ". CONTEXT. "+ Getservletname ()

It can be seen through the properties of the context, if through Webapplicationcontextutils.getrequiredwebapplicationcontext (ServletContext) To try to get dispatcherservlet loaded ApplicationContext, it throws "No Webapplicationcontext found:no Contextloaderlistener Registered? " The exception.

Special beans used in the Dispatcherservlet

Dispatcherservlet uses Webapplicationcontext as the context by default, so let's take a look at what special beans are in that context:

1, CONTROLLER: Processor/Page Controller, do the C thing in MVC, but the control logic transferred to the front controller, for processing the request;

2, Handlermapping: request to the processor mapping, if the mapping successfully returned a Handlerexecutionchain object (contains a handler processor (page Controller) object, Multiple Handlerinterceptor interceptors) objects, such as beannameurlhandlermapping the URL and the Bean name Mapping, the successful mapping of the bean is the processor here;

3. Handleradapter:handleradapter will package the processor as an adapter to support many types of processors, i.e. adapter design mode applications, making it easy to support a wide variety of processors , such as Simplecontrollerhandleradapter will implement the Controller interface of the bean to adapt, and off the processor HandleRequest method for functional processing;

4, Viewresolver:viewresolver will parse the logical view name into a specific view, through this policy mode, it is easy to replace other view technology, such as Internalresourceviewresolver map the logical view name as a JSP view;

5, Localresover: localization analysis, because spring supports internationalization, so localresover parsing client locale information so as to facilitate internationalization;

6, Themeresovler: Theme analysis, through it to achieve a page multi-style, that is common similar to the software skin effect;

7, Multipartresolver: File upload parsing, used to support file upload;

8, Handlerexceptionresolver: Processor exception resolution, you can map the exception to the corresponding unified error interface, so as to display a user-friendly interface (rather than to the user to see the specific error message);

9, Requesttoviewnametranslator: When the processor does not return the logical view name and other related information, the request URL is automatically mapped to the logical view name;

10. Flashmapmanager: A policy interface for managing Flashmap, Flashmap is used to store the output of a request, and is used as input to the request when another request is entered, usually for redirecting scenes

Through the above beans can be seen, General localresover, viewresolver, etc. need to be configured in the/web-inf/[server-name]-servlet.xml file.

Dispatcherservlet Learning in Contextloaderlistener and spring MVC