javascript
SpringMVC深度探险（三） —— DispatcherServlet与初始化主线
本文是專欄文章（SpringMVC深度探險(xiǎn)）系列的文章之一，博客地址為：http://downpour.iteye.com/blog/1341459。
在上一篇文章中，我們給出了構(gòu)成SpringMVC應(yīng)用程序的三要素以及三要素的設(shè)計(jì)過程。讓我們來歸納一下整個(gè)設(shè)計(jì)過程中的一些要點(diǎn)：
- SpringMVC將Http處理流程抽象為一個(gè)又一個(gè)處理單元
- SpringMVC定義了一系列組件（接口）與所有的處理單元對應(yīng)起來
- SpringMVC由DispatcherServlet貫穿始終，并將所有的組件串聯(lián)起來
在整個(gè)過程中，組件和DispatcherServlet總是維持著一個(gè)相互支撐的關(guān)系：
- DispatcherServlet —— 串聯(lián)起整個(gè)邏輯主線，是整個(gè)框架的心臟
- 組件 —— 邏輯處理單元的程序化表示，起到承上啟下的作用，是SpringMVC行為模式的實(shí)際承載者
在本系列接下來的兩篇文章中，我們將分別討論DispatcherServlet和組件的相關(guān)內(nèi)容。本文討論DispatcherServlet，而下一篇?jiǎng)t重點(diǎn)分析組件。
有關(guān)DispatcherServlet，我們想從構(gòu)成DispatcherServlet的體系結(jié)構(gòu)入手，再根據(jù)不同的邏輯主線分別加以分析，希望能夠幫助讀者整理出學(xué)習(xí)SpringMVC核心類的思路。
DispatcherServlet的體系結(jié)構(gòu)
通過不同的角度來觀察DispatcherServlet會(huì)得到不同的結(jié)論。我們在這里選取了三個(gè)不同的角度：運(yùn)行特性、繼承結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)。
【運(yùn)行主線】
從DispatcherServlet所實(shí)現(xiàn)的接口來看，DispatcherServlet的核心本質(zhì)：是一個(gè)Servlet。這個(gè)結(jié)論似乎很幼稚，不過這個(gè)幼稚的結(jié)論卻蘊(yùn)含了一個(gè)對整個(gè)框架都至關(guān)重要的內(nèi)在原則：Servlet可以根據(jù)其特性進(jìn)行運(yùn)行主線的劃分。
根據(jù)Servlet規(guī)范的定義，Servlet中的兩大核心方法init方法和service方法，它們的運(yùn)行時(shí)間和觸發(fā)條件都截然不同：
1. init方法
在整個(gè)系統(tǒng)啟動(dòng)時(shí)運(yùn)行，且只運(yùn)行一次。因此，在init方法中我們往往會(huì)對整個(gè)應(yīng)用程序進(jìn)行初始化操作。這些初始化操作可能包括對容器（WebApplicationContext）的初始化、組件和外部資源的初始化等等。
2. service方法
在整個(gè)系統(tǒng)運(yùn)行的過程中處于偵聽模式，偵聽并處理所有的Web請求。因此，在service及其相關(guān)方法中，我們看到的則是對Http請求的處理流程。
因而在這里，Servlet的這一特性就被SpringMVC用于對不同的邏輯職責(zé)加以劃分，從而形成兩條互不相關(guān)的邏輯運(yùn)行主線：
- 初始化主線 —— 負(fù)責(zé)對SpringMVC的運(yùn)行要素進(jìn)行初始化
- Http請求處理主線 —— 負(fù)責(zé)對SpringMVC中的組件進(jìn)行邏輯調(diào)度完成對Http請求的處理
對于一個(gè)MVC框架而言，運(yùn)行主線的劃分非常重要。因?yàn)橹挥信宄煌倪\(yùn)行主線，我們才能針對不同的運(yùn)行主線采取不同的研究策略。而我們在這個(gè)系列中的絕大多數(shù)分析的切入點(diǎn)，也是圍繞著不同的運(yùn)行主線進(jìn)行的。
注：SpringMVC運(yùn)行主線的劃分依據(jù)是Servlet對象中不同方法的生命周期。事實(shí)上，幾乎所有的MVC都是以此為依據(jù)來進(jìn)行運(yùn)行主線的劃分。這進(jìn)一步可以證明所有的MVC框架的核心基礎(chǔ)還是Servlet規(guī)范，而設(shè)計(jì)理念的差異也導(dǎo)致了不同的框架走向了完全不同的發(fā)展道路。
【繼承結(jié)構(gòu)】
除了運(yùn)行主線的劃分以外，我們再關(guān)注一下DispatcherServlet的繼承結(jié)構(gòu)：
在這個(gè)繼承結(jié)構(gòu)中，我們可以看到DispatcherServlet在其繼承樹中包含了2個(gè)Spring的支持類：HttpServletBean和FrameworkServlet。我們分別來討論一下這兩個(gè)Spring的支持類在這里所起到的作用。
HttpServletBean是Spring對于Servlet最低層次的抽象。在這一層抽象中，Spring會(huì)將這個(gè)Servlet視作是一個(gè)Spring的bean，并將init-param中的值作為bean的屬性注入進(jìn)來：
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方法的執(zhí)行特性，將一個(gè)普通的Servlet與Spring的容器聯(lián)系在了一起。在這其中起到核心作用的代碼是：BeanWrapper bw = PropertyAccessorFactory.forBeanPropertyAccess(this);將當(dāng)前的這個(gè)Servlet類轉(zhuǎn)化為一個(gè)BeanWrapper，從而能夠以Spring的方式來對init-param的值進(jìn)行注入。BeanWrapper的相關(guān)知識屬于Spring Framework的內(nèi)容，我們在這里不做詳細(xì)展開，讀者可以具體參考HttpServletBean的注釋獲得更多的信息。
FrameworkServlet則是在HttpServletBean的基礎(chǔ)之上的進(jìn)一步抽象。通過FrameworkServlet真正初始化了一個(gè)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初始化的核心代碼。從中我們可以看到這個(gè)FrameworkServlet將調(diào)用其內(nèi)部的方法initWebApplicationContext()對Spring的容器（WebApplicationContext）進(jìn)行初始化。同時(shí)，FrameworkServlet還暴露了與之通訊的結(jié)構(gòu)可供子類調(diào)用：
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）的初始化過程詳加探查，稍后我們會(huì)討論一些WebApplicationContext初始化過程中的配置選項(xiàng)。不過讀者可以在這里體會(huì)到：FrameworkServlet在其內(nèi)部初始化了一個(gè)Spring的容器（WebApplicationContext）并暴露了相關(guān)的操作接口，因而繼承自FrameworkServlet的DispatcherServlet，也就直接擁有了與WebApplicationContext進(jìn)行通信的能力。
通過對DispatcherServlet繼承結(jié)構(gòu)的研究，我們可以明確：
downpour 寫道
結(jié)論 DispatcherServlet的繼承體系架起了DispatcherServlet與Spring容器進(jìn)行溝通的橋梁。
【數(shù)據(jù)結(jié)構(gòu)】
在上一篇文章中，我們曾經(jīng)提到過DispatcherServlet的數(shù)據(jù)結(jié)構(gòu)：
我們可以把在上面這張圖中所構(gòu)成DispatcherServlet的數(shù)據(jù)結(jié)構(gòu)主要分為兩類（我們在這里用一根分割線將其分割開來）：
- 配置參數(shù) —— 控制SpringMVC組件的初始化行為方式
- 核心組件 —— SpringMVC的核心邏輯處理組件
可以看到，這兩類數(shù)據(jù)結(jié)構(gòu)都與SpringMVC中的核心要素組件有關(guān)。因此，我們可以得出這樣一個(gè)結(jié)論：
downpour 寫道
結(jié)論 組件是整個(gè)DispatcherServlet的靈魂所在：它不僅是初始化主線中的初始化對象，同樣也是Http請求處理主線中的邏輯調(diào)度載體。
注：我們可以看到被我們劃為配置參數(shù)的那些變量都是boolean類型的，它們將在DispatcherServlet的初始化主線中起到一定的作用，我們在之后會(huì)使用源碼進(jìn)行說明。而這些boolean值可以通過web.xml中的init-param值進(jìn)行設(shè)定覆蓋（這是由HttpServletBean的特性帶來的）。
SpringMVC的運(yùn)行體系
DispatcherServlet繼承結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)，實(shí)際上表述的是DispatcherServlet與另外兩大要素之間的關(guān)系：
- 繼承結(jié)構(gòu) —— DispatcherServlet與Spring容器（WebApplicationContext）之間的關(guān)系
- 數(shù)據(jù)結(jié)構(gòu) —— DispatcherServlet與組件之間的關(guān)系
所以，其實(shí)我們可以這么說：SpringMVC的整個(gè)運(yùn)行體系，是由DispatcherServlet、組件和容器這三者共同構(gòu)成的。
在這個(gè)運(yùn)行體系中，DispatcherServlet是邏輯處理的調(diào)度中心，組件則是被調(diào)度的操作對象。而容器在這里所起到的作用，是協(xié)助DispatcherServlet更好地對組件進(jìn)行管理。這就相當(dāng)于一個(gè)工廠招了一大批的工人，并把工人劃分到一個(gè)統(tǒng)一的工作車間而便于管理。在工廠要進(jìn)行生產(chǎn)活動(dòng)時(shí)，只需要從工作車間把工人分派到相應(yīng)的生產(chǎn)流水線上即可。
筆者在這里引用Spring官方reference中的一幅圖，對三者之間的關(guān)系進(jìn)行簡單的描述：
注：在這幅圖中，我們除了看到在圖的左半邊DispatcherServlet、組件和容器這三者之間的調(diào)用關(guān)系以外，還可以看到SpringMVC的運(yùn)行體系與其它運(yùn)行體系之間存在著關(guān)系。有關(guān)這一點(diǎn)，我們在之后的討論中會(huì)詳細(xì)展開。
既然是三個(gè)元素之間的關(guān)系表述，我們必須以兩兩關(guān)系的形式進(jìn)行歸納：
- DispatcherServlet - 容器 —— DispatcherServlet對容器進(jìn)行初始化
- 容器 - 組件 —— 容器對組件進(jìn)行全局管理
- DispatcherServlet - 組件 —— DispatcherServlet對組件進(jìn)行邏輯調(diào)用
值得注意的是，在上面這幅圖中，三大元素之間的兩兩關(guān)系其實(shí)表現(xiàn)得并不明顯，尤其是"容器 - 組件"和"DispatcherServlet - 組件"之間的關(guān)系。這主要是由于Spring官方reference所給出的這幅圖是一個(gè)靜態(tài)的關(guān)系表述，如果從動(dòng)態(tài)的觀點(diǎn)來對整個(gè)過程加以審視，我們就不得不將SpringMVC的運(yùn)行體系與之前所提到的運(yùn)行主線聯(lián)系在一起，看看這些元素在不同的邏輯主線中所起到的作用。
接下來，我們就分別看看DispatcherServlet的兩條運(yùn)行主線。
DispatcherServlet的初始化主線
對于DispatcherServlet的初始化主線，我們首先應(yīng)該明確幾個(gè)基本觀點(diǎn)：
- 初始化主線的驅(qū)動(dòng)要素 —— servlet中的init方法
- 初始化主線的執(zhí)行次序 —— HttpServletBean -> FrameworkServlet -> DispatcherServlet
- 初始化主線的操作對象 —— Spring容器（WebApplicationContext）和組件
這三個(gè)基本觀點(diǎn)，可以說是我們對之前所有討論的一個(gè)小結(jié)。明確了這些內(nèi)容，我們就可以更加深入地看看DispatcherServlet初始化主線的過程：
在這幅圖中，我們站在一個(gè)動(dòng)態(tài)的角度將DispatcherServlet、容器（WebApplicationContext）和組件這三者之間的關(guān)系表述出來，同時(shí)給出了這三者之間的運(yùn)行順序和邏輯過程。讀者或許對其中的絕大多數(shù)細(xì)節(jié)還很陌生，甚至有一種無從下手的感覺。這沒有關(guān)系，大家可以首先抓住圖中的執(zhí)行線，回憶一下之前有關(guān)DispatcherServlet的繼承結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)的內(nèi)容。接下來，我們就圖中的內(nèi)容逐一進(jìn)行解釋。
【W(wǎng)ebApplicationContext的初始化】
之前我們討論了DispatcherServlet對于WebApplicationContext的初始化是在FrameworkServlet中完成的，不過我們并沒有細(xì)究其中的細(xì)節(jié)。在默認(rèn)情況下，這個(gè)初始化過程是由web.xml中的入口程序配置所驅(qū)動(dòng)的：
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>
我們已經(jīng)不止一次提到過這段配置，不過在這之前都沒有對這段配置做過什么很詳細(xì)的分析。事實(shí)上，這段入口程序的配置中隱藏了SpringMVC的兩大要素（核心分發(fā)器Dispatcher和核心配置文件[servlet-name]-servlet.xml）之間的關(guān)系表述：
downpour 寫道
在默認(rèn)情況下，web.xml配置節(jié)點(diǎn)中<servlet-name>的值就是建立起核心分發(fā)器DispatcherServlet與核心配置文件之間聯(lián)系的橋梁。DispatcherServlet在初始化時(shí)會(huì)加載位置在/WEB-INF/[servlet-name]-servlet.xml的配置文件作為SpringMVC的核心配置。
SpringMVC在這里采用了一個(gè)"命名約定"的方法進(jìn)行關(guān)系映射，這種方法很廉價(jià)也很管用。以上面的配置為例，我們就必須在/WEB-INF/目錄下，放一個(gè)名為dispatcher-servlet.xml的Spring配置文件作為SpringMVC的核心配置用以指定SpringMVC的基本組件聲明定義。
這看上去似乎有一點(diǎn)別扭，因?yàn)樵趯?shí)際項(xiàng)目中，我們通常喜歡把配置文件放在classpath下，并使用不同的package進(jìn)行區(qū)分。例如，在基于Maven的項(xiàng)目結(jié)構(gòu)中，所有的配置文件應(yīng)置于src/main/resources目錄下，這樣才比較符合配置文件統(tǒng)一化管理的最佳實(shí)踐。
于是，Spring提供了一個(gè)初始化的配置選項(xiàng)，通過指定contextConfigLocation選項(xiàng)來自定義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在初始化時(shí)，就會(huì)自動(dòng)加載在classpath下，web這個(gè)package下名為applicationContext-dispatcherServlet.xml的文件作為其核心配置并用以初始化容器（WebApplicationContext）。
當(dāng)然，這只是DispatcherServlet在進(jìn)行WebApplicationContext初始化過程中的配置選項(xiàng)之一。我們可以在Spring的官方reference中找到相應(yīng)的配置選項(xiàng)，有興趣的讀者可以參照reference的說明進(jìn)行嘗試：
所有的這些配置選項(xiàng)，實(shí)際上都是為了讓DispatcherServlet對WebApplicationContext的初始化過程顯得更加自然。不過這只是完成了容器（WebApplicationContext）的構(gòu)建工作，那么容器所管理的那些組件，又是如何進(jìn)行初始化的呢？
downpour 寫道
結(jié)論 SpringMVC核心配置文件中所有的bean定義，就是SpringMVC的組件定義，也是DispatcherServlet在初始化容器（WebApplicationContext）時(shí)，所要進(jìn)行初始化的組件。
在上一篇文章我們談到組件的時(shí)候就曾經(jīng)提到，SpringMVC自身對于組件并未實(shí)現(xiàn)一套完整的管理機(jī)制，而是借用了Spring Framework核心框架中容器的概念，將所有的組件納入到容器中進(jìn)行管理。所以，SpringMVC的核心配置文件使用與傳統(tǒng)Spring Framework相同的配置形式，而整個(gè)管理的體系也是一脈相承的。
注：Spring3.0之后，單獨(dú)為SpringMVC建立了專用的schema，從而使得我們可以使用Schema Based XML來對SpringMVC的組件進(jìn)行定義。不過我們可以將其視作是傳統(tǒng)Spring配置的一個(gè)補(bǔ)充，而不要過于糾結(jié)不同的配置格式。
我們知道，SpringMVC的組件是一個(gè)個(gè)的接口定義，當(dāng)我們在SpringMVC的核心配置文件中定義一個(gè)組件時(shí)，使用的卻是組件的實(shí)現(xiàn)類：
Xml代碼 ?
<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
????<property name="prefix" value="/" />
????<property name="suffix" value=".jsp" />
</bean>
這也就是Spring管理組件的模式：用具體的實(shí)現(xiàn)類來指定接口的行為方式。不同的實(shí)現(xiàn)類，代表著不同的組件行為模式，它們在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的容器就像是一個(gè)聚寶盆，它只負(fù)責(zé)承載對象，管理好對象的生命周期，而并不關(guān)心一個(gè)組件接口到底有多少種實(shí)現(xiàn)類或者行為模式。這也就是我們在上面那幅圖中，畫了多個(gè)HandlerMappings、HandlerAdapters和ViewResolvers的原因：一個(gè)組件的多種行為模式可以在容器中共存，容器將負(fù)責(zé)對這些實(shí)現(xiàn)類進(jìn)行管理。而具體如何使用這些對象，則由應(yīng)用程序自身來決定。
如此一來，我們可以大致概括一下WebApplicationContext初始化的兩個(gè)邏輯層次：
- DispatcherServlet負(fù)責(zé)對容器（WebApplicationContext）進(jìn)行初始化。
- 容器（WebApplicationContext）將讀取SpringMVC的核心配置文件進(jìn)行組件的實(shí)例化。
整個(gè)過程，我們把應(yīng)用程序的日志級別調(diào)低，可以進(jìn)行非常詳細(xì)的觀察：
引用
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
在這段啟動(dòng)日志（筆者進(jìn)行了一定刪減）中，筆者刻意將WebApplicationContext的初始化的標(biāo)志日志使用紅色的標(biāo)進(jìn)行區(qū)分，而將核心配置文件的讀取位置和組件定義初始化的標(biāo)志日志使用藍(lán)色標(biāo)記加以區(qū)分。相信有了這段日志的幫助，讀者應(yīng)該可以對WebApplicationContext的初始化過程有了更加直觀的認(rèn)識。
注：啟動(dòng)日志是我們研究SpringMVC的主要途徑之一，之后我們還將反復(fù)使用這種方法對SpringMVC的運(yùn)行過程進(jìn)行研究。讀者應(yīng)該仔細(xì)品味每一條日志的作用，從而能夠與之后的分析講解呼應(yīng)起來。
或許讀者對WebApplicationContext對組件進(jìn)行初始化的過程還有點(diǎn)困惑，大家不妨先將這個(gè)過程省略，把握住整個(gè)DispatcherServlet的大方向。我們在之后的文章中，還將對SpringMVC的組件、這些組件的定義以及組件的初始化方式做進(jìn)一步的分析和探討。
到此為止，圖中順著FrameworkServlet的那些箭頭，我們已經(jīng)交代清楚，讀者可以回味一下整個(gè)過程。
【獨(dú)立的WebApplicationContext體系】
獨(dú)立的WebApplicationContext體系，是SpringMVC初始化主線中的一個(gè)非常重要的概念。回顧一下剛才曾經(jīng)提到過的DispatcherServlet、容器和組件三者之間的關(guān)系，我們在引用的那副官方reference的示意圖中，實(shí)際上已經(jīng)包含了這一層意思：
downpour 寫道
結(jié)論 在DispatcherServlet初始化的過程中所構(gòu)建的WebApplicationContext獨(dú)立于Spring自身的所構(gòu)建的其他WebApplicationContext體系而存在。
稍有一些Spring編程經(jīng)驗(yàn)的程序員，對于下面的配置應(yīng)該非常熟悉：
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>
在上面的代碼中，我們定義了一個(gè)Listener，它會(huì)在整個(gè)Web應(yīng)用程序啟動(dòng)的時(shí)候運(yùn)行一次，并初始化傳統(tǒng)意義上的Spring的容器。這也是一般情況下，當(dāng)并不使用SpringMVC作為我們的表示層解決方案，卻希望在我們的Web應(yīng)用程序中使用Spring相關(guān)功能時(shí)所采取的一種配置方式。
如果我們要在這里引入SpringMVC，整個(gè)配置看上去就像這樣：
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會(huì)分別構(gòu)建不同作用范圍的容器（WebApplicationContext）。我們可以引入兩個(gè)不同的概念來對其進(jìn)行表述：ContextLoaderListener所初始化的容器，我們稱之為Root WebApplicationContext；而DispatcherServlet所初始化的容器，是SpringMVC WebApplicationContext。
同樣采取日志分析的方法，加入了ContextLoaderListener之后，整個(gè)啟動(dòng)日志變成了這樣：
引用
[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
整個(gè)啟動(dòng)日志被我們分為了2段。第一段的過程初始化的是Root WebApplicationContext；而第二段的過程初始化的是SpringMVC的WebApplicationContext。我們還是使用了紅色的標(biāo)記和藍(lán)色標(biāo)記指出了在整個(gè)初始化過程中的一些重要事件。其中，有這樣一段內(nèi)容值得我們注意：
引用
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之間的關(guān)系：從屬關(guān)系。因?yàn)楦鶕?jù)這段日志的表述，SpringMVC WebApplicationContext能夠感知到Root WebApplicationContext的存在，并且將其作為parent容器。
Spring正是使用這種Parent-Child的容器關(guān)系來對不同的編程層次進(jìn)行劃分。這種我們俗稱的父子關(guān)系實(shí)際上不僅僅是一種從屬關(guān)系，更是一種引用關(guān)系。從剛才的日志分析中，我們可以看出：SpringMVC中所定義的一切組件能夠無縫地與Root WebApplicationContext中的組件整合。
到此為止，我們針對圖中以web.xml為核心的箭頭分支進(jìn)行了講解，讀者可以將圖中的內(nèi)容與上面的文字說明對照再次加以理解。
【組件默認(rèn)行為的指定】
DispatcherServlet的初始化主線的執(zhí)行體系是順著其繼承結(jié)構(gòu)依次進(jìn)行的，我們在之前曾經(jīng)討論過它的執(zhí)行次序。所以，只有在FrameworkServlet完成了對于WebApplicationContext和組件的初始化之后，執(zhí)行權(quán)才被正式轉(zhuǎn)移到DispatcherServlet中。我們可以來看看DispatcherServlet此時(shí)究竟干了哪些事：
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中預(yù)留的擴(kuò)展方法，在DispatcherServlet中做了一個(gè)基本實(shí)現(xiàn)：initStrategies。我們粗略一看，很容易就能明白DispatcherServlet到底在這里干些什么了：初始化組件。
讀者或許會(huì)問，組件不是已經(jīng)在WebApplicationContext初始化的時(shí)候已經(jīng)被初始化過了嘛？這里所謂的組件初始化，指的又是什么呢？讓我們來看看其中的一個(gè)方法的源碼：
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）中讀取組件的實(shí)現(xiàn)類，并緩存于DispatcherServlet內(nèi)部的過程。還記得我們之前給出的DispatcherServlet的數(shù)據(jù)結(jié)構(gòu)嗎？這些位于DispatcherServlet內(nèi)部的組件實(shí)際上只是一些來源于容器緩存實(shí)例，不過它們同樣也是DispatcherServlet進(jìn)行后續(xù)操作的基礎(chǔ)。
注：我們在第一篇文章中就曾經(jīng)提到過Servlet實(shí)例內(nèi)部的屬性的訪問有線程安全問題。而在這里，我們可以看到所有的組件都以Servlet內(nèi)部屬性的形式被調(diào)用，充分證實(shí)了這些組件本身也都是無狀態(tài)的單例對象，所以我們在這里不必考慮線程安全的問題。
如果對上面的代碼加以詳細(xì)分析，我們會(huì)發(fā)現(xiàn)initMultipartResolver的過程是查找特定MultipartResolver實(shí)現(xiàn)類的過程。因?yàn)樵谌萜髦胁檎医M件的時(shí)候，采取的是根據(jù)特定名稱（MULTIPART_RESOLVER_BEAN_NAME）進(jìn)行查找的策略。由此，我們可以看到DispatcherServlet進(jìn)行組件初始化的特點(diǎn)：
downpour 寫道
結(jié)論 DispatcherServlet中對于組件的初始化過程實(shí)際上是應(yīng)用程序在WebApplicationContext中選擇和查找組件實(shí)現(xiàn)類的過程，也是指定組件在SpringMVC中的默認(rèn)行為方式的過程。
除了根據(jù)特定名稱進(jìn)行查找的策略以外，我們還對DispatcherServlet中指定SpringMVC默認(rèn)行為方式的其他的策略進(jìn)行的總結(jié)：
- 名稱查找 —— 根據(jù)bean的名字在容器中查找相應(yīng)的實(shí)現(xiàn)類
- 自動(dòng)搜索 —— 自動(dòng)搜索容器中所有某個(gè)特定組件（接口）的所有實(shí)現(xiàn)類
- 默認(rèn)配置 —— 根據(jù)一個(gè)默認(rèn)的配置文件指定進(jìn)行實(shí)現(xiàn)類加載
這三條策略恰巧在initHandlerMappings的過程中都有體現(xiàn)，讀者可以從其源碼中找到相應(yīng)的線索：
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");
????????}
????}
}
這里有必要對"默認(rèn)策略"做一個(gè)簡要的說明。SpringMVC為一些核心組件設(shè)置了默認(rèn)行為方式的說明，這個(gè)說明以一個(gè)properties文件的形式位于SpringMVC分發(fā)包（例如spring-webmvc-3.1.0.RELEASE.jar）的內(nèi)部：
我們可以觀察一下DispatcherServlet.properties的內(nèi)容：
引用
# 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
結(jié)合剛才initHandlerMappings的源碼，我們可以發(fā)現(xiàn)如果沒有開啟detectAllHandlerAdapters選項(xiàng)或者根據(jù)HANDLER_ADAPTER_BEAN_NAME的名稱沒有找到相應(yīng)的組件實(shí)現(xiàn)類，就會(huì)使用DispatcherServlet.properties文件中對于HandlerMapping接口的實(shí)現(xiàn)來進(jìn)行組件默認(rèn)行為的初始化。
由此可見，DispatcherServlet.properties中所指定的所有接口的實(shí)現(xiàn)方式在Spring的容器WebApplicationContext中總有相應(yīng)的定義。這一點(diǎn)，我們在組件的討論中還會(huì)詳談。
這個(gè)部分我們的側(cè)重點(diǎn)是圖中DispatcherServlet與容器之間的關(guān)系。讀者需要理解的是圖中為什么會(huì)有兩份組件定義，它們之間的區(qū)別在哪里，以及DispatcherServlet在容器中查找組件的三種策略。
小結(jié)
在本文中，我們對SpringMVC的核心類：DispatcherServlet進(jìn)行了一番梳理。也對整個(gè)SpringMVC的兩條主線之一的初始化主線做了詳細(xì)的分析。
對于DispatcherServlet而言，重要的其實(shí)并不是這個(gè)類中的代碼和邏輯，而是應(yīng)該掌握這個(gè)類在整個(gè)框架中的作用以及與SpringMVC中其他要素的關(guān)系。
對于初始化主線而言，核心其實(shí)僅僅在于那張筆者為大家精心打造的圖。讀者只要掌握了這張圖，相信對整個(gè)SpringMVC的初始化過程會(huì)有一個(gè)全新的認(rèn)識。
轉(zhuǎn)載于:https://www.cnblogs.com/xiangxs/p/5052025.html
總結(jié)
以上是生活随笔為你收集整理的SpringMVC深度探险（三） —— DispatcherServlet与初始化主线的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 你好，在不？波形护栏螺栓终拧扭矩的单位是
- 下一篇： 漫游Kafka设计篇之性能优化（7）