Spring MVC Project Context Initiation process parsing

In software development, if some features are used more commonly, these features can often be implemented as platform features, which are effectively encapsulated in these platform features to open to other applications. As such, Spring has played an application platform because of its IOC, AOP, transaction processing, and persistence-driven features. Spring MVC is an important part of spring, and the implementation of its Web application is supported by spring, and spring MVC is implemented based on the basic features provided by the spring platform. This article is mainly about the process of Spring MVC container initialization, from which we can see spring MVC's dependence on spring. first, from the Web application perspective of Spring MVC

In the servlet model, the implementation of the request-response relies on the co-ordination of the two major elements:

1. Configuring the servlet and its mapping relationship (in Web. xml)
2. Complete the response logic in the Servlet implementation class

After the project scale expands, the request-response mappings are all defined in Web. XML and will cause the expansion of Web. Xml to become difficult to maintain. To address this problem, SPRINGMVC proposes a solution that refines a core servlet to overwrite all HTTP requests. This refined servlet is often called the core dispatcher . In Springmvc, the core dispatcher is Org.springframework.web.servlet.DispatcherServlet.

The core dispatcher is addressing the following two issues:

Issue 1: The core servlet should be able to establish a complete set of processes for normalizing all HTTP requests.

Issue 2: The core servlet should be able to distribute different HTTP requests to different servlet objects for processing according to certain rules.

For the two problems above, SPRINGMVC's solution is to normalize the entire process and assign each process step to a different component for processing .

Process Normalization: divides the processing process into several steps (tasks) and concatenates all the steps using a clear logical mainline
Process Process components: Define each step (task) in the processing process as an interface and give each interface a different implementation pattern

The primary content of process normalization is to consider the logical steps that a generic servlet responder should roughly include: preliminary processing of HTTP requests, lookup of corresponding controller processing classes (methods) to invoke corresponding controller processing classes (methods) to complete business logic Handling exceptions that can occur when a controller processes a class (method) call the HTTP response processing based on the call result of the Controller processing class (method)

The so-called component, in fact, is the use of programming language to express these logical semantics. In the Java language, the syntax structure that best fits the semantics of the logic processing is the interface, and the interface can have different implementations, so the above four processes are also defined for four different interfaces, respectively: Handlermapping handleradapter Handlerexceptionresolver viewresolver Two, spring MVC from the spring perspective

As can be seen from the above, the component is the core of the core dispatcher (Dispatchservlet), which is the logical carrier of HTTP request processing, Dispatcherservlet is the dispatch center of the logical processing, and the component is the Operation object that is dispatched. The role of the spring container here is to assist Dispatcherservlet to better manage the components.

We know that the SPRINGMVC component is an interface definition, when we define a component in the core configuration file of Springmvc, we use the implementation class of the component, specify the behavior pattern of the component with the concrete implementation class, and the different implementation classes represent different behavior patterns. They can coexist in spring. The spring container manages these implementation classes, depending on how it is used, as determined by the application itself.

Pictured above is a picture of the official spring reference, Dispatchservlet requests to receive HTTP, and the processing of the request is done by components, and the component interface is implemented by the spring IOC container (Webapplicationcontext) to manage. As we can see from this diagram, Spring MVC's implementation of Web applications is dependent on the underlying features (IOC, etc.) provided with spring. The difference between the two webapplicationcontext in the figure is left below. iii. Spring MVC Portal Configuration file Web. XML

What are the configuration files for Spring MVC: The Portal Configuration file: Web. xml; The configuration file that is loaded for each Web project by the website or application server. Application context: Includes the web framework-specific configuration file: Springmvc's ${dispatcherservletname}-servlet.xml configuration file. And spring's configuration file applicationcontext.xml,applicationcontext-*.xml.

Following the servlet specification, the Portal configuration file for Spring MVC's Web App is also XML. The initialization of a Web container is the first load of the. xml file, which jetty loads and initializes the configuration file at startup, and listener and servlets defined therein. Jetty does not know (and does not care) the existence of other profiles, so loading other profiles should be your (framework) thing. So how to load it. As I said earlier, Jetty automatically loads and initializes listener and servlets at startup, so we can customize a listener (Contextloaderlistener) or servlet (Dispatcherservlet). Jetty will load and initialize them according to Web. XML, while they are responsible for loading the appropriate configuration files.

In the Web. XML configuration file, there are two main configurations: Contextloaderlistener and Dispatcherservlet. The same configuration about the spring configuration file also has two parts: the Init-param in Context-param and Dispatcherservlet. The distinction between these two parts, then, is the initialization of the spring container and the initialization of the Web container. Dispatcherservlet and Contextloaderlistener provide the interface to spring in the Web container. ServletContext provides a hosting environment for the spring IOC container, in which spring MVC establishes an IOC container system.

If you do not use Webapplicationconext in your project, you can listen without configuring Contextloadlistener.

Here's a look at the related configuration of the Web. xml file in spring MVC:

[HTML]  View Plain  copy <?xml version= "1.0"  encoding= "UTF-8"?>   <web-app  version= "2.5"  xmlns= "Http://java.sun.com/xml/ns/javaee"              xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance"              xsi:schemalocation= "http://java.sun.com/xml/ns/javaee http://java.sun.com/ Xml/ns/javaee/web-app_2_5.xsd ">       <display-name>push-center-server </display-name>       <description><span style= "font-family:  Arial, sans-serif; " >test</span></description>       <context-param>           <param-name>webAppRootKey</param-name>           <param-value>test</param-value>       </context-param>       < context-param>           <param-name> contextconfiglocation</param-name>           < param-value>               classpath: applicationcontext.xml           </param-value>