SpringMVC深度探险（三） —— DispatcherServlet与初始化主线
本文是專欄文章（SpringMVC深度探險）系列的文章之一，博客地址為：http://downpour.iteye.com/blog/1341459。
在上一篇文章中，我們給出了構成SpringMVC應用程序的三要素以及三要素的設計過程。讓我們來歸納一下整個設計過程中的一些要點：
- SpringMVC將Http處理流程抽象為一個又一個處理單元
- SpringMVC定義了一系列組件（接口）與所有的處理單元對應起來
- SpringMVC由DispatcherServlet貫穿始終，并將所有的組件串聯起來
在整個過程中，組件和DispatcherServlet總是維持著一個相互支撐的關系：
- DispatcherServlet —— 串聯起整個邏輯主線，是整個框架的心臟
- 組件 —— 邏輯處理單元的程序化表示，起到承上啟下的作用，是SpringMVC行為模式的實際承載者
在本系列接下來的兩篇文章中，我們將分別討論DispatcherServlet和組件的相關內容。本文討論DispatcherServlet，而下一篇則重點分析組件。
有關DispatcherServlet，我們想從構成DispatcherServlet的體系結構入手，再根據不同的邏輯主線分別加以分析，希望能夠幫助讀者整理出學習SpringMVC核心類的思路。
DispatcherServlet的體系結構
通過不同的角度來觀察DispatcherServlet會得到不同的結論。我們在這里選取了三個不同的角度：運行特性、繼承結構和數據結構。
【運行主線】
從DispatcherServlet所實現的接口來看，DispatcherServlet的核心本質：是一個Servlet。這個結論似乎很幼稚，不過這個幼稚的結論卻蘊含了一個對整個框架都至關重要的內在原則：Servlet可以根據其特性進行運行主線的劃分。
根據Servlet規范的定義，Servlet中的兩大核心方法init方法和service方法，它們的運行時間和觸發條件都截然不同：
1. init方法
在整個系統啟動時運行，且只運行一次。因此，在init方法中我們往往會對整個應用程序進行初始化操作。這些初始化操作可能包括對容器（WebApplicationContext）的初始化、組件和外部資源的初始化等等。
2. service方法
在整個系統運行的過程中處于偵聽模式，偵聽并處理所有的Web請求。因此，在service及其相關方法中，我們看到的則是對Http請求的處理流程。
因而在這里，Servlet的這一特性就被SpringMVC用于對不同的邏輯職責加以劃分，從而形成兩條互不相關的邏輯運行主線：
- 初始化主線 —— 負責對SpringMVC的運行要素進行初始化
- Http請求處理主線 —— 負責對SpringMVC中的組件進行邏輯調度完成對Http請求的處理
對于一個MVC框架而言，運行主線的劃分非常重要。因為只有弄清楚不同的運行主線，我們才能針對不同的運行主線采取不同的研究策略。而我們在這個系列中的絕大多數分析的切入點，也是圍繞著不同的運行主線進行的。
注：SpringMVC運行主線的劃分依據是Servlet對象中不同方法的生命周期。事實上，幾乎所有的MVC都是以此為依據來進行運行主線的劃分。這進一步可以證明所有的MVC框架的核心基礎還是Servlet規范，而設計理念的差異也導致了不同的框架走向了完全不同的發展道路。
【繼承結構】
除了運行主線的劃分以外，我們再關注一下DispatcherServlet的繼承結構：
在這個繼承結構中，我們可以看到DispatcherServlet在其繼承樹中包含了2個Spring的支持類：HttpServletBean和FrameworkServlet。我們分別來討論一下這兩個Spring的支持類在這里所起到的作用。
HttpServletBean是Spring對于Servlet最低層次的抽象。在這一層抽象中，Spring會將這個Servlet視作是一個Spring的bean，并將init-param中的值作為bean的屬性注入進來：
Java代碼 ?
public final void init() throws ServletException {
????if (logger.isDebugEnabled()) {
????????logger.debug("Initializing servlet '" + getServletName() + "'");
????}
?
????// 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, this.environment));
????????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();
?
????if (logger.isDebugEnabled()) {
????????logger.debug("Servlet '" + getServletName() + "' configured successfully");
????}
}
從源碼中，我們可以看到HttpServletBean利用了Servlet的init方法的執行特性，將一個普通的Servlet與Spring的容器聯系在了一起。在這其中起到核心作用的代碼是：BeanWrapper bw = PropertyAccessorFactory.forBeanPropertyAccess(this);將當前的這個Servlet類轉化為一個BeanWrapper，從而能夠以Spring的方式來對init-param的值進行注入。BeanWrapper的相關知識屬于Spring Framework的內容，我們在這里不做詳細展開，讀者可以具體參考HttpServletBean的注釋獲得更多的信息。
FrameworkServlet則是在HttpServletBean的基礎之上的進一步抽象。通過FrameworkServlet真正初始化了一個Spring的容器（WebApplicationContext），并引入到Servlet對象之中：
Java代碼 ?
protected final void initServletBean() throws ServletException {
????getServletContext().log("Initializing Spring FrameworkServlet '" + getServletName() + "'");
????if (this.logger.isInfoEnabled()) {
????????this.logger.info("FrameworkServlet '" + getServletName() + "': initialization started");
????}
????long startTime = System.currentTimeMillis();
?
????try {
????????this.webApplicationContext = initWebApplicationContext();
????????initFrameworkServlet();
????} catch (ServletException ex) {
????????this.logger.error("Context initialization failed", ex);
????????throw ex;
????} catch (RuntimeException ex) {
????????this.logger.error("Context initialization failed", ex);
????????throw ex;
????}
?
????if (this.logger.isInfoEnabled()) {
????????long elapsedTime = System.currentTimeMillis() - startTime;
????????this.logger.info("FrameworkServlet '" + getServletName() + "': initialization completed in " +
????????????????elapsedTime + " ms");
????}
}
上面的這段代碼就是FrameworkServlet初始化的核心代碼。從中我們可以看到這個FrameworkServlet將調用其內部的方法initWebApplicationContext()對Spring的容器（WebApplicationContext）進行初始化。同時，FrameworkServlet還暴露了與之通訊的結構可供子類調用：
Java代碼 ?
public abstract class FrameworkServlet extends HttpServletBean {
?
????/** WebApplicationContext for this servlet */
????private WebApplicationContext webApplicationContext;
?
// 這里省略了其他所有的代碼
?
????/**
???? * Return this servlet's WebApplicationContext.
???? */
????public final WebApplicationContext getWebApplicationContext() {
????????return this.webApplicationContext;
????}
}
我們在這里暫且不對Spring容器（WebApplicationContext）的初始化過程詳加探查，稍后我們會討論一些WebApplicationContext初始化過程中的配置選項。不過讀者可以在這里體會到：FrameworkServlet在其內部初始化了一個Spring的容器（WebApplicationContext）并暴露了相關的操作接口，因而繼承自FrameworkServlet的DispatcherServlet，也就直接擁有了與WebApplicationContext進行通信的能力。
通過對DispatcherServlet繼承結構的研究，我們可以明確：
downpour 寫道
結論 DispatcherServlet的繼承體系架起了DispatcherServlet與Spring容器進行溝通的橋梁。
【數據結構】
在上一篇文章中，我們曾經提到過DispatcherServlet的數據結構：
我們可以把在上面這張圖中所構成DispatcherServlet的數據結構主要分為兩類（我們在這里用一根分割線將其分割開來）：
- 配置參數 —— 控制SpringMVC組件的初始化行為方式
- 核心組件 —— SpringMVC的核心邏輯處理組件
可以看到，這兩類數據結構都與SpringMVC中的核心要素組件有關。因此，我們可以得出這樣一個結論：
downpour 寫道
結論 組件是整個DispatcherServlet的靈魂所在：它不僅是初始化主線中的初始化對象，同樣也是Http請求處理主線中的邏輯調度載體。
注：我們可以看到被我們劃為配置參數的那些變量都是boolean類型的，它們將在DispatcherServlet的初始化主線中起到一定的作用，我們在之后會使用源碼進行說明。而這些boolean值可以通過web.xml中的init-param值進行設定覆蓋（這是由HttpServletBean的特性帶來的）。
SpringMVC的運行體系
DispatcherServlet繼承結構和數據結構，實際上表述的是DispatcherServlet與另外兩大要素之間的關系：
- 繼承結構 —— DispatcherServlet與Spring容器（WebApplicationContext）之間的關系
- 數據結構 —— DispatcherServlet與組件之間的關系
所以，其實我們可以這么說：SpringMVC的整個運行體系，是由DispatcherServlet、組件和容器這三者共同構成的。
在這個運行體系中，DispatcherServlet是邏輯處理的調度中心，組件則是被調度的操作對象。而容器在這里所起到的作用，是協助DispatcherServlet更好地對組件進行管理。這就相當于一個工廠招了一大批的工人，并把工人劃分到一個統一的工作車間而便于管理。在工廠要進行生產活動時，只需要從工作車間把工人分派到相應的生產流水線上即可。
筆者在這里引用Spring官方reference中的一幅圖，對三者之間的關系進行簡單的描述：
注：在這幅圖中，我們除了看到在圖的左半邊DispatcherServlet、組件和容器這三者之間的調用關系以外，還可以看到SpringMVC的運行體系與其它運行體系之間存在著關系。有關這一點，我們在之后的討論中會詳細展開。
既然是三個元素之間的關系表述，我們必須以兩兩關系的形式進行歸納：
- DispatcherServlet - 容器 —— DispatcherServlet對容器進行初始化
- 容器 - 組件 —— 容器對組件進行全局管理
- DispatcherServlet - 組件 —— DispatcherServlet對組件進行邏輯調用
值得注意的是，在上面這幅圖中，三大元素之間的兩兩關系其實表現得并不明顯，尤其是"容器 - 組件"和"DispatcherServlet - 組件"之間的關系。這主要是由于Spring官方reference所給出的這幅圖是一個靜態的關系表述，如果從動態的觀點來對整個過程加以審視，我們就不得不將SpringMVC的運行體系與之前所提到的運行主線聯系在一起，看看這些元素在不同的邏輯主線中所起到的作用。
接下來，我們就分別看看DispatcherServlet的兩條運行主線。
DispatcherServlet的初始化主線
對于DispatcherServlet的初始化主線，我們首先應該明確幾個基本觀點：
- 初始化主線的驅動要素 —— servlet中的init方法
- 初始化主線的執行次序 —— HttpServletBean -> FrameworkServlet -> DispatcherServlet
- 初始化主線的操作對象 —— Spring容器（WebApplicationContext）和組件
這三個基本觀點，可以說是我們對之前所有討論的一個小結。明確了這些內容，我們就可以更加深入地看看DispatcherServlet初始化主線的過程：
在這幅圖中，我們站在一個動態的角度將DispatcherServlet、容器（WebApplicationContext）和組件這三者之間的關系表述出來，同時給出了這三者之間的運行順序和邏輯過程。讀者或許對其中的絕大多數細節還很陌生，甚至有一種無從下手的感覺。這沒有關系，大家可以首先抓住圖中的執行線，回憶一下之前有關DispatcherServlet的繼承結構和數據結構的內容。接下來，我們就圖中的內容逐一進行解釋。
【WebApplicationContext的初始化】
之前我們討論了DispatcherServlet對于WebApplicationContext的初始化是在FrameworkServlet中完成的，不過我們并沒有細究其中的細節。在默認情況下，這個初始化過程是由web.xml中的入口程序配置所驅動的：
Xml代碼 ?
<!-- Processes application requests -->
<servlet>
????<servlet-name>dispatcher</servlet-name>
????<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
????<load-on-startup>1</load-on-startup>
</servlet>
????????
<servlet-mapping>
????<servlet-name>dispatcher</servlet-name>
????<url-pattern>/**</url-pattern>
</servlet-mapping>
我們已經不止一次提到過這段配置，不過在這之前都沒有對這段配置做過什么很詳細的分析。事實上，這段入口程序的配置中隱藏了SpringMVC的兩大要素（核心分發器Dispatcher和核心配置文件[servlet-name]-servlet.xml）之間的關系表述：
downpour 寫道
在默認情況下，web.xml配置節點中<servlet-name>的值就是建立起核心分發器DispatcherServlet與核心配置文件之間聯系的橋梁。DispatcherServlet在初始化時會加載位置在/WEB-INF/[servlet-name]-servlet.xml的配置文件作為SpringMVC的核心配置。
SpringMVC在這里采用了一個"命名約定"的方法進行關系映射，這種方法很廉價也很管用。以上面的配置為例，我們就必須在/WEB-INF/目錄下，放一個名為dispatcher-servlet.xml的Spring配置文件作為SpringMVC的核心配置用以指定SpringMVC的基本組件聲明定義。
這看上去似乎有一點別扭，因為在實際項目中，我們通常喜歡把配置文件放在classpath下，并使用不同的package進行區分。例如，在基于Maven的項目結構中，所有的配置文件應置于src/main/resources目錄下，這樣才比較符合配置文件統一化管理的最佳實踐。
于是，Spring提供了一個初始化的配置選項，通過指定contextConfigLocation選項來自定義SpringMVC核心配置文件的位置：
Xml代碼 ?
<!-- Processes application requests -->
<servlet>
????<servlet-name>dispatcher</servlet-name>
????<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
????<init-param>
????????<param-name>contextConfigLocation</param-name>
????????<param-value>classpath:web/applicationContext-dispatcherServlet.xml</param-value>
????</init-param>
????<load-on-startup>1</load-on-startup>
</servlet>
????????
<servlet-mapping>
????<servlet-name>dispatcher</servlet-name>
????<url-pattern>/</url-pattern>
</servlet-mapping>
這樣一來，DispatcherServlet在初始化時，就會自動加載在classpath下，web這個package下名為applicationContext-dispatcherServlet.xml的文件作為其核心配置并用以初始化容器（WebApplicationContext）。
當然，這只是DispatcherServlet在進行WebApplicationContext初始化過程中的配置選項之一。我們可以在Spring的官方reference中找到相應的配置選項，有興趣的讀者可以參照reference的說明進行嘗試：
所有的這些配置選項，實際上都是為了讓DispatcherServlet對WebApplicationContext的初始化過程顯得更加自然。不過這只是完成了容器（WebApplicationContext）的構建工作，那么容器所管理的那些組件，又是如何進行初始化的呢？
downpour 寫道
結論 SpringMVC核心配置文件中所有的bean定義，就是SpringMVC的組件定義，也是DispatcherServlet在初始化容器（WebApplicationContext）時，所要進行初始化的組件。
在上一篇文章我們談到組件的時候就曾經提到，SpringMVC自身對于組件并未實現一套完整的管理機制，而是借用了Spring Framework核心框架中容器的概念，將所有的組件納入到容器中進行管理。所以，SpringMVC的核心配置文件使用與傳統Spring Framework相同的配置形式，而整個管理的體系也是一脈相承的。
注：Spring3.0之后，單獨為SpringMVC建立了專用的schema，從而使得我們可以使用Schema Based XML來對SpringMVC的組件進行定義。不過我們可以將其視作是傳統Spring配置的一個補充，而不要過于糾結不同的配置格式。
我們知道，SpringMVC的組件是一個個的接口定義，當我們在SpringMVC的核心配置文件中定義一個組件時，使用的卻是組件的實現類：
Xml代碼 ?
<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
????<property name="prefix" value="/" />
????<property name="suffix" value=".jsp" />
</bean>
這也就是Spring管理組件的模式：用具體的實現類來指定接口的行為方式。不同的實現類，代表著不同的組件行為模式，它們在Spring容器中是可以共存的：
Xml代碼 ?
<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
????<property name="prefix" value="/" />
????<property name="suffix" value=".jsp" />
</bean>
?
<bean class="org.springframework.web.servlet.view.freemarker.FreeMarkerViewResolver">
????<property name="prefix" value="/" />
????<property name="suffix" value=".ftl" />
</bean>
所以，Spring的容器就像是一個聚寶盆，它只負責承載對象，管理好對象的生命周期，而并不關心一個組件接口到底有多少種實現類或者行為模式。這也就是我們在上面那幅圖中，畫了多個HandlerMappings、HandlerAdapters和ViewResolvers的原因：一個組件的多種行為模式可以在容器中共存，容器將負責對這些實現類進行管理。而具體如何使用這些對象，則由應用程序自身來決定。
如此一來，我們可以大致概括一下WebApplicationContext初始化的兩個邏輯層次：
- DispatcherServlet負責對容器（WebApplicationContext）進行初始化。
- 容器（WebApplicationContext）將讀取SpringMVC的核心配置文件進行組件的實例化。
整個過程，我們把應用程序的日志級別調低，可以進行非常詳細的觀察：
引用
14:15:27,037 DEBUG StandardServletEnvironment:100 - Initializing new StandardServletEnvironment
14:15:27,128 DEBUG DispatcherServlet:115 - Initializing servlet 'dispatcher'
14:15:27,438? INFO DispatcherServlet:444 - FrameworkServlet 'dispatcher': initialization started
14:15:27,449 DEBUG DispatcherServlet:572 - Servlet with name 'dispatcher' will try to create custom WebApplicationContext context of class 'org.springframework.web.context.support.XmlWebApplicationContext', using parent context [null]
1571 [main] INFO /sample - Initializing Spring FrameworkServlet 'dispatcher'
14:15:27,505 DEBUG StandardServletEnvironment:100 - Initializing new StandardServletEnvironment
14:15:27,546? INFO XmlWebApplicationContext:495 - Refreshing WebApplicationContext for namespace 'dispatcher-servlet': startup date [Mon Feb 06 14:15:27 CST 2012]; root of context hierarchy
14:15:27,689? INFO XmlBeanDefinitionReader:315 - Loading XML bean definitions from class path resource [web/applicationContext-dispatcherServlet.xml]
14:15:27,872 DEBUG PluggableSchemaResolver:140 - Loading schema mappings from [META-INF/spring.schemas]
14:15:28,442 DEBUG PathMatchingResourcePatternResolver:550 - Looking for matching resources in directory tree [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller]
14:15:28,442 DEBUG PathMatchingResourcePatternResolver:612 - Searching directory [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller] for files matching pattern [D:/Work/Demo2do/Sample/target/classes/com/demo2do/sample/web/controller/**/*.class]
14:15:28,450 DEBUG PathMatchingResourcePatternResolver:351 - Resolved location pattern [classpath*:com/demo2do/sample/web/controller/**/*.class] to resources [file [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller\BlogController.class], file [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller\UserController.class]]
14:15:28,569 DEBUG ClassPathBeanDefinitionScanner:243 - Identified candidate component class: file [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller\BlogController.class]
14:15:28,571 DEBUG ClassPathBeanDefinitionScanner:243 - Identified candidate component class: file [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller\UserController.class]
14:15:28,634 DEBUG BeanDefinitionParserDelegate:497 - Neither XML 'id' nor 'name' specified - using generated bean name [org.springframework.web.servlet.view.InternalResourceViewResolver#0]
14:15:28,635 DEBUG XmlBeanDefinitionReader:216 - Loaded 19 bean definitions from location pattern [classpath:web/applicationContext-dispatcherServlet.xml]
14:15:28,635 DEBUG XmlWebApplicationContext:525 - Bean factory for WebApplicationContext for namespace 'dispatcher-servlet': org.springframework.beans.factory.support.DefaultListableBeanFactory@2321b59a: defining beans [org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping#0,org.springframework.format.support.FormattingConversionServiceFactoryBean#0,org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter#0,org.springframework.web.servlet.handler.MappedInterceptor#0,org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver#0,org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver#0,org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver#0,org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping,org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,blogController,userController,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.web.servlet.resource.ResourceHttpRequestHandler#0,org.springframework.web.servlet.handler.SimpleUrlHandlerMapping#0,org.springframework.web.servlet.view.InternalResourceViewResolver#0]; root of factory hierarchy
14:15:29,015 DEBUG RequestMappingHandlerMapping:98 - Looking for request mappings in application context: WebApplicationContext for namespace 'dispatcher-servlet': startup date [Mon Feb 06 14:15:27 CST 2012]; root of context hierarchy
14:15:29,037? INFO RequestMappingHandlerMapping:188 - Mapped "{[/blog],methods=[],params=[],headers=[],consumes=[],produces=[],custom=[]}" onto public org.springframework.web.servlet.ModelAndView com.demo2do.station.web.controller.BlogController.index()
14:15:29,039? INFO RequestMappingHandlerMapping:188 - Mapped "{[/login],methods=[],params=[],headers=[],consumes=[],produces=[],custom=[]}" onto public org.springframework.web.servlet.ModelAndView com.demo2do.station.web.controller.UserController.login(java.lang.String,java.lang.String)
14:15:29,040 DEBUG DefaultListableBeanFactory:458 - Finished creating instance of bean 'org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping#0'
14:15:29,460 DEBUG BeanNameUrlHandlerMapping:71 - Looking for URL mappings in application context: WebApplicationContext for namespace 'dispatcher-servlet': startup date [Mon Feb 06 14:15:27 CST 2012]; root of context hierarchy
14:15:29,539 DEBUG DefaultListableBeanFactory:458 - Finished creating instance of bean 'org.springframework.web.servlet.resource.ResourceHttpRequestHandler#0'
14:15:29,540 DEBUG DefaultListableBeanFactory:217 - Creating shared instance of singleton bean 'org.springframework.web.servlet.handler.SimpleUrlHandlerMapping#0'
14:15:29,555? INFO SimpleUrlHandlerMapping:314 - Mapped URL path [/static/**] onto handler 'org.springframework.web.servlet.resource.ResourceHttpRequestHandler#0'
14:15:29,556 DEBUG DefaultListableBeanFactory:458 - Finished creating instance of bean 'org.springframework.web.servlet.handler.SimpleUrlHandlerMapping#0'
14:15:29,827 DEBUG DispatcherServlet:523 - Published WebApplicationContext of servlet 'dispatcher' as ServletContext attribute with name [org.springframework.web.servlet.FrameworkServlet.CONTEXT.dispatcher]
14:15:29,827? INFO DispatcherServlet:463 - FrameworkServlet 'dispatcher': initialization completed in 2389 ms
14:15:29,827 DEBUG DispatcherServlet:136 - Servlet 'dispatcher' configured successfully
4047 [main] INFO org.mortbay.log - Started SelectChannelConnector@0.0.0.0:8080
Jetty Server started, use 4267 ms
在這段啟動日志（筆者進行了一定刪減）中，筆者刻意將WebApplicationContext的初始化的標志日志使用紅色的標進行區分，而將核心配置文件的讀取位置和組件定義初始化的標志日志使用藍色標記加以區分。相信有了這段日志的幫助，讀者應該可以對WebApplicationContext的初始化過程有了更加直觀的認識。
注：啟動日志是我們研究SpringMVC的主要途徑之一，之后我們還將反復使用這種方法對SpringMVC的運行過程進行研究。讀者應該仔細品味每一條日志的作用，從而能夠與之后的分析講解呼應起來。
或許讀者對WebApplicationContext對組件進行初始化的過程還有點困惑，大家不妨先將這個過程省略，把握住整個DispatcherServlet的大方向。我們在之后的文章中，還將對SpringMVC的組件、這些組件的定義以及組件的初始化方式做進一步的分析和探討。
到此為止，圖中順著FrameworkServlet的那些箭頭，我們已經交代清楚，讀者可以回味一下整個過程。
【獨立的WebApplicationContext體系】
獨立的WebApplicationContext體系，是SpringMVC初始化主線中的一個非常重要的概念。回顧一下剛才曾經提到過的DispatcherServlet、容器和組件三者之間的關系，我們在引用的那副官方reference的示意圖中，實際上已經包含了這一層意思：
downpour 寫道
結論 在DispatcherServlet初始化的過程中所構建的WebApplicationContext獨立于Spring自身的所構建的其他WebApplicationContext體系而存在。
稍有一些Spring編程經驗的程序員，對于下面的配置應該非常熟悉：
Xml代碼 ?
<context-param>
????<param-name>contextConfigLocation</param-name>
????<param-value>classpath:context/applicationContext-*.xml</param-value>
</context-param>
????
<listener>
????<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
在上面的代碼中，我們定義了一個Listener，它會在整個Web應用程序啟動的時候運行一次，并初始化傳統意義上的Spring的容器。這也是一般情況下，當并不使用SpringMVC作為我們的表示層解決方案，卻希望在我們的Web應用程序中使用Spring相關功能時所采取的一種配置方式。
如果我們要在這里引入SpringMVC，整個配置看上去就像這樣：
Xml代碼 ?
<context-param>
????<param-name>contextConfigLocation</param-name>
????<param-value>classpath:context/applicationContext-*.xml</param-value>
</context-param>
????
<listener>
????<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
?
<!-- Processes application requests -->
<servlet>
????<servlet-name>dispatcher</servlet-name>
????<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
????<init-param>
????????<param-name>contextConfigLocation</param-name>
????????<param-value>classpath:web/applicationContext-dispatcherServlet.xml</param-value>
????</init-param>
????<load-on-startup>1</load-on-startup>
</servlet>
????????
<servlet-mapping>
????<servlet-name>dispatcher</servlet-name>
????<url-pattern>/</url-pattern>
</servlet-mapping>
在這種情況下，DispatcherServlet和ContextLoaderListener會分別構建不同作用范圍的容器（WebApplicationContext）。我們可以引入兩個不同的概念來對其進行表述：ContextLoaderListener所初始化的容器，我們稱之為Root WebApplicationContext；而DispatcherServlet所初始化的容器，是SpringMVC WebApplicationContext。
同樣采取日志分析的方法，加入了ContextLoaderListener之后，整個啟動日志變成了這樣：
引用
[main] INFO /sample - Initializing Spring root WebApplicationContext
14:56:42,261? INFO ContextLoader:272 - Root WebApplicationContext: initialization started
14:56:42,343 DEBUG StandardServletEnvironment:100 - Initializing new StandardServletEnvironment
14:56:42,365? INFO XmlWebApplicationContext:495 - Refreshing Root WebApplicationContext: startup date [Mon Feb 06 14:56:42 CST 2012]; root of context hierarchy
14:56:42,441 DEBUG PathMatchingResourcePatternResolver:550 - Looking for matching resources in directory tree [D:\Work\Demo2do\Sample\target\classes\context]
14:56:42,442 DEBUG PathMatchingResourcePatternResolver:612 - Searching directory [D:\Work\Demo2do\Sample\target\classes\context] for files matching pattern [D:/Work/Demo2do/Sample/target/classes/context/applicationContext-*.xml]
14:56:42,446 DEBUG PathMatchingResourcePatternResolver:351 - Resolved location pattern [classpath:context/applicationContext-*.xml] to resources [file [D:\Work\Demo2do\Sample\target\classes\context\applicationContext-configuration.xml]]
14:56:42,447? INFO XmlBeanDefinitionReader:315 - Loading XML bean definitions from file [D:\Work\Demo2do\Sample\target\classes\context\applicationContext-configuration.xml]
14:56:42,486 DEBUG PluggableSchemaResolver:140 - Loading schema mappings from [META-INF/spring.schemas]
14:56:42,597 DEBUG DefaultBeanDefinitionDocumentReader:108 - Loading bean definitions
14:56:42,658 DEBUG PathMatchingResourcePatternResolver:550 - Looking for matching resources in directory tree [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample]
14:56:42,699 DEBUG ClassPathBeanDefinitionScanner:243 - Identified candidate component class: file [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\service\impl\BlogServiceImpl.class]
14:56:42,750 DEBUG XmlBeanDefinitionReader:216 - Loaded 5 bean definitions from location pattern [classpath:context/applicationContext-*.xml]
14:56:42,750 DEBUG XmlWebApplicationContext:525 - Bean factory for Root WebApplicationContext: org.springframework.beans.factory.support.DefaultListableBeanFactory@478e4327: defining beans [blogService,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor]; root of factory hierarchy
14:56:42,860 DEBUG ContextLoader:296 - Published root WebApplicationContext as ServletContext attribute with name [org.springframework.web.context.WebApplicationContext.ROOT]
14:56:42,860? INFO ContextLoader:301 - Root WebApplicationContext: initialization completed in 596 ms
14:56:42,935 DEBUG DispatcherServlet:115 - Initializing servlet 'dispatcher'
14:56:42,974? INFO DispatcherServlet:444 - FrameworkServlet 'dispatcher': initialization started
14:56:42,974 DEBUG DispatcherServlet:572 - Servlet with name 'dispatcher' will try to create custom WebApplicationContext context of class 'org.springframework.web.context.support.XmlWebApplicationContext', using parent context [Root WebApplicationContext: startup date [Mon Feb 06 14:56:42 CST 2012]; root of context hierarchy]
14:56:42,979? INFO XmlWebApplicationContext:495 - Refreshing WebApplicationContext for namespace 'dispatcher-servlet': startup date [Mon Feb 06 14:56:42 CST 2012]; parent: Root WebApplicationContext
14:56:42,983? INFO XmlBeanDefinitionReader:315 - Loading XML bean definitions from class path resource [web/applicationContext-dispatcherServlet.xml]
14:56:42,987 DEBUG PluggableSchemaResolver:140 - Loading schema mappings from [META-INF/spring.schemas]
14:56:43,035 DEBUG DefaultBeanDefinitionDocumentReader:108 - Loading bean definitions
14:56:43,075 DEBUG PathMatchingResourcePatternResolver:550 - Looking for matching resources in directory tree [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller]
14:56:43,075 DEBUG PathMatchingResourcePatternResolver:612 - Searching directory [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller] for files matching pattern [D:/Work/Demo2do/Sample/target/classes/com/demo2do/sample/web/controller/**/*.class]
14:56:43,077 DEBUG PathMatchingResourcePatternResolver:351 - Resolved location pattern [classpath*:com/demo2do/sample/web/controller/**/*.class] to resources [file [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller\BlogController.class], file [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller\UserController.class]]
14:56:43,079 DEBUG ClassPathBeanDefinitionScanner:243 - Identified candidate component class: file [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller\BlogController.class]
14:56:43,080 DEBUG ClassPathBeanDefinitionScanner:243 - Identified candidate component class: file [D:\Work\Demo2do\Sample\target\classes\com\demo2do\sample\web\controller\UserController.class]
14:56:43,089 DEBUG XmlBeanDefinitionReader:216 - Loaded 19 bean definitions from location pattern [classpath:web/applicationContext-dispatcherServlet.xml]
14:56:43,089 DEBUG XmlWebApplicationContext:525 - Bean factory for WebApplicationContext for namespace 'dispatcher-servlet': org.springframework.beans.factory.support.DefaultListableBeanFactory@5e6458a6: defining beans [org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping#0,org.springframework.format.support.FormattingConversionServiceFactoryBean#0,org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter#0,org.springframework.web.servlet.handler.MappedInterceptor#0,org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver#0,org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver#0,org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver#0,org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping,org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,blogController,userController,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.web.servlet.resource.ResourceHttpRequestHandler#0,org.springframework.web.servlet.handler.SimpleUrlHandlerMapping#0,org.springframework.web.servlet.view.InternalResourceViewResolver#0]; parent: org.springframework.beans.factory.support.DefaultListableBeanFactory@478e4327
14:56:43,323 DEBUG RequestMappingHandlerMapping:98 - Looking for request mappings in application context: WebApplicationContext for namespace 'dispatcher-servlet': startup date [Mon Feb 06 14:56:42 CST 2012]; parent: Root WebApplicationContext
14:56:43,345? INFO RequestMappingHandlerMapping:188 - Mapped "{[/blog],methods=[],params=[],headers=[],consumes=[],produces=[],custom=[]}" onto public org.springframework.web.servlet.ModelAndView com.demo2do.sample.web.controller.BlogController.index()
14:56:43,346? INFO RequestMappingHandlerMapping:188 - Mapped "{[/login],methods=[],params=[],headers=[],consumes=[],produces=[],custom=[]}" onto public org.springframework.web.servlet.ModelAndView com.demo2do.sample.web.controller.UserController.login(java.lang.String,java.lang.String)
14:56:43,707 DEBUG BeanNameUrlHandlerMapping:71 - Looking for URL mappings in application context: WebApplicationContext for namespace 'dispatcher-servlet': startup date [Mon Feb 06 14:56:42 CST 2012]; parent: Root WebApplicationContext
14:56:43,828? INFO SimpleUrlHandlerMapping:314 - Mapped URL path [/static/**] onto handler 'org.springframework.web.servlet.resource.ResourceHttpRequestHandler#0'
14:56:43,883 DEBUG DispatcherServlet:523 - Published WebApplicationContext of servlet 'dispatcher' as ServletContext attribute with name [org.springframework.web.servlet.FrameworkServlet.CONTEXT.dispatcher]
14:56:43,883? INFO DispatcherServlet:463 - FrameworkServlet 'dispatcher': initialization completed in 909 ms
14:56:43,883 DEBUG DispatcherServlet:136 - Servlet 'dispatcher' configured successfully
2687 [main] INFO org.mortbay.log - Started SelectChannelConnector@0.0.0.0:8080
Jetty Server started, use 2901 ms
整個啟動日志被我們分為了2段。第一段的過程初始化的是Root WebApplicationContext；而第二段的過程初始化的是SpringMVC的WebApplicationContext。我們還是使用了紅色的標記和藍色標記指出了在整個初始化過程中的一些重要事件。其中，有這樣一段內容值得我們注意：
引用
14:56:42,979? INFO XmlWebApplicationContext:495 - Refreshing WebApplicationContext for namespace 'dispatcher-servlet': startup date [Mon Feb 06 14:56:42 CST 2012]; parent: Root WebApplicationContext
在這段日志中，非常明確地指出了SpringMVC WebApplicationContext與Root WebApplicationContext之間的關系：從屬關系。因為根據這段日志的表述，SpringMVC WebApplicationContext能夠感知到Root WebApplicationContext的存在，并且將其作為parent容器。
Spring正是使用這種Parent-Child的容器關系來對不同的編程層次進行劃分。這種我們俗稱的父子關系實際上不僅僅是一種從屬關系，更是一種引用關系。從剛才的日志分析中，我們可以看出：SpringMVC中所定義的一切組件能夠無縫地與Root WebApplicationContext中的組件整合。
到此為止，我們針對圖中以web.xml為核心的箭頭分支進行了講解，讀者可以將圖中的內容與上面的文字說明對照再次加以理解。
【組件默認行為的指定】
DispatcherServlet的初始化主線的執行體系是順著其繼承結構依次進行的，我們在之前曾經討論過它的執行次序。所以，只有在FrameworkServlet完成了對于WebApplicationContext和組件的初始化之后，執行權才被正式轉移到DispatcherServlet中。我們可以來看看DispatcherServlet此時究竟干了哪些事：
Java代碼 ?
/**
* This implementation calls {@link #initStrategies}.
*/
@Override
protected void onRefresh(ApplicationContext context) {
????initStrategies(context);
}
?
/**
* Initialize the strategy objects that this servlet uses.
* <p>May be overridden in subclasses in order to initialize further strategy objects.
*/
protected void initStrategies(ApplicationContext context) {
????initMultipartResolver(context);
????initLocaleResolver(context);
????initThemeResolver(context);
????initHandlerMappings(context);
????initHandlerAdapters(context);
????initHandlerExceptionResolvers(context);
????initRequestToViewNameTranslator(context);
????initViewResolvers(context);
????initFlashMapManager(context);
}
onRefresh是FrameworkServlet中預留的擴展方法，在DispatcherServlet中做了一個基本實現：initStrategies。我們粗略一看，很容易就能明白DispatcherServlet到底在這里干些什么了：初始化組件。
讀者或許會問，組件不是已經在WebApplicationContext初始化的時候已經被初始化過了嘛？這里所謂的組件初始化，指的又是什么呢？讓我們來看看其中的一個方法的源碼：
Java代碼 ?
/**
* Initialize the MultipartResolver used by this class.
* <p>If no bean is defined with the given name in the BeanFactory for this namespace,
* no multipart handling is provided.
*/
private void initMultipartResolver(ApplicationContext context) {
????try {
????????this.multipartResolver = context.getBean(MULTIPART_RESOLVER_BEAN_NAME, MultipartResolver.class);
????????if (logger.isDebugEnabled()) {
????????????logger.debug("Using MultipartResolver [" + this.multipartResolver + "]");
????????}
????} catch (NoSuchBeanDefinitionException ex) {
????????// Default is no multipart resolver.
????????this.multipartResolver = null;
????????if (logger.isDebugEnabled()) {
????????????logger.debug("Unable to locate MultipartResolver with name '" + MULTIPART_RESOLVER_BEAN_NAME +
????????????????????"': no multipart request handling provided");
????????}
????}
}
原來，這里的初始化，指的是DispatcherServlet從容器（WebApplicationContext）中讀取組件的實現類，并緩存于DispatcherServlet內部的過程。還記得我們之前給出的DispatcherServlet的數據結構嗎？這些位于DispatcherServlet內部的組件實際上只是一些來源于容器緩存實例，不過它們同樣也是DispatcherServlet進行后續操作的基礎。
注：我們在第一篇文章中就曾經提到過Servlet實例內部的屬性的訪問有線程安全問題。而在這里，我們可以看到所有的組件都以Servlet內部屬性的形式被調用，充分證實了這些組件本身也都是無狀態的單例對象，所以我們在這里不必考慮線程安全的問題。
如果對上面的代碼加以詳細分析，我們會發現initMultipartResolver的過程是查找特定MultipartResolver實現類的過程。因為在容器中查找組件的時候，采取的是根據特定名稱（MULTIPART_RESOLVER_BEAN_NAME）進行查找的策略。由此，我們可以看到DispatcherServlet進行組件初始化的特點：
downpour 寫道
結論 DispatcherServlet中對于組件的初始化過程實際上是應用程序在WebApplicationContext中選擇和查找組件實現類的過程，也是指定組件在SpringMVC中的默認行為方式的過程。
除了根據特定名稱進行查找的策略以外，我們還對DispatcherServlet中指定SpringMVC默認行為方式的其他的策略進行的總結：
- 名稱查找 —— 根據bean的名字在容器中查找相應的實現類
- 自動搜索 —— 自動搜索容器中所有某個特定組件（接口）的所有實現類
- 默認配置 —— 根據一個默認的配置文件指定進行實現類加載
這三條策略恰巧在initHandlerMappings的過程中都有體現，讀者可以從其源碼中找到相應的線索：
Java代碼 ?
private void initHandlerAdapters(ApplicationContext context) {
????this.handlerAdapters = null;
?
????if (this.detectAllHandlerAdapters) {
????????// Find all HandlerAdapters in the ApplicationContext, including ancestor contexts.
????????Map<String, HandlerAdapter> matchingBeans = BeanFactoryUtils.beansOfTypeIncludingAncestors(context, HandlerAdapter.class, true, false);
????????if (!matchingBeans.isEmpty()) {
????????????this.handlerAdapters = new ArrayList<HandlerAdapter>(matchingBeans.values());
????????????// We keep HandlerAdapters in sorted order.
????????????OrderComparator.sort(this.handlerAdapters);
????????}
????}
????else {
????????try {
????????????HandlerAdapter ha = context.getBean(HANDLER_ADAPTER_BEAN_NAME, HandlerAdapter.class);
????????????this.handlerAdapters = Collections.singletonList(ha);
????????}
????????catch (NoSuchBeanDefinitionException ex) {
????????????// Ignore, we'll add a default HandlerAdapter later.
????????}
????}
?
????// Ensure we have at least some HandlerAdapters, by registering
????// default HandlerAdapters if no other adapters are found.
????if (this.handlerAdapters == null) {
????????this.handlerAdapters = getDefaultStrategies(context, HandlerAdapter.class);
????????if (logger.isDebugEnabled()) {
????????????logger.debug("No HandlerAdapters found in servlet '" + getServletName() + "': using default");
????????}
????}
}
這里有必要對"默認策略"做一個簡要的說明。SpringMVC為一些核心組件設置了默認行為方式的說明，這個說明以一個properties文件的形式位于SpringMVC分發包（例如spring-webmvc-3.1.0.RELEASE.jar）的內部：
我們可以觀察一下DispatcherServlet.properties的內容：
引用
# Default implementation classes for DispatcherServlet's strategy interfaces.
# Used as fallback when no matching beans are found in the DispatcherServlet context.
# Not meant to be customized by application developers.
org.springframework.web.servlet.LocaleResolver=org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver
org.springframework.web.servlet.ThemeResolver=org.springframework.web.servlet.theme.FixedThemeResolver
org.springframework.web.servlet.HandlerMapping=org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping,\
org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping
org.springframework.web.servlet.HandlerAdapter=org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,\
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter
org.springframework.web.servlet.HandlerExceptionResolver=org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerExceptionResolver,\
org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver,\
org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver
org.springframework.web.servlet.RequestToViewNameTranslator=org.springframework.web.servlet.view.DefaultRequestToViewNameTranslator
org.springframework.web.servlet.ViewResolver=org.springframework.web.servlet.view.InternalResourceViewResolver
org.springframework.web.servlet.FlashMapManager=org.springframework.web.servlet.support.DefaultFlashMapManager
結合剛才initHandlerMappings的源碼，我們可以發現如果沒有開啟detectAllHandlerAdapters選項或者根據HANDLER_ADAPTER_BEAN_NAME的名稱沒有找到相應的組件實現類，就會使用DispatcherServlet.properties文件中對于HandlerMapping接口的實現來進行組件默認行為的初始化。
由此可見，DispatcherServlet.properties中所指定的所有接口的實現方式在Spring的容器WebApplicationContext中總有相應的定義。這一點，我們在組件的討論中還會詳談。
這個部分我們的側重點是圖中DispatcherServlet與容器之間的關系。讀者需要理解的是圖中為什么會有兩份組件定義，它們之間的區別在哪里，以及DispatcherServlet在容器中查找組件的三種策略。
小結
在本文中，我們對SpringMVC的核心類：DispatcherServlet進行了一番梳理。也對整個SpringMVC的兩條主線之一的初始化主線做了詳細的分析。
對于DispatcherServlet而言，重要的其實并不是這個類中的代碼和邏輯，而是應該掌握這個類在整個框架中的作用以及與SpringMVC中其他要素的關系。
對于初始化主線而言，核心其實僅僅在于那張筆者為大家精心打造的圖。讀者只要掌握了這張圖，相信對整個SpringMVC的初始化過程會有一個全新的認識。
轉載于:https://www.cnblogs.com/xiangxs/p/5052025.html
總結
以上是生活随笔為你收集整理的SpringMVC深度探险（三） —— DispatcherServlet与初始化主线的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 你好，在不？波形护栏螺栓终拧扭矩的单位是
- 下一篇： JavaScript的编码规范