SpringMVC解析请求响应请求过程-源码分析

在web.xml中，我们配置了一个Servlet，这个Servlet会拦截所有请求，但是不会拦截xxx.jsp请求，它会让xxx.jsp正确被返回。

<servlet>
<servlet-name>SpringMVC</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<!-- contextConfigLocation配置SpringMVC加载的配置文件（配置处理器映射器、适配器等等）
如果不配置contextConfigLocation，默认加载的是/WEB-INF/servlet名称-servlet.xml(SpringMVC-servlet.xml)
-->
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:springmvc.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>SpringMVC</servlet-name>
<!--
第一种：*.action，访问以.action结尾由DispatcherServlet进行解析
第二种：/，所以访问的地址由DispatcherServlet进行解析，对于静态文件的解析需要配置不让DispatcherServlet进行解析，对于静态文件的解析需要配置，不让DispatcherServlet进行解析。
使用此种方式可以实现 RESTful 风格的url 。
第三种：/*，这样配置不对，使用这种配置，最终要转发到一个jsp页面时，仍然会由DispatcherServlet解析jsp地址，不能根据jsp页面找到Handler，会报错。
-->
<url-pattern>/</url-pattern>
</servlet-mapping>

所以，当我们访问一个SSM项目的时候，该Servlet会拦截我们的请求。

大家都知道，Tomcat针对每次用户请求都会调用service方法，所以我们就从serivce方法开始分析。

在此之前，我想说，所有在Spring中配置的bean都已经被SpringMVC加载到自身的前端控制器类中进行集中控制调配了。





更在之前，加载配置文件，通过Spring创建bean对象，由Spring进行bean管理：



Tomcat会先调用HttpServlet中的公共serivce方法。

@Override
public void service(ServletRequest req, ServletResponse res)
throws ServletException, IOException {

HttpServletRequest  request;
HttpServletResponse response;

try {
request = (HttpServletRequest) req;
response = (HttpServletResponse) res;
} catch (ClassCastException e) {
throw new ServletException("non-HTTP request or response");
}
service(request, response);
}

之后重载调用其它的service方法。

对！！没错，调用FrameworkServlet中的实现方法。

为什么呢？？因为子类FrameworkServlet重写了该方法，方法进行了动态绑定，所以说，我们这里就调用FrameworkServlet中的实现方法。



之后调用processRequest();方法，该方法的意思是处理请求。



进去你会发现是空实现，所以该方法一定有子类来实现。(这种方式被称为：模板模式，一种设计模式)

DispatcherServlet实现了doService方法，所以进入该类：



之后在该方法中调用doDispatch()；做一个调度。基本上所有前端控制器的逻辑都在这个doDispatch()方法里面。









得到ModelAndView后就是要进行视图渲染了。











好了，进行页面包含或者页面转发后我们浏览器就能够看到页面了。

非常Nice！！！