SpringMVC源码分析-DispatcherServlet

SpringMVC框架是Spring框架中web模块,时下常用来构建web应用。在应用之余,也一直想要搞明白SpringMVC中是如何接受处理请求的?

SpingMVC 初始化

Spring框架和其他框架类似,都是配置元素集中于xml配置文件中,在框架初始化的时候,加载配置文件,解析文件,生成对应的配置。SpringMVC框架是依托于Spring容器。Spring初始化的过程其实就是IoC容器启动的过程,也就是上下文建立的过程。

ServletContext

每一个web应用中都有一个Servlet上下文。servlet容器提供一个全局上下文的环境,这个上下文环境将成为其他IoC容器的宿主环境,例如:WebApplicationContext就是作为ServletContext的一个属性存在。

WebApplicationContext

context-param

在使用SpringMVC的时候,通常需要在web.xml文件中配置context-paramcontext-param通常可以用来设置SpringcontextConfigLocation

1
2
3
4
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>xxx.xml,xxx.xml</param-value>
</context-param>

当然也可以不配置contextConfigLocation,默认的是/WEB-INF/applicationContext.xml。如果没有设置的话,默认会传入WEB-INF文件夹中包含*Context.xml, spring*.xml或者/**/*Context.xml的文件。

listener
1
2
3
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

ContextLoaderListener 实现了ServletContextListener接口,在SpringMVC中作为监听器的存在,当servlet容器启动时候,会调用contextInitialized进行一些初始化的工作。而ContextLoaderListenercontextInitialized的具体实现在父类ContextLoader类中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
try {
// Store context in local instance variable, to guarantee that
// it is available on ServletContext shutdown.
if (this.context == null) {
this.context = createWebApplicationContext(servletContext);
}
if (this.context instanceof ConfigurableWebApplicationContext) {
ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) this.context;
if (!cwac.isActive()) {
// The context has not yet been refreshed -> provide services such as
// setting the parent context, setting the application context id, etc
if (cwac.getParent() == null) {
// The context instance was injected without an explicit parent ->
// determine parent for root web application context, if any.
ApplicationContext parent = loadParentContext(servletContext);
cwac.setParent(parent);
}
configureAndRefreshWebApplicationContext(cwac, servletContext);
}
}
servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, this.context);

上面的部分代码可以看出,初始化时候通过createWebApplicationContext(servletContext);声明一个WebApplicationContext并赋值给ServletContextorg.springframework.web.context.WebApplicationContext.ROOT属性,作为WebApplicationContext的根上下文(root context)。

DispatcherServlet

