SpringMVC executes the process

This is the third day of my participation in the November Gwen Challenge. Check out the details: the last Gwen Challenge 2021

The SpringMVC implementation process is all about the interaction between DispatcherSerlvet, HandlerMappings, handlerAdapter, and viewResolver.

The process outline is as follows:

1. All requests are made to DispatcherSerlvet.

   • DispatcherSerlvet is an HTTPServlet that SpingMVC calls to.

2. The DispatcherServlet will walk through all the handlerMappings to find the corresponding handler and get the HandlerExecutionChain

   • The function of handlerMappings is to find the corresponding handler based on the requested URL, that is, the method corresponding to the URL.
     • There are three main handlerMappings: three implementations of the controller
       • Spring MVC has two main types and three ways to implement the Controller layer
         • Two types of
           • BeanName: Use BeanName as the URL.
           • RequestMapping: RequestMapping annotates the URL.
         • Three ways

           • Implement the Controller interface + Component annotation (beanName is path).

           • Implement HttpRequestHandler interface + Component annotation (beanName is path).

           • Controller annotations and RequestMapping annotations. (This is the most common)

   • HandlerExecutionChain the handler execution chain object is the HandlerMethod object encapsulated in the controller’s method that requests the path, and an interceptor list.

3. The above HandlerExecutionChain will then run through the handlerAdapter and wrap it to fetch the handlerAdapter.

   • Why are these Adapters needed?
     • As mentioned above, controllers can be implemented in a number of ways. So different ways to call the corresponding method is not the same!
       • Q: How Java calls another class
         • New object call (not desirable, SpringMVC can’t dynamically know which method to call – it can’t be written in code)
         • Interface call (dead an interface, code directly call interface method, but the flexibility is poor, only a small number of dead interface method)
         • Reflection call (high flexibility, poor efficiency)
       • For SpringMVC implementation
         • The Controller implementation in BeanName mode uses the interface mode
         • RequestMapping uses reflection
       • If you don’t add these adapters, you need a bunch of if-else to do that. Define these Adapters for various scenarios!

4. The HandlerAdapter eventually calls the Handle method to execute the corresponding Controller’s method and return the ModelAndView.

• This handler takes the parameters from the request, iterates through the reflected Method object, and parses the parameters to the corresponding Method arguments through a series of parameter parsers (RequestParam/Path, etc.). Finally, invoke calls the controller’s methods.

• SpringMVC calls methods based on reflection. Before JDK8, reflection did not get argument names, arguments were simplified to arg0.. N, SpringMVC is available in ASM bytecode mode (after 1.8, -parameters is available). So: SpringMVC can also automatically match parameter names without requstparm annotations.

  • Parsing parameters: 1. Priority is annotated 2. Then JDK reflection – only for 1.8+ 3. But only ASM.

• If the Controller method is annotated with @reponseBody, then modelAndView will return null directly to Response without going through the view resolution process below.

5. DispatcherSerlvet gets the ModelAndView and gives it to the ViewResolver, which parses it into a View.

6. The DispatcherServlet renders the View and returns the View to the user.