SpringtMVC running process: @ RequestMapping method, how Map, HttpServletRequest, and other parameter information are encapsulated and transferred (source code understanding ),

SpringtMVC running process: @ RequestMapping method, how Map, HttpServletRequest, and other parameter information are encapsulated and transferred (source code understanding ),

When developing spring MVC programs, parameters such as Map and HttpServletRequest are usually input in the Controller method, and data can be conveniently added to them. At the same time, you can also use the request and other objects in Jsp to conveniently obtain them.

As shown in figure 2 below:

 

But the question is: how does the Map, HttpServletRequest, and other parameter information in the @ RequestMapping method encapsulate and pass?

With this problem, I wrote a simple Demo for source code debugging.

Demo code address:

Https://github.com/cyhbyw/springMVC_atguigu_TongGang

Project name:

SpringMVC_DebugSourceCode

======================================

PS: The image in the following content is too small (I still don't know how to enlarge the image or sweat), so I saved the following content in Word format, and synchronize it to GitHub at the address above.

Word file name:SpringtMVC parameter encapsulation and transfer principle source code ).docx

============== The following are source code debugging ========================

01. First, the browser sends the request to DispatcherServlet. Then, find the appropriate HandlerAdapter (here RequestMappingHandlerAdapter), and then call the handle () method of RequestMappingHandlerAdapter. The method stack starts from Line959.

 

02. in the doDispatch () method of Line959 of DispatcherServlet, several methods are called to reach the invokeForRequest () method. As the name suggests, this method will actually call the Request method (the method in Controller ); however, parameters will be parsed in Line128 first.

 

 

03. The method for parsing parameters will go to Line161.

 

 

04. after calling the two methods, we can see that the above parameter resolution method directly returns mavContainer. getModle ()

 

05. The getModel () method returns the member variable of defaulutModel.

 

06. defaulutModel is actually a BindingAwareModelMap

 

 

07. Return to Line161. We can see that args [I] points to the BindingAwareModelMap we just obtained and the memory address is 5010.

 

08. return a layer. Here, the Object [] args is still BindingAwareModelMap @ 5010, And the element is empty. Here, the Line136 doInvoke (args) method calls the method in the real Controller through reflection.

 

09. after calling the real Controller method, you can see that the defaultModel attribute in the mavContainer object has been assigned a value, and the value is BindingAwareModelMap @ 5010. It is the same object as args (very important )!!!!

(Note: SpringMVC assigns a value to the defaultModel attribute in the mavContainer object. It has not been found after debugging for a long time. I thought that since it is a Map, it should call setXXX (), put (), putAll () is assigned to a method, but this method has not been called for a long time after debugging. At the same time, you can also determine that it is assigned a value after Line136 is called. The Last guess is that it is referenced by the same object. Now, it turns out that it is true)

Again, the Line128 Object [] args variable points to the defamodel model attribute of the mavContainer Object! Therefore, after calling the real Controller method and filling the data through Line136 reflection of args, The defaultModel also has the corresponding data!

 

10. The input parameter Map printed on the console is actually BindingAwareModelMap (unfortunately, the memory address is not obtained; but it can help prove the conclusion in 09)

 

 

11. after calling the real Controller method, process the returned value.

 

12. Set the view name

 

 

13. Prepare to create a ModelAndView object

 

14. Retrieve the Model data from the mavContainer and pass in the ModelAndView through the constructor.

 

15. You have obtained the ModelAndView object for subsequent operations (such as rendering). Note that the method stack in DispatcherServlet starts from Line971.

 

16. Prepare Rendering

 

17. Get the View object.

 

18. Traverse viewResolvers to find a suitable object and return it to the View object in step 17.

 

19. Prepare Rendering

 

20. Expose Model data to RequestAttribute

 

21. The essence of exposure is actually: request. setAttribute (modelName, modelValue)

 

22. The last is a forwarding operation.