在加载完<context-param><listener>之后,容器将加载配置了load-on-startupservlet

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<servlet>
<servlet-name>example</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>***.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>example</servlet-name>
<url-pattern>/example/*</url-pattern>
</servlet-mapping>

DispatcherServlet在初始化的过程中,会建立一个自己的IoC容器上下文Servlet WebApplicationContext,会以ContextLoaderListener建立的根上下文作为自己的父级上下文。DispatcherServlet持有的上下文默认的实现类是XmlWebApplicationContext

我们也可以利用servlet默认初始化参数<init-param>配置contextConfigLocation。如果不设置的话,默认会读取/WEB-INF/applicationContext.xml或者/WEB-INF/xxx-servlet.xml的配置。xxx是对应的servlet-name

Servlet有自己独有的Bean空间,也可以共享父级上下文的共享Bean,当然也存在配置有含有一个root WebApplicationContext配置。其关系如下图所示,后面也还会详细介绍DispatcherServlet这个类。

DispatcherServlet类

DispatcherServlet最为SpringMVC核心类,起到了前端控制器(Front controller)的作用,负责请求分发等工作。

从类图中可以看出,DispatcherServlet的继承关系大致如此:

1
DispatcherServlet -> FrameworkServlet -> HttpServletBean -> HttpServlet -> GenericServlet

从继承关系上可以得出结论,DispatcherServlet本质上还是一个ServletServlet的生命周期大致分为三个阶段:

  • 初始化阶段 init方法
  • 处理请求阶段 service方法
  • 结束阶段 destroy方法

这里就重点关注DispatcherServlet在这三个阶段具体做了那些工作。

DispatcherServlet初始化

DispatcherServletinit()的实现在其父类HttpServletBean中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public final void init() throws ServletException {
...
// Set bean properties from init parameters.
try {
PropertyValues pvs = new ServletConfigPropertyValues(getServletConfig(), this.requiredProperties);
BeanWrapper bw = PropertyAccessorFactory.forBeanPropertyAccess(this);
ResourceLoader resourceLoader = new ServletContextResourceLoader(getServletContext());
bw.registerCustomEditor(Resource.class, new ResourceEditor(resourceLoader, getEnvironment()));
initBeanWrapper(bw);
bw.setPropertyValues(pvs, true);
}
catch (BeansException ex) {
logger.error("Failed to set bean properties on servlet '" + getServletName() + "'", ex);
throw ex;
}
// Let subclasses do whatever initialization they like.
initServletBean();
...
}

以上部分源码描述的过程是通过读取<init-param>的配置元素,读取到DispatcherServlet中,配置相关bean的配置。完成配置后调用initServletBean方法来创建Servlet WebApplicationContext

initServletBean方法在FrameworkServlet类中重写了:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
protected final void initServletBean() throws ServletException {
...
try {
this.webApplicationContext = initWebApplicationContext();
initFrameworkServlet();
}
...
}
protected WebApplicationContext initWebApplicationContext() {
WebApplicationContext rootContext =
WebApplicationContextUtils.getWebApplicationContext(getServletContext());
WebApplicationContext wac = null;
if (this.webApplicationContext != null) {
wac = this.webApplicationContext;
if (wac instanceof ConfigurableWebApplicationContext) {
ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) wac;
if (!cwac.isActive()) {
if (cwac.getParent() == null) {
cwac.setParent(rootContext);
}
configureAndRefreshWebApplicationContext(cwac);
}
}
}
if (wac == null) {
wac = findWebApplicationContext();
}
if (wac == null) {
wac = createWebApplicationContext(rootContext);
}
if (!this.refreshEventReceived) {
onRefresh(wac);
}
if (this.publishContext) {
String attrName = getServletContextAttributeName();
getServletContext().setAttribute(attrName, wac);
if (this.logger.isDebugEnabled()) {
this.logger.debug("Published WebApplicationContext of servlet '" + getServletName() +
"' as ServletContext attribute with name [" + attrName + "]");
}
}
return wac;
}

上文提到Servlet容器在启动的时候,通过ContextLoaderListener创建一个根上下文,并配置到ServletContext中。可以看出FrameworkServlet这个类做的作用是用来创建WebApplicationContext上下文的。大致过程如下:

  • 首先检查webApplicationContext是否通过构造函数注入,如果有的话,直接使用,并将根上下文设置为父上下文。
  • 如果webApplicationContext没有注入,则检查是否在ServletContext已经注册过,如果已经注册过,直接返回使用。
  • 如果没有注册过,将重新新建一个webApplicationContext。将根上下文设置为父级上下文。
  • 不管是何种策略获取的webApplicationContext,都将会调用onRefresh方法,onRefresh方法会调用initStrategies方法,通过上下文初始化HandlerMappingsHandlerAdaptersViewResolvers等等。
  • 最后,同样会将所得webApplicationContext注册到ServletContext中。

initFrameworkServlet()默认的实现是空的。这也可算是SpingMVC留的一个扩展点。

DispatcherServlet处理请求

纵观SpringMVC的源码,大量运用模板方法的设计模式。Servletservice方法也不例外。FrameworkServlet类重写service方法:

1
2
3
4
5
6
7
8
9
10
11
12
@Override
protected void service(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
HttpMethod httpMethod = HttpMethod.resolve(request.getMethod());
if (HttpMethod.PATCH == httpMethod || httpMethod == null) {
processRequest(request, response);
}
else {
super.service(request, response);
}
}

如果请求的方法是PATCH或者空,直接调用processRequest方法(后面会详细解释);否则,将调用父类的service的方法,即HttpServletservice方法, 而这里会根据请求方法,去调用相应的doGetdoPostdoPut……

doXXX系列方法的实现并不是HttpServlet类中,而是在FrameworkServlet类中。在FrameworkServletdoXXX系列实现中,都调用了上面提到的processRequest方法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
protected final void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
long startTime = System.currentTimeMillis();
Throwable failureCause = null;
LocaleContext previousLocaleContext = LocaleContextHolder.getLocaleContext();
LocaleContext localeContext = buildLocaleContext(request);
RequestAttributes previousAttributes = RequestContextHolder.getRequestAttributes();
ServletRequestAttributes requestAttributes = buildRequestAttributes(request, response, previousAttributes);
WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
asyncManager.registerCallableInterceptor(FrameworkServlet.class.getName(), new RequestBindingInterceptor());
initContextHolders(request, localeContext, requestAttributes);
try {
doService(request, response);
}
catch (ServletException ex) {
failureCause = ex;
throw ex;
}
catch (IOException ex) {
failureCause = ex;
throw ex;
}
catch (Throwable ex) {
failureCause = ex;
throw new NestedServletException("Request processing failed", ex);
}
finally {
resetContextHolders(request, previousLocaleContext, previousAttributes);
if (requestAttributes != null) {
requestAttributes.requestCompleted();
}
if (logger.isDebugEnabled()) {
if (failureCause != null) {
this.logger.debug("Could not complete request", failureCause);
}
else {
if (asyncManager.isConcurrentHandlingStarted()) {
logger.debug("Leaving response open for concurrent processing");
}
else {
this.logger.debug("Successfully completed request");
}
}
}
publishRequestHandledEvent(request, response, startTime, failureCause);
}
}

为了避免子类重写它,该方法用final修饰。

  • 首先调用initContextHolders方法,将获取到的localeContextrequestAttributesrequest绑定到线程上。
  • 然后调用doService方法,doService具体是由DispatcherServlet类实现的。
  • doService执行完成后,调用resetContextHolders,解除localeContext等信息与线程的绑定。
  • 最终调用publishRequestHandledEvent发布一个处理完成的事件。

DispatcherServlet类中的doService方法实现会调用doDispatch方法,这里请求分发处理的主要执行逻辑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
HttpServletRequest processedRequest = request;
HandlerExecutionChain mappedHandler = null;
boolean multipartRequestParsed = false;
WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
try {
ModelAndView mv = null;
Exception dispatchException = null;
try {
processedRequest = checkMultipart(request);
multipartRequestParsed = (processedRequest != request);
// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null || mappedHandler.getHandler() == null) {
noHandlerFound(processedRequest, response);
return;
}
// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// Process last-modified header, if supported by the handler.
String method = request.getMethod();
boolean isGet = "GET".equals(method);
if (isGet || "HEAD".equals(method)) {
long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
if (logger.isDebugEnabled()) {
logger.debug("Last-Modified value for [" + getRequestUri(request) + "] is: " + lastModified);
}
if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
return;
}
}
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
return;
}
// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
if (asyncManager.isConcurrentHandlingStarted()) {
return;
}
applyDefaultViewName(processedRequest, mv);
mappedHandler.applyPostHandle(processedRequest, response, mv);
}
catch (Exception ex) {
dispatchException = ex;
}
catch (Throwable err) {
// As of 4.3, we're processing Errors thrown from handler methods as well,
// making them available for @ExceptionHandler methods and other scenarios.
dispatchException = new NestedServletException("Handler dispatch failed", err);
}
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}
catch (Exception ex) {
triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
}
catch (Throwable err) {
triggerAfterCompletion(processedRequest, response, mappedHandler,
new NestedServletException("Handler processing failed", err));
}
finally {
if (asyncManager.isConcurrentHandlingStarted()) {
// Instead of postHandle and afterCompletion
if (mappedHandler != null) {
mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
}
}
else {
// Clean up any resources used by a multipart request.
if (multipartRequestParsed) {
cleanupMultipart(processedRequest);
}
}
}
}

doDispatch主要流程是如下图所示:

  • 先判断是否Multipart类型的请求。如果是则通过multipartResolver解析request
  • 通过getHandler方法找到从HandlerMapping找到该请求对应的handler,如果没有找到对应的handler则抛出异常。
  • 通过getHandlerAdapter方法找到handler对应的HandlerAdapter
  • 如果有拦截器,执行拦截器preHandler方法
  • HandlerAdapter执行handle方法处理请求,返回ModelAndView
  • 如果有拦截器,执行拦截器postHandle方法
  • 然后调用processDispatchResult方法处理请求结果,封装到response中。

SpingMVC 请求处理流程

SpringMVC框架是围绕DispatcherServlet设计的。DispatcherServlet负责将请求分发给对应的处理程序。从网上找了两个图,可以大致了解SpringMVC的框架对请求的处理流程。

  • 用户发送请求,Front ControllerDispatcherServlet)根据请求信息将请求委托给对应的Controller进行处理。
  • DispatcherServlet接收到请求后,HandlerMapping将会把请求封装为HandlerExecutionChain,而HandlerExecutionChain包含请求的所有信息,包括拦截器、Handler处理器等。
  • DispatcherServlet会找到对应的HandlerAdapter,并调用对应的处理方法,并返回一个ModelAndView对象。
  • DispatcherServlet会将ModelAndView对象传入View层进行渲染。
  • 最终DispatcherServlet将渲染好的response返回给用户。

总结

本文主要分析SpringMVCDispatcherServlet的初始化、请求流传过程等。

发现了SpringMVC中在DispatcherServlet的实现过程中运用了模板方法设计模式,看到SpringMVC中留给用户可扩展的点也有很多,体会到Open for extension, closed for modification的设计原则。

本文只关注了DispatcherServlet主流程,忽略了DispatcherServlet处理请求的其他组件的具体实现,如:HandlerMappingHandlerExecutionChainHandlerAdapter等。后面有机会定会追本溯源。