Spring原始碼深度解析之Spring MVC
Spring原始碼深度解析之Spring MVC
Spring框架提供了構建Web應用程式的全功能MVC模組。通過策略介面，Spring框架是高度可配置的，而且支援多種檢視技術，例如JavaServer pages（JSP）技術、Velocity、Tiles、iText和POI。Spring MVC框架並不知道使用的檢視，所以不會強迫您只使用JSP技術。Spring MVC分離了控制器、模型物件、分派器以及處理程式物件的角色，這種分離讓它們更容易進行定製。
Spring的MVC是基於Servlet功能實現的。通過實現Servlet介面的DispatcherServlet來封裝其核心功能實現，通過將請求分派給處理程式，同時帶有可配置的處理程式對映、檢視解析、本地語言、主題解析以及上載檔案的支援。預設的處理程式是非常簡單的Controller介面，只有一個方法ModelAndView handleRequest(request, response)。Spring提供了一個控制器層次結構，可以派生子類。如果應用程式需要處理使用者輸入表單，那麼可以繼承AbstractFormController。如果需要把多頁輸入處理到一個表單，那麼可以繼承AbstractWizardFormController。
Spring MVC或者其他比較成熟的MVC框架而言，解決的問題無外乎以下幾點：
（1）將Web頁面的請求傳給伺服器。
（2）根據不同的請求處理不同的邏輯單元。
（3）返回處理結果資料並跳轉到響應的頁面。
我們先通過一個簡單示例來快速回顧Spring MVC的使用。
一、 Spring MVC快速體驗
（一）配置web.xml
一個Web中可以沒有web.xml檔案，也就是說，web.xml檔案並不是Web工廠必須的。web.xml檔案用來初始化配置資訊：比如Welcome頁面、servlet、servlet-mapping、filter、listener、啟動載入級別等。但是，Spring MVC的實現原理就是通過Servlet攔截所有URL來達到控制的目的，所以web.xml的配置是必須的。
1 <?xml version="1.0" encoding="UTF-8"?> 2 <web-app id="WebApp_ID" version="2.5" xmlns="http://java.sun.com/xml/ns/j2ee" 3 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 4 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> 5 <display-name>Springmvc</display-name> 6 7 <!--使用ContextLoaderListener配置時，需要告訴他Spring配置檔案的位置--> 8 <context-param> 9 <param-name>contextConfigLocation</param-name> 10 <param-value>classpath:applicationContext.xml</param-value> 11 </context-param> 12 13 <!--Spring MVC的前端控制器--> 14 <!--當DispatcherServlet載入後，它將從一個XML檔案中載入Spring的應用上下文，該XMl檔案的名字取決於<servlet-name>--> 15 <!--這裡DispatcherServlet將試圖從一個叫做Springmvc-servlet.xml的檔案中載入應用上下文，其預設位於WEB-INF目錄下--> 16 <servlet> 17 <servlet-name>Springmvc</servlet-name> 18 <servlet-class>org.Springframework.web.servlet.DispatcherServlet</servlet-class> 19 <load-on-startup>1</load-on-startup> 20 </servlet> 21 <servlet-mapping> 22 <servlet-name>Springmvc</servlet-name> 23 <url-pattern>*.htm</url-pattern> 24 </servlet-mapping> 25 26 <!--配置上下文載入器--> 27 <!--上下文載入器載入除DispatcherServlet載入的配置檔案之外的其它上下文配置檔案--> 28 <!--最常用的上下文載入器是一個Servlet監聽器，其名稱為ContextLoaderListener--> 29 <listener> 30 <listener-class>org.Springframework.web.context.ContextLoaderListener</listener-class> 31 </listener> 32 33 </web-app>
Spring的MVC之所以必須要配置web.xml，其實最關鍵的是要配置兩個地方。
（1）contextConfigLocation：Spring的核心就是配置檔案，可以說配置檔案是Spring中必不可少的東西，而這個引數就是使Web與Spring的配置檔案相結合的一個關鍵配置。
（2）DispatcherServlet：包含了SpringMVC的請求邏輯，Spring使用此類攔截Web請求並進行相應的邏輯處理。
（二）建立Spring配置檔案applicationContext.xml
1 <?xml version="1.0" encoding="UTF-8" ?> 2 <beans xmlns="http://www.springframework.org/schema/beans" 3 xmls:xsi="http://www.w3.org/2001/XMLSchema-instance" 4 xmlns:tx="http://www.springframework.org/schema/tx" 5 xsi:schemaLocation="http://www.springframework.org/schema/beans 6 http://www.springframework.org/schema/beans/spring-beans-2.5.xsd 7 http://www.springframework.org/schema/tx 8 http://www.springframework.org/schema/tx/spring-tx-2.5.xsd"> 9 10 <bean id="viewResolver" class="org.springframework.web.servlet.view.Internal Resource ViewResolver"> 11 <property name="prefix" value="/WEB-INF/jsp/"/> 12 <property name="suffix" value=".jsp"/> 13 </bean> 14 15 </beans>
InternalResourceViewResolver是一個輔助Bean，會在ModelAndView返回的檢視名前加上prefix指定的字首，再在最後加上suffix指定的字尾，例如：由於XXController返回的ModelAndView中的檢視名師testview。故該檢視解析器將在/WEB-INF/jsp/testview.jsp處查詢檢視。
（三）建立model
模型對於Spring MVC來說是必不可少，如果處理程式非常簡單，完全可以忽略。模型建立的主要目的就是承載資料，使資料傳輸更加方便。
1 public class User{ 2 private String username; 3 private Integer age; 4 5 public String getUsername(){ 6 return username; 7 } 8 public void setUsername(String username){ 9 this.username = username; 10 } 11 12 public Integer getAge() { 13 return age; 14 } 15 public void setAge(Integer age){ 16 this.age = age; 17 } 18 }
（四）建立Controller
控制器用於處理Web請求，每個控制器都對應著一個邏輯處理。
1 public class UserController extends AbstractController{ 2 @Override 3 protected ModelAndView handleRequestInternal(HttpServletRequest arg0, HttpServletResponse arg1) throws Exception{ 4 List<User> userList = new ArrayList<User>(); 5 User userA = new User(); 6 User userB = new User(); 7 userA.setUsername("張三"); 8 userA.setAge(27); 9 userB.setUsername("李四"); 10 userB.setAge(37); 11 userList.add(userA); 12 userList.add(userB); 13 14 return new ModelAndView("userlist", "users", userList); 15 } 16 }
在請求的最後返回了ModelAndView型別的例項。ModelAndView類在Spring MVC中佔有很重要的地位。控制器執行方法都必須返回一個ModelAndView，ModelAndView物件儲存了檢視以及檢視顯示的模型資料，例如其中的引數如下：
第一個引數userlist：檢視元件的邏輯名稱。這裡檢視的邏輯名稱就是userlist，檢視解析器會使用該名稱查詢實際的View物件。
第二個引數users：傳遞給檢視的，模型物件的名稱。
第三個引數userList：傳遞給檢視的，模型物件的值。
（五）建立檢視檔案userlist.jsp
1 <%@ page language="java" pageEncoding="UTF-8" %> 2 <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> 3 <h2>This is SpringMVC demo page</h2> 4 <c:forEach item="${users}" var="user"> 5 <c:out value="${user.username}"/><br/> 6 <c:out value="${usr.age}"/><br/> 7 </c:forEach>
檢視檔案用於展現請求處理結果，通過對JSTL的支援，可以很方便地展現在控制器中放入ModelAndView中處理結果資料。
（六）建立Servlet配置檔案Spring-servlet.xml
1 <?xml version="1.0" encoding="UTF-8" ?> 2 <beans xmlns="http://www.springframework.org/schema/beans" 3 xmlns:xsi="http//www.w3.org/2001/XMLSchema-instance" 4 xmlns:tx="http://www.springframework.org/schema/tx" 5 xsi:schemaLocation="http://www.springframework.org/schema/beans 6 http://www.springframework.org/schema/beans/spring-beans-2.5.xsd 7 http://www.springframework.org/schema/tx 8 http://www.springframework.org/schema/tx/spring-tx-2.5.xsd"> 9 10 <bean id="simpleUrlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> 11 <property name="mapping"> 12 <props> 13 <prop key="/usrerlist.htm">userController</prop> 14 </props> 15 </property> 16 </bean> 17 18 <!--這裡的 id="userController對應的是<bean id="simpleUrlMapping">中的<prop>裡面的value"--> 19 <bean id="userController" class="test.controller.UserController"/> 20 21 </beans>
因為Spring MVC是基於Servlet的實現，所以在Web啟動的時候，伺服器會首先嚐試載入對應於Servlet的配置檔案，而為了讓專案更加模組化，通常我們講Web部分的配置都存放於此配置檔案中。
至此，已經完成了Spring MVC的搭建，啟動伺服器，輸入網址http://localhost:8080/Springmvc/userlist.htm。會看到伺服器器的返回介面。
二 、ContextLoaderListener
對於Spring MVC功能實現的分析，我們首先從web.xml開始，在web.xml檔案中我們首先配置的就是contextLoaderListener，那麼它所提供的功能有哪些又是如何實現的呢？
當使用程式設計方式的時候我們可以直接將Spring配置資訊作為引數傳入Spring容器中，如：
ApplicationContext ac = new ClassPathXmlApplicationContext(“applicationContext.xml”);
但是在Web下，我們需要更多的是與Web環境相互結合，通常的辦法是將路徑以context-param的方式註冊並使用ContextLoaderListener進行監聽讀取。
ContextLoaderListener的作用就是啟動Web容器時，自動裝配ApplicationContext的配置資訊。因為它實現了ServletContextListener這個介面，在web.xml配置這個監聽器，啟動容器時，就會預設執行它實現的方法，使用ServletContextListener介面，開發者能夠在為客戶端請求提供服務之前向ServletContext中新增任意的物件。這個物件在ServletContext啟動的時候被初始化，然後在ServletContext整個執行期間都是可見的。
每一個Web應用都有一個ServletContext與之相關聯。ServletContext物件在應用啟動時被建立，在應用關閉的時候被銷燬。ServletContext在全域性範圍內有效，類似於應用中一個全域性變數。
在ServletContextListener中的核心邏輯便是初始化WebApplicationContext例項並存放至ServletContext中。
（一）ServletContextListener的使用
正式分析程式碼前我們同樣還是先了解ServletContextListener的使用。
（1）建立自定義ServletContextListener。
首先我們建立ServletContextListener，目標是在系統啟動時新增自定義的屬性，以便於在全域性範圍內可以隨時呼叫。系統啟動的時候會呼叫ServletContextListener實現類的contextInitialized方法，所以需要在這個方法中實現我們的初始化邏輯。
1 public class MyDataContextListener implements ServletContextListener{ 2 3 private ServletContext context = null; 4 5 public MyDataContextListener(){ 6 7 } 8 9 //該方法在ServletContext啟動之後被呼叫，並準備好處理客戶端的請求 10 public void contextInitialized(ServletContextEvent event){ 11 this.context = event.getServletContext(); 12 //通過你可以實現自己的邏輯並將結果記錄在屬性中 13 context = setAttribut("myData", "this is myData"); 14 } 15 16 //這個方法在ServletContext將要關閉的時候呼叫 17 public void contextDestroyed(ServletContextEvent event){ 18 this.context = null; 19 } 20 }
（2）註冊監聽器。
在web.xml檔案中需要註冊自定義的監聽器。
1 <listener> 2 com.test.MyDataContextListener 3 </listener>
（3）測試。
一旦Web應用啟動的時候，我們就能在任意的Servlet或者JSP中通過下面的方式獲取我們初始化引數，如下：String myData = (String) getServletContext().getAttribut(“myData”);
（二）Spring中的ContextLoaderListener
分析了ServletContextListener的使用方式後再來分析Spring中的ContextLoaderListener的實現方式就容易理解得多，雖然ContextLoaderListener實現的邏輯要複雜得多，但是大致的套路還是萬變不離其宗。
ServletContext啟動後會呼叫ServletContextListener的contextInitialized方法，那麼，我們就從這個函式開始進行分析。
1 @Override 2 public void contextInitialized(ServletContextEvent event) { 3 //該方法在其父類ContextLoader中定義 4 initWebApplicationContext(event.getServletContext()); 5 }
這裡涉及了一個常用類WebApplicationContext：在Web應用中，我們會用到WebApplicationContext，WebApplicationContext繼承自ApplicationContext，在ApplicationContext的基礎上又追加了一些特定於Web的操作及屬性。非常類似於我們通過程式設計方式使用Spring時使用的ClassPathXmlApplicationContext類提供的功能。繼續跟蹤程式碼：
1 public WebApplicationContext initWebApplicationContext(ServletContext servletContext) { 2 if (servletContext.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE) != null) { 3 //web.xml中存在多次ContextLoader的定義 4 throw new IllegalStateException( 5 "Cannot initialize context because there is already a root application context present - " + 6 "check whether you have multiple ContextLoader* definitions in your web.xml!"); 7 } 8 9 servletContext.log("Initializing Spring root WebApplicationContext"); 10 Log logger = LogFactory.getLog(ContextLoader.class); 11 if (logger.isInfoEnabled()) { 12 logger.info("Root WebApplicationContext: initialization started"); 13 } 14 long startTime = System.currentTimeMillis(); 15 16 try { 17 // Store context in local instance variable, to guarantee that 18 // it is available on ServletContext shutdown. 19 if (this.context == null) { 20 //初始化context 21 this.context = createWebApplicationContext(servletContext); 22 } 23 if (this.context instanceof ConfigurableWebApplicationContext) { 24 ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) this.context; 25 if (!cwac.isActive()) { 26 // The context has not yet been refreshed -> provide services such as 27 // setting the parent context, setting the application context id, etc 28 if (cwac.getParent() == null) { 29 // The context instance was injected without an explicit parent -> 30 // determine parent for root web application context, if any. 31 ApplicationContext parent = loadParentContext(servletContext); 32 cwac.setParent(parent); 33 } 34 configureAndRefreshWebApplicationContext(cwac, servletContext); 35 } 36 } 37 //記錄在servletContext中 38 servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, this.context); 39 40 ClassLoader ccl = Thread.currentThread().getContextClassLoader(); 41 if (ccl == ContextLoader.class.getClassLoader()) { 42 currentContext = this.context; 43 } 44 else if (ccl != null) { 45 currentContextPerThread.put(ccl, this.context); 46 } 47 48 if (logger.isInfoEnabled()) { 49 long elapsedTime = System.currentTimeMillis() - startTime; 50 logger.info("Root WebApplicationContext initialized in " + elapsedTime + " ms"); 51 } 52 53 return this.context; 54 } 55 catch (RuntimeException | Error ex) { 56 logger.error("Context initialization failed", ex); 57 servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, ex); 58 throw ex; 59 } 60 }
initWebApplicationContext函式主要是體現了建立WebApplicationContext例項的一個功能架構，從函式中我們看到了初始化的大致步驟。
（1）WebApplicationContext存在性的驗證。
在配置中只允許申明一次ServletContextListener，多次申明會擾亂Spring的執行邏輯，所以這裡首先要做的就是對比驗證，在Spring中如果建立WebApplicationContext；例項會記錄在ServletContext中以方便全域性呼叫，而使用的key就是WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE，所以驗證的方式就是檢視ServletContext例項中是否有對應key的屬性。
（2）建立WebApplicationContext例項。
如果通過驗證，則Spring將建立WebApplicationContext例項的工作委託給了createWebApplicationContext函式。
1 protected WebApplicationContext createWebApplicationContext(ServletContext sc) { 2 Class<?> contextClass = determineContextClass(sc); 3 if (!ConfigurableWebApplicationContext.class.isAssignableFrom(contextClass)) { 4 throw new ApplicationContextException("Custom context class [" + contextClass.getName() + 5 "] is not of type [" + ConfigurableWebApplicationContext.class.getName() + "]"); 6 } 7 return (ConfigurableWebApplicationContext) BeanUtils.instantiateClass(contextClass); 8 }
createWebApplicationContext函式又呼叫了determineContextClass方法，繼續：
1 protected Class<?> determineContextClass(ServletContext servletContext) { 2 String contextClassName = servletContext.getInitParameter(CONTEXT_CLASS_PARAM); 3 if (contextClassName != null) { 4 try { 5 return ClassUtils.forName(contextClassName, ClassUtils.getDefaultClassLoader()); 6 } 7 catch (ClassNotFoundException ex) { 8 throw new ApplicationContextException( 9 "Failed to load custom context class [" + contextClassName + "]", ex); 10 } 11 } 12 else { 13 contextClassName = defaultStrategies.getProperty(WebApplicationContext.class.getName()); 14 try { 15 return ClassUtils.forName(contextClassName, ContextLoader.class.getClassLoader()); 16 } 17 catch (ClassNotFoundException ex) { 18 throw new ApplicationContextException( 19 "Failed to load default context class [" + contextClassName + "]", ex); 20 } 21 } 22 }
其中，在ContextLoader類中有這樣的靜態程式碼塊：
1 static { 2 // Load default strategy implementations from properties file. 3 // This is currently strictly internal and not meant to be customized 4 // by application developers. 5 try { 6 ClassPathResource resource = new ClassPathResource(DEFAULT_STRATEGIES_PATH, ContextLoader.class); 7 defaultStrategies = PropertiesLoaderUtils.loadProperties(resource); 8 } 9 catch (IOException ex) { 10 throw new IllegalStateException("Could not load 'ContextLoader.properties': " + ex.getMessage()); 11 } 12 }
根據以上靜態的程式碼塊內容，我們推斷在當前類ContextLoader同樣目錄下必定會存在屬性檔案ContextLoader.properties（在..\spring-web\src\main\resources\org\springframework\web\context目錄下），檢視後果然存在，內容如下：
org.springframework.web.context.WebApplicationContext=org.springframework.web.context.support.XmlWebApplicationContext
綜合以上程式碼分析，在初始化過程中，程式首先會讀取ContextLoader類的同目錄下的屬性檔案ContextLoader.properties。並根據其中的配置提取將要實現WebApplicationContext介面的實現類，並根據這個實現類通過反射的方式進行例項的建立。
（3）將例項記錄在servletContext中。
（4）對映當前的類載入器與建立的例項到全域性變數currentContextPerThread中。
三、 DispatcherServlet
在Spring中，ContextLoaderListener只是輔助功能，用於建立WebApplicationContext型別例項，而真正的邏輯其實是在DispatcherServlet（package org.springframework.web.servlet）中進行的，DispatcherServlet是實現servlet的介面的實現類。
servlet是一個Java編寫的程式，此程式是基於HTTP協議的，在伺服器端執行的（如Tomcat），是按照servlet規範編寫的一個Java類。主要是處理客戶端的請求並將其結果傳送到客戶端。servlet的生命週期是由servlet的容器來控制的，它可以分為3個階段：初始化、執行和銷燬。
（1）初始化階段
servlet容器載入servlet類，把servlet類的.class檔案中的資料讀到記憶體中。
servlet容器建立一個ServletConfig物件，ServletConfig物件包含了servlet的初始化配置資訊。
servlet容器建立一個servlet物件。
servlet容器呼叫servlet物件的init方法機芯初始化化。
（2）執行階段
當servelt容器接收到一個請求是，servelt容器會針對這個請求建立serveltRequest和ServletResponse物件，然後呼叫service方法。並把這兩個引數傳遞給service方法。service方法通過servletRequest物件獲得請求的資訊。並處理請求。再通過servletResponse物件生成這個請求的響應結果。然後銷燬servletRequest和ServletResponse物件。我們不管這個請求是post提交的還是get提交的，最終這個請求都會由service方法來處理。
（3）銷燬階段。
當Web應用被終止時，servlet容器會先呼叫servlet物件的destroy方法，然後在銷燬servlet物件，同時也會銷燬與servlet物件相關聯的servletConfig物件。我們可以在destroy方法的實現中，釋放servlet所佔用的資源，如關閉資料庫連線，關閉檔案輸入輸出流等。
servlet的框架是由兩個Java包組成：javax.servlet和javax.servlet.http。在javax.servlet包中定義了所有的servlet類都必須實現或拓展的通用介面和類。在javax.servlet.http包中定義了採用HTTP通訊協議的HttpServlet類。
servlet類被設計成請求驅動，servlet的請求可能包含多個數據項，當Web容器接收到某個servlet請求是，servelt把請求封裝成一個HTTPServletRequest物件，然後把物件傳給servlet的物件的服務方法。
HTTP的請求方式包括delete、get、options、post、put和trace。在HttpServlet類中分別提供了相應的服務方法，它們是doDelete()、doGet()、doOptions()、doPost()、doPut()和doTrace()。
（一）servlet的使用
我們同樣還是以最簡單的servlet來快速體驗其用法。
（1）建立servlet
1 public class Myservlet extends HttpServlet{ 2 public void init(){ 3 System.out.println("this is a method"); 4 } 5 6 public void doGet(HttpServletRequest request, HttpServletResponse response){ 7 handleLogic(request, response); 8 } 9 10 public void doPost(HttpServletRequest request, HttpServletResponse response){ 11 handleLogic(request, response); 12 } 13 14 public void handleLogic(HttpServletRequest request, HttpServletResponse response){ 15 System.out.println("handle myLogic"); 16 ServletContext sc = getServletContext(); 17 18 RequestDispatcher rd = null; 19 20 rd = sc.getRequestDispatcher("/index.jsp"); 21 try { 22 rd.forward(request, response); 23 } catch (ServletException | IOException e) { 24 e.printStackTrace(); 25 } 26 } 27 }
麻雀雖小，五臟俱全。例項中包含了對init方法和get/post方法的處理，init方法包裝在servlet載入的時候能做一些邏輯操作，而HttpServlet類則會幫助我們根據方法型別的不同而將邏輯引入不同的函式。在子類中我們只需要重寫對應的函式邏輯便可，如以上程式碼重寫了doGet和doPost方法並將邏輯處理部分引導至handleLogic函式中，最後，又將頁面跳轉至index.jsp。
（2）新增配置
為了是servlet能夠正常使用，需要在web.xml檔案中新增以下配置：
1 <servlet> 2 <servlet-name>myservlet</servlet-name> 3 <servlet-name>test.servlet.MyServlet</servlet-name> 4 <load-on-startup>1</load-on-startup> 5 </servlet> 6 7 <servlet-mapping> 8 <servlet-name>myservlet</servlet-name> 9 <url-pattern>*.htm</url-pattern> 10 </servlet-mapping>
配置後便可以根據對應的配置訪問響應的路徑了。
（二）DispatcherServlet的初始化
通過上面的例項我們瞭解到，在servlet初始化階段會呼叫器init方法，所以我們首先要檢視在DispatcherServlet中是否重寫了init方法。我們再其父類HttpServletBean（package org.springframework.web.servlet）中找到了該方法。
1 @Override 2 public final void init() throws ServletException { 3 4 // Set bean properties from init parameters. 5 //解析init-param並封裝在pvs中 6 PropertyValues pvs = new ServletConfigPropertyValues(getServletConfig(), this.requiredProperties); 7 if (!pvs.isEmpty()) { 8 try { 9 //將當前的這個Servlet類轉化成一個BeanWrapper，從而能夠以Spring的方式來對init-param的值進行注 10 BeanWrapper bw = PropertyAccessorFactory.forBeanPropertyAccess(this); 11 ResourceLoader resourceLoader = new ServletContextResourceLoader(getServletContext()); 12 //註冊自定義屬性編輯器，一旦遇到Resource型別的屬性將會使用ResourceEditor進行解析 13 bw.registerCustomEditor(Resource.class, new ResourceEditor(resourceLoader, getEnvironment())); 14 //空實現，留給子類覆蓋 15 initBeanWrapper(bw); 16 //屬性注入 17 bw.setPropertyValues(pvs, true); 18 } 19 catch (BeansException ex) { 20 if (logger.isErrorEnabled()) { 21 logger.error("Failed to set bean properties on servlet '" + getServletName() + "'", ex); 22 } 23 throw ex; 24 } 25 } 26 27 // Let subclasses do whatever initialization they like. 28 //留給子類擴充套件 29 initServletBean(); 30 }
DispatchServlet的初始化過程主要是通過將當前的servlet型別例項轉換成BeanWrapper型別例項，以便使用Spring中提供的注入功能進行對應屬性的注入。這些屬性如contextAttribut、contextClass、nameSpace、contextConfigLocation等，都可以在web.xml檔案中以初始化引數的方式配置在servelt的宣告中。DispatcherServlet繼承自FrameworkServlet，FrameServlet類上包含對應的同名屬性，Spring會保證這些引數被注入到對應的值中。屬性注入主要包含以下幾個步驟：
（1）封裝及驗證初始化引數
ServletConfigPropertyValues除了封裝屬性外還有對屬性驗證的功能。
1 public ServletConfigPropertyValues(ServletConfig config, Set<String> requiredProperties) 2 throws ServletException { 3 4 Set<String> missingProps = (!CollectionUtils.isEmpty(requiredProperties) ? 5 new HashSet<>(requiredProperties) : null); 6 7 Enumeration<String> paramNames = config.getInitParameterNames(); 8 while (paramNames.hasMoreElements()) { 9 String property = paramNames.nextElement(); 10 Object value = config.getInitParameter(property); 11 addPropertyValue(new PropertyValue(property, value)); 12 if (missingProps != null) { 13 missingProps.remove(property); 14 } 15 } 16 17 // Fail if we are still missing properties. 18 if (!CollectionUtils.isEmpty(missingProps)) { 19 throw new ServletException( 20 "Initialization from ServletConfig for servlet '" + config.getServletName() + 21 "' failed; the following required properties were missing: " + 22 StringUtils.collectionToDelimitedString(missingProps, ", ")); 23 } 24 }
從程式碼中得知，封裝屬性主要是對初始化的引數進行封裝，也就是servlet中配置的<init-param>中配置的封裝。當然，使用者可以同對requiredProperties引數的初始化來強制驗證某些屬性的必要性。這樣，在屬性封裝的過程中，一旦檢測到requiredProperties中的屬性沒有指定初始值，就會丟擲異常。
（2）將當前servlet例項轉化成BeanWrapper例項
PropertyAccessorFactory.forBeanPropertyAccess是Spring中提供的工具方法，主要用於將指定例項轉化成Spring中可以處理的BeanWrapper型別的例項。
（3）註冊相對於Resource的屬性編輯器
屬性編輯器，我們再上文中已經介紹並分析過其原理。這裡使用屬性編輯器的目的是在對當前例項（DispatcherServlet）屬性注入過程中一旦遇到Resource型別的屬性就會使用ResourceEditor去解析。
（4）屬性注入
BeanWrapper為Spring中的方法，支援Spring的自動注入。其實我們最常用的屬性注入無非是contextAttribut、contextClass、nameSpace、contextConfigLocation等屬性。
（5）servletBean的初始化
在ContextLoaderListener載入的時候已經建立了WebApplicationContext例項，而在這個函式中最重要的就是對這個例項進行進一步的補充初始化。
繼續檢視initServletBean()。父類FrameworkServlet覆蓋了HttpServletBean中的initServletBean函式，如下：
1 protected final void initServletBean() throws ServletException { 2 getServletContext().log("Initializing Spring " + getClass().getSimpleName() + " '" + getServletName() + "'"); 3 if (logger.isInfoEnabled()) { 4 logger.info("Initializing Servlet '" + getServletName() + "'"); 5 } 6 long startTime = System.currentTimeMillis(); 7 8 try { 9 this.webApplicationContext = initWebApplicationContext(); 10 //設為子類覆蓋 11 initFrameworkServlet(); 12 } 13 catch (ServletException | RuntimeException ex) { 14 logger.error("Context initialization failed", ex); 15 throw ex; 16 } 17 18 if (logger.isDebugEnabled()) { 19 String value = this.enableLoggingRequestDetails ? 20 "shown which may lead to unsafe logging of potentially sensitive data" : 21 "masked to prevent unsafe logging of potentially sensitive data"; 22 logger.debug("enableLoggingRequestDetails='" + this.enableLoggingRequestDetails + 23 "': request parameters and headers will be " + value); 24 } 25 26 if (logger.isInfoEnabled()) { 27 logger.info("Completed initialization in " + (System.currentTimeMillis() - startTime) + " ms"); 28 } 29 }
上面的函式設計了計時器來統計初始化的執行時間，而且提供了一個擴充套件方法initFrameworkServlet()用於子類的覆蓋操作。而作為關鍵的初始化邏輯實現委託給了initWebApplicationContext()。
（三）WebApplicationContext的初始化
initWebApplicationContext函式的主要工作就是建立或者重新整理WebApplicationContext例項並對servlet功能所使用額變數進行初始化。
1 protected WebApplicationContext initWebApplicationContext() { 2 WebApplicationContext rootContext = 3 WebApplicationContextUtils.getWebApplicationContext(getServletContext()); 4 WebApplicationContext wac = null; 5 6 if (this.webApplicationContext != null) { 7 // A context instance was injected at construction time -> use it 8 //context例項在建構函式中被注入 9 wac = this.webApplicationContext; 10 if (wac instanceof ConfigurableWebApplicationContext) { 11 ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) wac; 12 if (!cwac.isActive()) { 13 // The context has not yet been refreshed -> provide services such as 14 // setting the parent context, setting the application context id, etc 15 if (cwac.getParent() == null) { 16 // The context instance was injected without an explicit parent -> set 17 // the root application context (if any; may be null) as the parent 18 cwac.setParent(rootContext); 19 } 20 //重新整理上下文環境 21 configureAndRefreshWebApplicationContext(cwac); 22 } 23 } 24 } 25 if (wac == null) { 26 // No context instance was injected at construction time -> see if one 27 // has been registered in the servlet context. If one exists, it is assumed 28 // that the parent context (if any) has already been set and that the 29 // user has performed any initialization such as setting the context id 30 //根據contextAttribute屬性載入WebApplicationContext 31 wac = findWebApplicationContext(); 32 } 33 if (wac == null) { 34 // No context instance is defined for this servlet -> create a local one 35 wac = createWebApplicationContext(rootContext); 36 } 37 38 if (!this.refreshEventReceived) { 39 // Either the context is not a ConfigurableApplicationContext with refresh 40 // support or the context injected at construction time had already been 41 // refreshed -> trigger initial onRefresh manually here. 42 synchronized (this.onRefreshMonitor) { 43 onRefresh(wac); 44 } 45 } 46 47 if (this.publishContext) { 48 // Publish the context as a servlet context attribute. 49 String attrName = getServletContextAttributeName(); 50 getServletContext().setAttribute(attrName, wac); 51 } 52 53 return wac; 54 }
對應本函式中的初始化主要包含幾個部分。
（1）尋找或建立對應的WebApplicationContext例項
WebApplicationContext的尋找和建立包括以下幾個步驟。
（1.1）通過建構函式的注入進行初始化。
當進入initWebApplicationContext函式後通過判斷this.webApplicationContext != null後，便可以確定this.webApplicationContext是否是通過建構函式來初始化的。可是有讀者可能會有疑問，在initServletBean函式中明明是把建立好的例項記錄在了this.webApplicationContext中：
this.webApplicationContext = initWebApplicationContext();
何以判斷這個引數就是通過建構函式初始化，而不是通過上一次的函式返回值初始化的呢？如果存在這個問題，那麼就是讀者忽略了一個問題：在Web中包含SpringWeb的核心邏輯DispatcherServlet只可以被宣告一次，在Spring中已經存在驗證，所以這就確保瞭如果this.webApplicationContext != null，則可以直接判定this.webApplicationContext已經通過建構函式初始化了。
（1.2）通過contextAttribute進行初始化。
通過在web.xml檔案中配置的servlet引數contextAttribut來 查詢ServletContext中對應的屬性，預設為WebApplicationContext.class.getName()+”.ROOT”，也就是在ContextLoaderListener載入時會建立WebApplicationContext例項，並將例項以WebApplicationContext.class.getName()+”.ROOT”為key放入ServletContext中，當然讀者可以重寫初始化邏輯使用自己建立的WebApplicationContext，並在servlet的配置中通過初始化引數contextAttribut指定可以key。
1 protected WebApplicationContext findWebApplicationContext() { 2 String attrName = getContextAttribute(); 3 if (attrName == null) { 4 return null; 5 } 6 WebApplicationContext wac = 7 WebApplicationContextUtils.getWebApplicationContext(getServletContext(), attrName); 8 if (wac == null) { 9 throw new IllegalStateException("No WebApplicationContext found: initializer not registered?"); 10 } 11 return wac; 12 }
（1.3）重新建立WebApplicationContext例項。
如果通過以上兩種方式並沒有找到任何突破，那就沒有辦法了，只能在這裡重新建立新的例項了。
1 protected WebApplicationContext createWebApplicationContext(@Nullable WebApplicationContext parent) { 2 return createWebApplicationContext((ApplicationContext) parent); 3 }
1 protected WebApplicationContext createWebApplicationContext(@Nullable ApplicationContext parent) { 2 //獲取servlet的初始化引數contextClass，如果沒有配置預設為XMLWebApplication.class 3 Class<?> contextClass = getContextClass(); 4 if (!ConfigurableWebApplicationContext.class.isAssignableFrom(contextClass)) { 5 throw new ApplicationContextException( 6 "Fatal initialization error in servlet with name '" + getServletName() + 7 "': custom WebApplicationContext class [" + contextClass.getName() + 8 "] is not of type ConfigurableWebApplicationContext"); 9 } 10 //通過反射方式例項化contextClass 11 ConfigurableWebApplicationContext wac = 12 (ConfigurableWebApplicationContext) BeanUtils.instantiateClass(contextClass); 13 14 wac.setEnvironment(getEnvironment()); 15 //parent為在ContextloaderListener中建立的例項，在ContextLoaderListener載入的時候初始化的WebApplicationContext型別例項 16 wac.setParent(parent); 17 String configLocation = getContextConfigLocation(); 18 if (configLocation != null) { 19 //獲取contextConfigLocation屬性，配置在servlet初始化引數中 20 wac.setConfigLocation(configLocation); 21 } 22 //初始化Spring環境包括載入配置檔案等 23 configureAndRefreshWebApplicationContext(wac); 24 25 return wac; 26 }
（2）configureAndRefreshWebApplicationContext
無論是通過建構函式注入還是單獨建立，都免不了會呼叫configureAndRefreshWebApplicationContext方法來對已經建立的WebApplicationContext例項進行配置及重新整理，那麼這個步驟又做了哪些工作呢？
1 protected void configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac) { 2 if (ObjectUtils.identityToString(wac).equals(wac.getId())) { 3 // The application context id is still set to its original default value 4 // -> assign a more useful id based on available information 5 if (this.contextId != null) { 6 wac.setId(this.contextId); 7 } 8 else { 9 // Generate default id... 10 wac.setId(ConfigurableWebApplicationContext.APPLICATION_CONTEXT_ID_PREFIX + 11 ObjectUtils.getDisplayString(getServletContext().getContextPath()) + '/' + getServletName()); 12 } 13 } 14 15 wac.setServletContext(getServletContext()); 16 wac.setServletConfig(getServletConfig()); 17 wac.setNamespace(getNamespace()); 18 wac.addApplicationListener(new SourceFilteringListener(wac, new ContextRefreshListener())); 19 20 // The wac environment's #initPropertySources will be called in any case when the context 21 // is refreshed; do it eagerly here to ensure servlet property sources are in place for 22 // use in any post-processing or initialization that occurs below prior to #refresh 23 ConfigurableEnvironment env = wac.getEnvironment(); 24 if (env instanceof ConfigurableWebEnvironment) { 25 ((ConfigurableWebEnvironment) env).initPropertySources(getServletContext(), getServletConfig()); 26 } 27 28 postProcessWebApplicationContext(wac); 29 applyInitializers(wac); 30 //載入配置檔案及整合parent到wac 31 wac.refresh(); 32 }
（3）重新整理
onRefresh是FrameworkServlet類中提供的模板方法，在其子類DispatcherServlet中進行了重寫，主要用於重新整理Spring在Web功能實現中所必須使用的全域性變數。下面我們會介紹它們的初始化過程以及使用場景，而至於具體的使用細節會在稍後的章節中再做詳細的介紹。
1 /** 2 * This implementation calls {@link #initStrategies}. 3 */ 4 @Override 5 protected void onRefresh(ApplicationContext context) { 6 initStrategies(context); 7 } 8 9 /** 10 * Initialize the strategy objects that this servlet uses. 11 * <p>May be overridden in subclasses in order to initialize further strategy objects. 12 */ 13 protected void initStrategies(ApplicationContext context) { 14 //(1)初始化MultipartResolver 15 initMultipartResolver(context); 16 //(2)初始化LocaleResolver 17 initLocaleResolver(context); 18 //(3)初始化ThemeResolver 19 initThemeResolver(context); 20 //(4)初始化HandlerMappings 21 initHandlerMappings(context); 22 //(5)初始化HandlerAdapters 23 initHandlerAdapters(context); 24 //(6)初始化HandlerExceptionResolvers 25 initHandlerExceptionResolvers(context); 26 //(7)初始化RequestToViewNameTranslator 27 initRequestToViewNameTranslator(context); 28 //(8)初始化ViewResolvers 29 initViewResolvers(context); 30 //(9)初始化FlashMapManager 31 initFlashMapManager(context); 32 }
（3.1）初始化MultipartResolver
在Spring中，MultipartResolver主要用來處理檔案上傳。預設情況下，Spring是沒有Multipart處理的，因為一些開發者想要自己處理它們。如果想使用Spring的multipart，則需要在Web應用的上下文中新增multipart解析器。這樣，每個請求就會被檢查是否包含multipart。然而，如果請求中包含multipart，那麼上下文中定義的MultipartResolver就會解析它，這樣請求的multipart屬性就會像其他屬性一樣被處理。常用配置如下：
1 <bean id="multipartResolver" class="org.Springframework.web.multipart.commons.CommonsMultipartResolver"> 2 <!--該屬性用來配置可上傳檔案的最大byte數--> 3 <proterty name="maximumFileSize"><value>100000</value></proterty> 4 </bean>
當然，CommonsMultipartResolver還提供了其他功能用於幫助使用者完成上傳功能，有興趣的讀者可以進一步檢視。
那麼MultipartResolver就是在initMultipartResolver中被加入到DispatcherServlet中的。
1 private void initMultipartResolver(ApplicationContext context) { 2 try { 3 this.multipartResolver = context.getBean(MULTIPART_RESOLVER_BEAN_NAME, MultipartResolver.class); 4 if (logger.isTraceEnabled()) { 5 logger.trace("Detected " + this.multipartResolver); 6 } 7 else if (logger.isDebugEnabled()) { 8 logger.debug("Detected " + this.multipartResolver.getClass().getSimpleName()); 9 } 10 } 11 catch (NoSuchBeanDefinitionException ex) { 12 // Default is no multipart resolver. 13 this.multipartResolver = null; 14 if (logger.isTraceEnabled()) { 15 logger.trace("No MultipartResolver '" + MULTIPART_RESOLVER_BEAN_NAME + "' declared"); 16 } 17 } 18 }
因為之前的步驟已經完成了Spring中配置檔案的解析，所以在這裡只要在配置檔案註冊過都可以通過ApplicationContext提供的getBean方法來直接獲取對應的bean，進而初始化MultipartResolver中的MultipartResolver變數。
（3.2）初始化LocalResolver
在Spring國際化配置中一共有3種使用方式。
1. 基於URL引數的配置
通過URL引數來控制國際化，比如你在頁面上加一句<a href=”?locale=zh_CN”>簡體中文</a>來控制專案中使用的國際化引數。而提供這個功能的就是AcceptHeaderLocalResolver，預設的引數名為local，注意大小寫。裡面放的就是你的提交引數，比如en_US、zh_CN之類的，具體配置如下：
<bean id=”localResolver” class=”org.Springframework.web.servlet.i18n.AcceptHeaderLocalResolver”/>
2. 基於session的配置
它通過檢驗使用者會話中國預置的屬性來解析區域。最常用的是根據使用者本次會話過程中的語言設定決定語言種類（例如，使用者登入時選擇語言種類，則此次登入週期內統一使用此語言設定），如果會話屬性不存在，它會根據accept-language HTTP頭部確定預設區域。
<bean id=”localResolver” class=”org.Springframework.web.servlet.i18n.SessionLocaleResolver”>
3. 基於Cookie的國際化配置。
CookieLocalResolver用於通過瀏覽器的cookie設定取得Locale物件。這種策略再應用程式不支援會話或者狀態必須儲存在客戶端時有用，配置如下：
<bean id=”localResolver” class=”org.Springframework.web.servlet.i18n.CookieLocalResolver”>
這3種方式都可以解決國際化的問題，但是，對於LocalResolver的使用基礎是在DispatcherServlet中初始化的。
1 private void initLocaleResolver(ApplicationContext context) { 2 try { 3 this.localeResolver = context.getBean(LOCALE_RESOLVER_BEAN_NAME, LocaleResolver.class); 4 if (logger.isTraceEnabled()) { 5 logger.trace("Detected " + this.localeResolver); 6 } 7 else if (logger.isDebugEnabled()) { 8 logger.debug("Detected " + this.localeResolver.getClass().getSimpleName()); 9 } 10 } 11 catch (NoSuchBeanDefinitionException ex) { 12 // We need to use the default. 13 this.localeResolver = getDefaultStrategy(context, LocaleResolver.class); 14 if (logger.isTraceEnabled()) { 15 logger.trace("No LocaleResolver '" + LOCALE_RESOLVER_BEAN_NAME + 16 "': using default [" + this.localeResolver.getClass().getSimpleName() + "]"); 17 } 18 } 19 }
提取配置檔案中設定的LocalResolver來初始化DispatcherServlet中的localeResolver屬性。
（3.3）初始化ThemeResolver。
在Web開發中經常會遇到通過主題Theme來控制網頁風格。這將進一步改善使用者體驗。簡單的說，一個主題就是一組靜態資源（比如樣式表和圖片）。它們可以影響程式的視覺效果。Spring中的主題功能和國際化功能非常類似。構成Spring主題功能主要包括如下內容。
1. 主題資源
org.Springframework.ui.context.ThemeSource是Spring中主題資源的介面。Spring的主題需要通過ThemeSource介面來實現存放主題資訊的資源。
org.Springframework.ui.context.support.ResourceBundleThemeSource是ThemeSource介面預設實現類（也就是通過ResourceBundle資源的方式定義主題。）在Spring中的配置如下：
1 <bean id="themeSource" class="org.Springframework.ui.context.support.ResourceBundleThemeSource"> 2 <proterty name="basenamePrefix" value="com.text."></proterty> 3 </bean>
預設狀態下是在類路徑根目錄下查詢相應的資原始檔。也可以通過basenamePrefix來制定。這樣，DispatcherServlet就會在com.test包下查詢資原始檔。
2. 主題解析器。
ThemeSource定義了一些主題資源，那麼不同的使用者使用什麼主題資源由誰定義呢？org.Springframework.web.servlet.ThemeResolver是主題解析器的介面，主題解析器的工作便是由它的子類來完成的。
對於主題解析器的子類主要有3個比較常用的實現。以主題檔案summer.properties為例。
①FixedThemeResolver用於選擇一個固定的主題。
1 <bean id="themeSource" class="org.Springframework.web.servlet.theme.FixedThemeResolver"> 2 <proterty name="defaultThemeName" value="summer"/> 3 </bean>
以上配置的作用是設定主題檔案為summer.properties，在整個專案內固定不變。
②CookieThemeResolver用於實現使用者所選的主題，以cookie的形式存放在客戶端的機器上，配置如下：
1 <bean id="themeSource" class="org.Springframework.web.servlet.theme. CookieThemeResolver"> 2 <proterty name="defaultThemeName" value="summer"/> 3 </bean>
③SessionThemeResolver用於主題儲存在使用者的HTTP session中。
1 <bean id="themeSource" class="org.Springframework.web.servlet.theme. SessionThemeResolver"> 2 <proterty name="defaultThemeName" value="summer"/> 3 </bean>
以上配置用於設定主題名稱，並且將該名稱儲存在使用者的HttpSession中。
④AbstractThemeResolver是一個抽象類被SessionThemeResolver和FixedThemeResolver繼承，使用者也可以繼承它來自定義主題解析器。
3. 攔截器。
如果需要根據使用者請求來改變主題，那麼Spring提供了一個已經實現的攔截器ThemeChangeInterceptor攔截器了，配置如下：
1 <bean id="themeChangeInterceptor" class="org.Springframework.web.servlet.theme.ThemeChangeInterceptor"> 2 <proterty name="paramName" value="themeName"/> 3 </bean>
其中設定使用者請求引數名為themeName，即URL為？themeName=具體的主題名稱。此外，還需要在handlerMapping中配置攔截器。當然需要在handleMapping中新增攔截器。
1 <property name="interceptors"> 2 <list> 3 <ref local="themeChangeInterceptor"/> 4 </list> 5 </property>
瞭解了主題檔案的簡單使用方式後，再來檢視解析器的初始化工作。與其他變數的初始化工作相同，主題檔案解析器的初始化工作並沒有任何特別需要說明的地方。
1 private void initThemeResolver(ApplicationContext context) { 2 try { 3 this.themeResolver = context.getBean(THEME_RESOLVER_BEAN_NAME, ThemeResolver.class); 4 if (logger.isTraceEnabled()) { 5 logger.trace("Detected " + this.themeResolver); 6 } 7 else if (logger.isDebugEnabled()) { 8 logger.debug("Detected " + this.themeResolver.getClass().getSimpleName()); 9 } 10 } 11 catch (NoSuchBeanDefinitionException ex) { 12 // We need to use the default. 13 this.themeResolver = getDefaultStrategy(context, ThemeResolver.class); 14 if (logger.isTraceEnabled()) { 15 logger.trace("No ThemeResolver '" + THEME_RESOLVER_BEAN_NAME + 16 "': using default [" + this.themeResolver.getClass().getSimpleName() + "]"); 17 } 18 } 19 }
（3.4）初始化HandlerMapping
當客戶端發出Request時DispatcherServlet會將Request提交給HandlerMapping，然後HandlerMapping根據WebApplicationContext的配置來回傳給DispatcherServlet響應的Controller。
在基於SpringMVC的Web應用程式中，我們可以為DispatcherServlet提供多個HandlerMapping供其使用。DispatcherServlet在選用HandlerMapping的過程中，將根據我們所指定的一系列HandlerMapping的優先順序進行排序，然後優先使用優先順序在簽名的HandlerMapping。如果當前的HandlerMapping能夠返回可用的Handler，DispatcherServlet則使用當前返回的Handler進行Web請求的處理，而不再繼續詢問其他的HandlerMapping。否則，DispatcherServlet將繼續按照各個HandlerMapping的優先順序進行詢問，直到獲取一個可用的Handler為止。初始化配置如下：
1 private void initHandlerMappings(ApplicationContext context) { 2 this.handlerMappings = null; 3 4 if (this.detectAllHandlerMappings) { 5 // Find all HandlerMappings in the ApplicationContext, including ancestor contexts. 6 Map<String, HandlerMapping> matchingBeans = 7 BeanFactoryUtils.beansOfTypeIncludingAncestors(context, HandlerMapping.class, true, false); 8 if (!matchingBeans.isEmpty()) { 9 this.handlerMappings = new ArrayList<>(matchingBeans.values()); 10 // We keep HandlerMappings in sorted order. 11 AnnotationAwareOrderComparator.sort(this.handlerMappings); 12 } 13 } 14 else { 15 try { 16 HandlerMapping hm = context.getBean(HANDLER_MAPPING_BEAN_NAME, HandlerMapping.class); 17 this.handlerMappings = Collections.singletonList(hm); 18 } 19 catch (NoSuchBeanDefinitionException ex) { 20 // Ignore, we'll add a default HandlerMapping later. 21 } 22 } 23 24 // Ensure we have at least one HandlerMapping, by registering 25 // a default HandlerMapping if no other mappings are found. 26 if (this.handlerMappings == null) { 27 this.handlerMappings = getDefaultStrategies(context, HandlerMapping.class); 28 if (logger.isTraceEnabled()) { 29 logger.trace("No HandlerMappings declared for servlet '" + getServletName() + 30 "': using default strategies from DispatcherServlet.properties"); 31 } 32 } 33 }
預設情況下，SpringMVC將載入當前系統中所有實現了HandlerMapping介面的bean。如果只期望SpringMVC載入指定的handlerMapping時，可用修改web.xml中的DispatcherServlet的初始引數，將detectAllHandlerMappings的值設定為false：
1 <init-param> 2 <param-name>detectAllHandlerMappings</param-name> 3 <param-value>false</param-value> 4 </init-param>
此時，SpringMVC將查詢名為“HandlerMapping”的bean，並作為當前系統中唯一的handlerMapping。如果沒有定義HandlerMapping的話，則SpringMVC將按照org.Springframework.web.servlet.DispatcherServlet所在目錄下的DispatcherServlet.properties中所定義的org.Springframework.web.servlet.HandlerMapping的內容來載入預設的handlerMapping（使用者沒有自定義Strategies的情況下）。
（3.5）初始化HandlerAdapters
從名字也能聯想到這是一個典型的介面卡模式的使用，在計算機程式設計中，介面卡模式將一個類的介面適配成使用者所期待的。使用介面卡，可以使介面不相容而無法在一起工作的類協同工作。做飯是將類自己的介面包裹在一個已存在的類中。那麼在處理handler時為什麼會使用介面卡模式呢？回答這個問題我們首先要分析它的初始化邏輯。
1 private void initHandlerAdapters(ApplicationContext context) { 2 this.handlerAdapters = null; 3 4 if (this.detectAllHandlerAdapters) { 5 // Find all HandlerAdapters in the ApplicationContext, including ancestor contexts. 6 Map<String, HandlerAdapter> matchingBeans = 7 BeanFactoryUtils.beansOfTypeIncludingAncestors(context, HandlerAdapter.class, true, false); 8 if (!matchingBeans.isEmpty()) { 9 this.handlerAdapters = new ArrayList<>(matchingBeans.values()); 10 // We keep HandlerAdapters in sorted order. 11 AnnotationAwareOrderComparator.sort(this.handlerAdapters); 12 } 13 } 14 else { 15 try { 16 HandlerAdapter ha = context.getBean(HANDLER_ADAPTER_BEAN_NAME, HandlerAdapter.class); 17 this.handlerAdapters = Collections.singletonList(ha); 18 } 19 catch (NoSuchBeanDefinitionException ex) { 20 // Ignore, we'll add a default HandlerAdapter later. 21 } 22 } 23 24 // Ensure we have at least some HandlerAdapters, by registering 25 // default HandlerAdapters if no other adapters are found. 26 if (this.handlerAdapters == null) { 27 this.handlerAdapters = getDefaultStrategies(context, HandlerAdapter.class); 28 if (logger.isTraceEnabled()) { 29 logger.trace("No HandlerAdapters declared for servlet '" + getServletName() + 30 "': using default strategies from DispatcherServlet.properties"); 31 } 32 } 33 }
同樣在初始化的過程中涉及了一個變數detectAllHandlerAdapters，detectAllHandlerAdapters的作用和detectAllHandlerMapping類似，只不過作用物件為handlerAdapter。亦可通過如下配置來強制系統只加載bean name為“handlerAdapter”的handlerAdapter。
1 <init-param> 2 <param-name>detectAllHandlerAdapters</param-name> 3 <param-value>false</param-value> 4 </init-param>
如果無法找到對應的bean，那麼系統會嘗試載入預設的介面卡。
1 @SuppressWarnings("unchecked") 2 protected <T> List<T> getDefaultStrategies(ApplicationContext context, Class<T> strategyInterface) { 3 String key = strategyInterface.getName(); 4 String value = defaultStrategies.getProperty(key); 5 if (value != null) { 6 String[] classNames = StringUtils.commaDelimitedListToStringArray(value); 7 List<T> strategies = new ArrayList<>(classNames.length); 8 for (String className : classNames) { 9 try { 10 Class<?> clazz = ClassUtils.forName(className, DispatcherServlet.class.getClassLoader()); 11 Object strategy = createDefaultStrategy(context, clazz); 12 strategies.add((T) strategy); 13 } 14 catch (ClassNotFoundException ex) { 15 throw new BeanInitializationException( 16 "Could not find DispatcherServlet's default strategy class [" + className + 17 "] for interface [" + key + "]", ex); 18 } 19 catch (LinkageError err) { 20 throw new BeanInitializationException( 21 "Unresolvable class definition for DispatcherServlet's default strategy class [" + 22 className + "] for interface [" + key + "]", err); 23 } 24 } 25 return strategies; 26 } 27 else { 28 return new LinkedList<>(); 29 } 30 }
在getDefaultStrategies函式中，Spring會嘗試從defaultStrategies中載入對應的HandlerAdapter的屬性。那麼defaultStrategies是如何初始化的呢？
在當期類DispatcherServlet中存在這樣一段初始化程式碼塊：
1 static { 2 // Load default strategy implementations from properties file. 3 // This is currently strictly internal and not meant to be customized 4 // by application developers. 5 try { 6 ClassPathResource resource = new ClassPathResource(DEFAULT_STRATEGIES_PATH, DispatcherServlet.class); 7 defaultStrategies = PropertiesLoaderUtils.loadProperties(resource); 8 } 9 catch (IOException ex) { 10 throw new IllegalStateException("Could not load '" + DEFAULT_STRATEGIES_PATH + "': " + ex.getMessage()); 11 } 12 }
在系統載入的時候，defaultStrategies根據當前路徑DispatcherServlet.properties來初始化本身，檢視DispatcherServlet.properties中對應於HandlerAdapter的屬性：
1 org.springframework.web.servlet.HandlerAdapter=org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,\ 2 org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\ 3 org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter,\ 4 org.springframework.web.servlet.function.support.HandlerFunctionAdapter
由此得知，如果程式開發人員沒有再配置檔案中定義自己的介面卡，那麼Spring會預設載入配置檔案中的介面卡。
作為總控制器的派遣器servlet通過處理器對映得到處理器後，會輪詢處理器介面卡模組，查詢能夠處理當前HTTP請求的處理器介面卡的實現，處理器介面卡模組根據處理器對映發揮的處理器型別，例如簡單的控制器型別、註解控制器型別或者遠端呼叫處理器型別，來選擇某一個適當的處理器介面卡的實現，從而適配當前的HTTP請求。
1. HTTP請求處理器介面卡（HTTPRequestHandlerAdapter）。
HTTP請求處理器介面卡僅僅支援對HTTP請求處理器的適配。它簡單的將HTTP請求物件和響應物件傳遞給HTTP請求處理器的實現，它並不需要返回值。它主要應用在基於HTTP的遠端呼叫的實現上。
2. 簡單控制器介面卡（SimpleControllerHandlerAdapter）。
這個實現類將HTTP請求適配到一個控制器的實現進行處理。這裡控制器的實現是一個簡單的控制器介面的實現。簡單控制器處理器介面卡被設計成一個框架類的實現，不需要被改寫，客戶化的業務邏輯通常是在控制器介面的實現類中實現的。
3. 註解方法處理器介面卡（AnnotationMethodHandlerAdapte）。
這個類的實現是基於註解的實現，它需要結合註解方法對映和註解方法處理器協同工作。它通過解析宣告在註解控制器的請求對映資訊來解析相應的處理器方法來處理當前的HTTP請求。在處理的過程中，它通過反射來發現探測處理器方法的引數，呼叫處理器方法，並且對映返回值到模型和控制器物件，最後返回模型和控制器物件給作為主控制器的派遣器Servlet.
所以我們現在基本可以回答之前的問題了，Spring找那個所使用的Handler並沒有任何特殊的聯絡，但是為了統一處理，Spring提供了不同情況下的介面卡。
（3.6）初始化HandlerExceptionResolver。
基於HandlerExceptionResolver介面的異常處理，使用這種方式只需要實現resolveException方法，該方法返回一個ModelAndView物件，在方法內部對異常的型別進行判斷，然後嘗試生成對應的ModelAndView物件，如果該方法返回了null，則Spring會繼續尋找其他的實現了HandlerExceptionResolver介面的bean。換句話說，Spring會搜尋所有註冊在其環境中的實現了HandlerExceptionResolver介面的bean，逐個執行，直到返回了一個ModelAndView物件。
1 import javax.servlet.http.HttpServletRequest; 2 import javax.servlet.http.HttpServletResponse; 3 4 import org.apache.commons.logging.Log; 5 import org.apache.commons.logging.LogFactory; 6 import org.Springframework.stereotype.Componet; 7 import org.Springframwwork.web.servlet.HandlerExceptionResolver; 8 import org.Springframework.web.servlet.ModelAndView; 9 10 @component 11 public class ExceptionHandler implements HandlerExceptionResolver{ 12 private static final Log = logs = LogFactory.getLog(ExceptionHandler.class); 13 14 @override 15 public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object obj, Exception exception){ 16 request.setAttribute("exception", exception.toString()); 17 request.setAttribute("exceptionStack", exception); 18 logs.error(exception.toString(), exception); 19 return new ModelAndView("error/exception"); 20 } 21 }
這個類必須宣告到Spring中去，讓Spring管理它，在Spring的配置檔案applicationContext.xml中增加以下內容：
<bean id="exceptionHandler" class="com.test.exception.MyExceptionHandler"/>
初始化程式碼如下：
1 private void initHandlerExceptionResolvers(ApplicationContext context) { 2 this.handlerExceptionResolvers = null; 3 4 if (this.detectAllHandlerExceptionResolvers) { 5 // Find all HandlerExceptionResolvers in the ApplicationContext, including ancestor contexts. 6 Map<String, HandlerExceptionResolver> matchingBeans = BeanFactoryUtils 7 .beansOfTypeIncludingAncestors(context, HandlerExceptionResolver.class, true, false); 8 if (!matchingBeans.isEmpty()) { 9 this.handlerExceptionResolvers = new ArrayList<>(matchingBeans.values()); 10 // We keep HandlerExceptionResolvers in sorted order. 11 AnnotationAwareOrderComparator.sort(this.handlerExceptionResolvers); 12 } 13 } 14 else { 15 try { 16 HandlerExceptionResolver her = 17 context.getBean(HANDLER_EXCEPTION_RESOLVER_BEAN_NAME, HandlerExceptionResolver.class); 18 this.handlerExceptionResolvers = Collections.singletonList(her); 19 } 20 catch (NoSuchBeanDefinitionException ex) { 21 // Ignore, no HandlerExceptionResolver is fine too. 22 } 23 } 24 25 // Ensure we have at least some HandlerExceptionResolvers, by registering 26 // default HandlerExceptionResolvers if no other resolvers are found. 27 if (this.handlerExceptionResolvers == null) { 28 this.handlerExceptionResolvers = getDefaultStrategies(context, HandlerExceptionResolver.class); 29 if (logger.isTraceEnabled()) { 30 logger.trace("No HandlerExceptionResolvers declared in servlet '" + getServletName() + 31 "': using default strategies from DispatcherServlet.properties"); 32 } 33 } 34 }
（3.7）初始化RequestToViewNameTranslator。
當Controller處理器方法沒有返回一個View物件或邏輯檢視名稱，並且在該方法中沒有直接往response的輸出流裡面寫資料的時候，Spring就會採用約定好的方式提供一個邏輯檢視名稱。這個邏輯檢視名稱是通過Spring定義的org.Springframework.web.servlet.RequestToViewNameTranslator介面的getViewName方法來實現的，我們可以實現自己RequestToViewNameTranslator介面來約定好沒有返回檢視名稱的時候如何確定檢視名稱。Spring已經給我們提供了一個它自己的實現，那就是org.Springframework.web.servlet.view.DefaultRequestToViewNameTranslator。
在介紹DefaultRequestToViewNameTranslator是如何約定檢視名稱之前，先來看一下它支援使用者定義的屬性。
prefix：字首，表示約定好的檢視名稱需要加上的字首，預設是空串。
suffix：字尾，表示約定好的檢視名稱需要加上的字尾，預設是空串。
separator：分隔符，預設是斜槓“/”。
stripLeadingSlash：如果首字元是分隔符，是否要去除，預設是true。
stripTrailingSlash：如果最後一個字元是分隔符，是否要去除，預設是true。
stripExtension：如果請求路徑包含副檔名是否要去除，預設是true。
urlDecode：是否需要對URL編碼，預設是ture。它會採用request指定的編碼或者ISO-8859-1編碼對URL進行解碼。
當我們沒有再SpringMVC的配置檔案中手動的定義一個名為viewNameTranlator的Bean的時候，Spring就會為我們提供一個預設的viewNameTranslator，即DefaultRequestToViewNameTranslator。
接下來看一下，當Controller處理器方法沒有返回邏輯檢視名稱時，DefaultRequestToViewNameTranslator是如何約定檢視名稱的。DefaultRequestToViewNameTranslator會獲取到請求的URL，然後根據提供的屬性做一些改造，把改造之後的結果作為檢視名稱返回。這裡以請求路徑http://localhost/app/test/index.html為例，來說明一下DefaultRequestToViewNameTranslator是如何工作的。該請求路徑對應的請求URI為/test/index.html，我們來看以下幾種情況，它分別對應的邏輯檢視名稱是什麼。
prefix和suffix如果都存在，其他為預設值，那麼對應返回的邏輯檢視名稱應該是prefixtest/indexsuffix。
stripLeadingSlash和stripExtension都為false，其他為預設，這時候對應的邏輯檢視名稱是/product/index.html。
都採用預設配置時，返回的邏輯檢視名稱應該是product/index。
如果邏輯檢視名稱跟請求路徑相同或者相關關係都是一樣的，那麼我們就可以採用Spring為我們事先約定好的邏輯檢視名稱返回，這可以大大簡化我們的開發工作，而以上功能實現的關鍵屬性viewNameTranslator，則是在initRequestToViewNameTranslator中完成的。
1 private void initRequestToViewNameTranslator(ApplicationContext context) { 2 try { 3 this.viewNameTranslator = 4 context.getBean(REQUEST_TO_VIEW_NAME_TRANSLATOR_BEAN_NAME, RequestToViewNameTranslator.class); 5 if (logger.isTraceEnabled()) { 6 logger.trace("Detected " + this.viewNameTranslator.getClass().getSimpleName()); 7 } 8 else if (logger.isDebugEnabled()) { 9 logger.debug("Detected " + this.viewNameTranslator); 10 } 11 } 12 catch (NoSuchBeanDefinitionException ex) { 13 // We need to use the default. 14 this.viewNameTranslator = getDefaultStrategy(context, RequestToViewNameTranslator.class); 15 if (logger.isTraceEnabled()) { 16 logger.trace("No RequestToViewNameTranslator '" + REQUEST_TO_VIEW_NAME_TRANSLATOR_BEAN_NAME + 17 "': using default [" + this.viewNameTranslator.getClass().getSimpleName() + "]"); 18 } 19 } 20 }
（3.8）初始化ViewResolvers。
在SpringMVC中，當Controller將請求處理結果放入到ModelAndView中以後，DispatcherServlet會根據ModelAndView選擇合適的檢視進行渲染。那麼在SpringMVC中是如何選擇合適的View的呢？View物件是如何建立的呢？答案就在ViewResolver中。ViewResolver介面定義了resolverViewName方法，根據ViewName建立合適型別的View實現。
那麼如何配置ViewResolver呢？在Spring中，ViewResolver作為Spring Bean存在，可以在Spring配置檔案中進行配置，例如下面的程式碼，配置了JSP相關的viewResolver。
1 <bean class="org.Springframework.web.servlet.view.InternalResourceViewResolver"> 2 <property name="prefix" value="/WEB-INF/views/"/> 3 <property name="suffix" value=".jsp"/> 4 </bean>
ViewResolver屬性的初始化工作在initViewResolver中完成。
1 private void initViewResolvers(ApplicationContext context) { 2 this.viewResolvers = null; 3 4 if (this.detectAllViewResolvers) { 5 // Find all ViewResolvers in the ApplicationContext, including ancestor contexts. 6 Map<String, ViewResolver> matchingBeans = 7 BeanFactoryUtils.beansOfTypeIncludingAncestors(context, ViewResolver.class, true, false); 8 if (!matchingBeans.isEmpty()) { 9 this.viewResolvers = new ArrayList<>(matchingBeans.values()); 10 // We keep ViewResolvers in sorted order. 11 AnnotationAwareOrderComparator.sort(this.viewResolvers); 12 } 13 } 14 else { 15 try { 16 ViewResolver vr = context.getBean(VIEW_RESOLVER_BEAN_NAME, ViewResolver.class); 17 this.viewResolvers = Collections.singletonList(vr); 18 } 19 catch (NoSuchBeanDefinitionException ex) { 20 // Ignore, we'll add a default ViewResolver later. 21 } 22 } 23 24 // Ensure we have at least one ViewResolver, by registering 25 // a default ViewResolver if no other resolvers are found. 26 if (this.viewResolvers == null) { 27 this.viewResolvers = getDefaultStrategies(context, ViewResolver.class); 28 if (logger.isTraceEnabled()) { 29 logger.trace("No ViewResolvers declared for servlet '" + getServletName() + 30 "': using default strategies from DispatcherServlet.properties"); 31 } 32 } 33 }
（3.9）初始化FlashMapManager。
SpringMVC Flash attributes提供了一個請求儲存屬性，可供其他請求使用。在使用重定向時候非常必要，例如Post/Redirect/Get模式。Flash attribute在重定向之前暫存（就像存在session中）以便重定向之後還能使用，並立即刪除。
SpringMVC有兩個主要的抽象來支援Flash attributes。FlashMap用於保持Flash attributes，而FlashMapManager用於儲存、檢索、管理FlashMap例項。
Flash attributes支援預設開啟（“on”）並不需要顯示啟用，它永遠不會導致HTTP Session的建立。這兩個FlashMap例項都可以通過靜態方法RequestContextUtils從SpringMVC的任何位置訪問。
FlashMapManager的初始化在initFlashMapManager中完成。
1 private void initFlashMapManager(ApplicationContext context) { 2 try { 3 this.flashMapManager = context.getBean(FLASH_MAP_MANAGER_BEAN_NAME, FlashMapManager.class); 4 if (logger.isTraceEnabled()) { 5 logger.trace("Detected " + this.flashMapManager.getClass().getSimpleName()); 6 } 7 else if (logger.isDebugEnabled()) { 8 logger.debug("Detected " + this.flashMapManager); 9 } 10 } 11 catch (NoSuchBeanDefinitionException ex) { 12 // We need to use the default. 13 this.flashMapManager = getDefaultStrategy(context, FlashMapManager.class); 14 if (logger.isTraceEnabled()) { 15 logger.trace("No FlashMapManager '" + FLASH_MAP_MANAGER_BEAN_NAME + 16 "': using default [" + this.flashMapManager.getClass().getSimpleName() + "]"); 17 } 18 } 19 }
四、 DispatcherServlet的處理邏輯
根據之前的示例，我們知道在HttpServlet類中分別提供了相應的服務方法，他們是doDelete()、doGet()、doOptions()、doGet()、doPut()和doTrace()，它會根據請求的不同形式將程式引導至對應的函式進行處理。這幾個函式中最常用的函式無非就是doGet()和doGet()，那麼我們就直接檢視DispatcherServlet中對於這兩個函式的實現邏輯（在其父類FrameworkServlet中實現）。
1 protected final void doGet(HttpServletRequest request, HttpServletResponse response) 2 throws ServletException, IOException { 3 4 processRequest(request, response); 5 }
1 protected final void doPost(HttpServletRequest request, HttpServletResponse response) 2 throws ServletException, IOException { 3 4 processRequest(request, response); 5 }
對於不同的方法，Spring並沒有做特殊的處理，而是統一將程式再一次地引導至processRequest(request, response)中。
1 protected final void processRequest(HttpServletRequest request, HttpServletResponse response) 2 throws ServletException, IOException { 3 4 //記錄當前時間，用於計算web請求的處理時間 5 long startTime = System.currentTimeMillis(); 6 Throwable failureCause = null; 7 8 LocaleContext previousLocaleContext = LocaleContextHolder.getLocaleContext(); 9 LocaleContext localeContext = buildLocaleContext(request); 10 11 RequestAttributes previousAttributes = RequestContextHolder.getRequestAttributes(); 12 ServletRequestAttributes requestAttributes = buildRequestAttributes(request, response, previousAttributes); 13 14 WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request); 15 asyncManager.registerCallableInterceptor(FrameworkServlet.class.getName(), new RequestBindingInterceptor()); 16 17 initContextHolders(request, localeContext, requestAttributes); 18 19 try { 20 doService(request, response); 21 } 22 catch (ServletException | IOException ex) { 23 failureCause = ex; 24 throw ex; 25 } 26 catch (Throwable ex) { 27 failureCause = ex; 28 throw new NestedServletException("Request processing failed", ex); 29 } 30 31 finally { 32 resetContextHolders(request, previousLocaleContext, previousAttributes); 33 if (requestAttributes != null) { 34 requestAttributes.requestCompleted(); 35 } 36 logResult(request, response, failureCause, asyncManager); 37 publishRequestHandledEvent(request, response, startTime, failureCause); 38 } 39 }
函式中已經開始了對請求的處理，雖然吧細節轉移到了doService函式中實現，但是我們不難看出處理請求前後所做的準備與處理工作。
（1）為了保證當前執行緒的LocalContext以及RequestAttribute可以在當前請求後還能恢復，提取當前執行緒的兩個屬性。
（2）根據當前request建立對應的LocalContext和RequestAttributes，並繫結到當前執行緒。
（3）委託給doService方法進一步處理。
（4）請求處理結束後恢復執行緒到原始狀態。
（5）請求處理結束後無論成功與否釋出事件通知。
繼續檢視doService方法。
1 protected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception { 2 logRequest(request); 3 4 // Keep a snapshot of the request attributes in case of an include, 5 // to be able to restore the original attributes after the include. 6 Map<String, Object> attributesSnapshot = null; 7 if (WebUtils.isIncludeRequest(request)) { 8 attributesSnapshot = new HashMap<>(); 9 Enumeration<?> attrNames = request.getAttributeNames(); 10 while (attrNames.hasMoreElements()) { 11 String attrName = (String) attrNames.nextElement(); 12 if (this.cleanupAfterInclude || attrName.startsWith(DEFAULT_STRATEGIES_PREFIX)) { 13 attributesSnapshot.put(attrName, request.getAttribute(attrName)); 14 } 15 } 16 } 17 18 // Make framework objects available to handlers and view objects. 19 request.setAttribute(WEB_APPLICATION_CONTEXT_ATTRIBUTE, getWebApplicationContext()); 20 request.setAttribute(LOCALE_RESOLVER_ATTRIBUTE, this.localeResolver); 21 request.setAttribute(THEME_RESOLVER_ATTRIBUTE, this.themeResolver); 22 request.setAttribute(THEME_SOURCE_ATTRIBUTE, getThemeSource()); 23 24 if (this.flashMapManager != null) { 25 FlashMap inputFlashMap = this.flashMapManager.retrieveAndUpdate(request, response); 26 if (inputFlashMap != null) { 27 request.setAttribute(INPUT_FLASH_MAP_ATTRIBUTE, Collections.unmodifiableMap(inputFlashMap)); 28 } 29 request.setAttribute(OUTPUT_FLASH_MAP_ATTRIBUTE, new FlashMap()); 30 request.setAttribute(FLASH_MAP_MANAGER_ATTRIBUTE, this.flashMapManager); 31 } 32 33 try { 34 doDispatch(request, response); 35 } 36 finally { 37 if (!WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) { 38 // Restore the original attribute snapshot, in case of an include. 39 if (attributesSnapshot != null) { 40 restoreAttributesAfterInclude(request, attributesSnapshot); 41 } 42 } 43 } 44 }
我們猜想對請求處理至少應該包括一些諸如尋找Handler並頁面跳轉之類的邏輯處理，但是，在doService中我們並沒有看到想看到的邏輯，相反卻同樣是一些準備工作，但是這些準備工作確實必不可少的。Spring將已經初始化的功能輔助工具變數，比如localeResolver、ThemeResolver等設定在request屬性中，而這些屬性會在接下來額處理中派上用場。
經過層層的準備工作，終於在doDispatch函式中看到了完整的請求處理過程。
1 protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception { 2 HttpServletRequest processedRequest = request; 3 HandlerExecutionChain mappedHandler = null; 4 boolean multipartRequestParsed = false; 5 6 WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request); 7 8 try { 9 ModelAndView mv = null; 10 Exception dispatchException = null; 11 12 try { 13 //如果是MultipartContent型別的request則轉換request為MultipartHttpServletRequest型別的request 14 processedRequest = checkMultipart(request); 15 multipartRequestParsed = (processedRequest != request); 16 17 // Determine handler for the current request. 18 //根據request資訊尋找對應的Handler 19 mappedHandler = getHandler(processedRequest); 20 if (mappedHandler == null) { 21 //如果沒有找到對應的handler則通過response反饋錯誤資訊 22 noHandlerFound(processedRequest, response); 23 return; 24 } 25 26 // Determine handler adapter for the current request. 27 //根據當前的handler尋找對應的HandlerAdapter 28 HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler()); 29 30 // Process last-modified header, if supported by the handler. 31 //如果當前handler支援last-modified頭處理 32 String method = request.getMethod(); 33 boolean isGet = "GET".equals(method); 34 if (isGet || "HEAD".equals(method)) { 35 long lastModified = ha.getLastModified(request, mappedHandler.getHandler()); 36 if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) { 37 return; 38 } 39 } 40 41 if (!mappedHandler.applyPreHandle(processedRequest, response)) { 42 return; 43 } 44 45 // Actually invoke the handler. 46 //真正的啟用handler並返回檢視 47 mv = ha.handle(processedRequest, response, mappedHandler.getHandler()); 48 49 if (asyncManager.isConcurrentHandlingStarted()) { 50 return; 51 } 52 53 applyDefaultViewName(processedRequest, mv); 54 mappedHandler.applyPostHandle(processedRequest, response, mv); 55 } 56 catch (Exception ex) { 57 dispatchException = ex; 58 } 59 catch (Throwable err) { 60 // As of 4.3, we're processing Errors thrown from handler methods as well, 61 // making them available for @ExceptionHandler methods and other scenarios. 62 dispatchException = new NestedServletException("Handler dispatch failed", err); 63 } 64 processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException); 65 } 66 catch (Exception ex) { 67 triggerAfterCompletion(processedRequest, response, mappedHandler, ex); 68 } 69 catch (Throwable err) { 70 triggerAfterCompletion(processedRequest, response, mappedHandler, 71 new NestedServletException("Handler processing failed", err)); 72 } 73 finally { 74 if (asyncManager.isConcurrentHandlingStarted()) { 75 // Instead of postHandle and afterCompletion 76 if (mappedHandler != null) { 77 mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response); 78 } 79 } 80 else { 81 // Clean up any resources used by a multipart request. 82 if (multipartRequestParsed) { 83 cleanupMultipart(processedRequest); 84 } 85 } 86 } 87 }
doDispatch函式中展示了Spring請求處理所涉及的主要邏輯，而我們之前設定在request中的各種輔助屬性也都有被派上了用場。下面回顧一下邏輯處理的全過程。
（一）MultipartContent型別的request處理
對於請求的處理，Spring首先要考慮的是對於Multipart的處理，如果是MultipartContent型別的request，則轉換request為MultipartHttpServletRequest型別的request。
1 protected HttpServletRequest checkMultipart(HttpServletRequest request) throws MultipartException { 2 if (this.multipartResolver != null && this.multipartResolver.isMultipart(request)) { 3 if (WebUtils.getNativeRequest(request, MultipartHttpServletRequest.class) != null) { 4 if (request.getDispatcherType().equals(DispatcherType.REQUEST)) { 5 logger.trace("Request already resolved to MultipartHttpServletRequest, e.g. by MultipartFilter"); 6 } 7 } 8 else if (hasMultipartException(request)) { 9 logger.debug("Multipart resolution previously failed for current request - " + 10 "skipping re-resolution for undisturbed error rendering"); 11 } 12 else { 13 try { 14 return this.multipartResolver.resolveMultipart(request); 15 } 16 catch (MultipartException ex) { 17 if (request.getAttribute(WebUtils.ERROR_EXCEPTION_ATTRIBUTE) != null) { 18 logger.debug("Multipart resolution failed for error dispatch", ex); 19 // Keep processing error dispatch with regular request handle below 20 } 21 else { 22 throw ex; 23 } 24 } 25 } 26 } 27 // If not returned before: return original request. 28 return request; 29 }
（二） 根據request資訊尋找對應的handler
在Spring中最簡單的對映處理器配置如下：
1 <bean id="simpleUrlMapping" class="org.Springframework.web.servlet.handler.SimpleUrlHandlerMapping"> 2 <property name="mapping"> 3 <props> 4 <prop key="/userlist.htm">userController</prop> 5 </props> 6 </property> 7 </bean>
在Spring的載入過程中，Spring會將型別為SimpleUrlHandlerMapping的例項載入到this.handlerMappings中，按照常理推斷，根據request提取對應的Handler，無非就是提取當前例項中的userController，但是userController為繼承自AbstractController型別例項，與HandlerExecutionChain並無任何關聯，那麼進一步是如何封裝的呢？
1 protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception { 2 if (this.handlerMappings != null) { 3 for (HandlerMapping mapping : this.handlerMappings) { 4 HandlerExecutionChain handler = mapping.getHandler(request); 5 if (handler != null) { 6 return handler; 7 } 8 } 9 } 10 return null; 11 }
在之前的內容中我們提過，在系統啟動時Spring會將所有的對映型別的bean註冊到this.handlerMappings變數中，所以此函式的目的就是遍歷所有的HandlerMapping，並呼叫其getHandler方法進行封裝處理。以SimpleUrlHandlerMapping為例檢視其getHandler方法。
函式中首先會使用getHandlerInternal方法根據request資訊獲取到對應的Handler，如果以SimpleUrlHandlerMapping為例分析，那麼我們推斷此步驟提供的功能很可能就是根據URL找到匹配的Controller並返回，當然如果沒有找到對應的Controller處理器那麼程式會嘗試去查詢配置中的預設處理器，當然，當查詢的Controller為String型別時，那就意味著返回的是配置的bean名稱，需要根據bean名稱查詢對應的bean，最後，還要通過getHandlerExecutionChain方法對返回的Handler進行封裝，以保證滿足返回型別的匹配。下面詳細分析這個過程。
1. 根據request查詢對應的Handler
首先從根據request查詢對應的Handler開始分析。
1 protected Object getHandlerInternal(HttpServletRequest request) throws Exception { 2 //擷取用於匹配的url有效路徑 3 String lookupPath = getUrlPathHelper().getLookupPathForRequest(request); 4 request.setAttribute(LOOKUP_PATH, lookupPath); 5 //根據路徑尋找Handler 6 Object handler = lookupHandler(lookupPath, request); 7 if (handler == null) { 8 // We need to care for the default handler directly, since we need to 9 // expose the PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE for it as well. 10 Object rawHandler = null; 11 if ("/".equals(lookupPath)) { 12 //如果請求的路徑僅僅是“/”，那麼使用RootHandler進行處理 13 rawHandler = getRootHandler(); 14 } 15 if (rawHandler == null) { 16 //無法找到handler則使用預設的handler 17 rawHandler = getDefaultHandler(); 18 } 19 if (rawHandler != null) { 20 //根據beanName獲取對應的bean 21 // Bean name or resolved handler? 22 if (rawHandler instanceof String) { 23 String handlerName = (String) rawHandler; 24 rawHandler = obtainApplicationContext().getBean(handlerName); 25 } 26 //模板方法 27 validateHandler(rawHandler, request); 28 handler = buildPathExposingHandler(rawHandler, lookupPath, lookupPath, null); 29 } 30 } 31 return handler; 32 }
1 protected Object lookupHandler(String urlPath, HttpServletRequest request) throws Exception { 2 // Direct match? 3 //直接匹配情況的處理 4 Object handler = this.handlerMap.get(urlPath); 5 if (handler != null) { 6 // Bean name or resolved handler? 7 if (handler instanceof String) { 8 String handlerName = (String) handler; 9 handler = obtainApplicationContext().getBean(handlerName); 10 } 11 validateHandler(handler, request); 12 return buildPathExposingHandler(handler, urlPath, urlPath, null); 13 } 14 15 // Pattern match? 16 //萬用字元匹配的處理 17 List<String> matchingPatterns = new ArrayList<>(); 18 for (String registeredPattern : this.handlerMap.keySet()) { 19 if (getPathMatcher().match(registeredPattern, urlPath)) { 20 matchingPatterns.add(registeredPattern); 21 } 22 else if (useTrailingSlashMatch()) { 23 if (!registeredPattern.endsWith("/") && getPathMatcher().match(registeredPattern + "/", urlPath)) { 24 matchingPatterns.add(registeredPattern + "/"); 25 } 26 } 27 } 28 29 String bestMatch = null; 30 Comparator<String> patternComparator = getPathMatcher().getPatternComparator(urlPath); 31 if (!matchingPatterns.isEmpty()) { 32 matchingPatterns.sort(patternComparator); 33 if (logger.isTraceEnabled() && matchingPatterns.size() > 1) { 34 logger.trace("Matching patterns " + matchingPatterns); 35 } 36 bestMatch = matchingPatterns.get(0); 37 } 38 if (bestMatch != null) { 39 handler = this.handlerMap.get(bestMatch); 40 if (handler == null) { 41 if (bestMatch.endsWith("/")) { 42 handler = this.handlerMap.get(bestMatch.substring(0, bestMatch.length() - 1)); 43 } 44 if (handler == null) { 45 throw new IllegalStateException( 46 "Could not find handler for best pattern match [" + bestMatch + "]"); 47 } 48 } 49 // Bean name or resolved handler? 50 if (handler instanceof String) { 51 String handlerName = (String) handler; 52 handler = obtainApplicationContext().getBean(handlerName); 53 } 54 validateHandler(handler, request); 55 String pathWithinMapping = getPathMatcher().extractPathWithinPattern(bestMatch, urlPath); 56 57 // There might be multiple 'best patterns', let's make sure we have the correct URI template variables 58 // for all of them 59 Map<String, String> uriTemplateVariables = new LinkedHashMap<>(); 60 for (String matchingPattern : matchingPatterns) { 61 if (patternComparator.compare(bestMatch, matchingPattern) == 0) { 62 Map<String, String> vars = getPathMatcher().extractUriTemplateVariables(matchingPattern, urlPath); 63 Map<String, String> decodedVars = getUrlPathHelper().decodePathVariables(request, vars); 64 uriTemplateVariables.putAll(decodedVars); 65 } 66 } 67 if (logger.isTraceEnabled() && uriTemplateVariables.size() > 0) { 68 logger.trace("URI variables " + uriTemplateVariables); 69 } 70 return buildPathExposingHandler(handler, bestMatch, pathWithinMapping, uriTemplateVariables); 71 } 72 73 // No handler found... 74 return null; 75 }
根據URL獲取對應Handler的匹配規則程式碼實現起來雖然很長，但是並不難理解，考慮了直接匹配與萬用字元兩種情況。其中要提及的是buildPathExposingHandler函式，它將Handler封裝成了HandlerExecutionChain型別。
1 protected Object buildPathExposingHandler(Object rawHandler, String bestMatchingPattern, 2 String pathWithinMapping, @Nullable Map<String, String> uriTemplateVariables) { 3 4 HandlerExecutionChain chain = new HandlerExecutionChain(rawHandler); 5 chain.addInterceptor(new PathExposingHandlerInterceptor(bestMatchingPattern, pathWithinMapping)); 6 if (!CollectionUtils.isEmpty(uriTemplateVariables)) { 7 chain.addInterceptor(new UriTemplateVariablesHandlerInterceptor(uriTemplateVariables)); 8 } 9 return chain; 10 }
在函式中我們看到了通過將Handler以引數形式傳入，並構建HandlerExcutionChain型別例項，加入了兩個攔截器。此時我們似乎已經瞭解了Spring這樣大費周折的目的。鏈處理機制，是Spring中非常常用的處理方式，是AOP中的重要組成部分，可以方便地對目標物件進行擴充套件及攔截，這是非常優秀的設計。
2. 加入攔截器到執行鏈
將配置中的對應攔截器加入到執行鏈找中，以保證這些攔截器可以有效的作用於目標物件。
1 protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception { 2 if (this.handlerMappings != null) { 3 for (HandlerMapping mapping : this.handlerMappings) { 4 HandlerExecutionChain handler = mapping.getHandler(request); 5 if (handler != null) { 6 return handler; 7 } 8 } 9 } 10 return null; 11 }
（三）沒找到對應的Handler的錯誤處理
每個請求都應該對應著一個Handler，因為每個請求都會在後臺有相應的邏輯對應，而邏輯的實現就是在Handler中，所以一旦遇到沒有找到Handler的情況（正常情況下如果沒有URL匹配的Handler，開發人員可以設定預設的Handler來處理請求，但是如果預設請求也未設定就會出現Handler為空的情況），就只能通過response向用戶返回錯誤資訊。
1 protected void noHandlerFound(HttpServletRequest request, HttpServletResponse response) throws Exception { 2 if (pageNotFoundLogger.isWarnEnabled()) { 3 pageNotFoundLogger.warn("No mapping for " + request.getMethod() + " " + getRequestUri(request)); 4 } 5 if (this.throwExceptionIfNoHandlerFound) { 6 throw new NoHandlerFoundException(request.getMethod(), getRequestUri(request), 7 new ServletServerHttpRequest(request).getHeaders()); 8 } 9 else { 10 response.sendError(HttpServletResponse.SC_NOT_FOUND); 11 } 12 }
（四）根據當前的Handler尋找對應的HandlerAdapter
在WebApplicationContext的初始化過程中我們討論了HandlerAdapter的初始化，瞭解了在預設的情況下普通的Web請求會交給SimpleControllerHandlerAdapter去處理。下面我們以SimpleControllerHandlerAdapter為例來分析獲取介面卡的邏輯。
1 protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException { 2 if (this.handlerAdapters != null) { 3 for (HandlerAdapter adapter : this.handlerAdapters) { 4 if (adapter.supports(handler)) { 5 return adapter; 6 } 7 } 8 } 9 throw new ServletException("No adapter for handler [" + handler + 10 "]: The DispatcherServlet configuration needs to include a HandlerAdapter that supports this handler"); 11 }
通過上面的函式我們瞭解到，對於獲取介面卡的邏輯無非就是遍歷所有的介面卡來選擇合適的介面卡並返回它，而某個介面卡是否適用於當前的Handler邏輯被封裝在具體的介面卡中。進一步檢視SimpleControllerHandlerAdapter的supports方法。
1 @Override 2 public boolean supports(Object handler) { 3 return (handler instanceof Controller); 4 }
分析到這裡，一切已經明瞭，SimpleControllerHandlerAdapter就是用於處理普通的Web請求的，而且對於SpringMVC來說，我們會把邏輯封裝至Controller的子類中，例如我們之前的引導示例UserController就是繼承自AbstractController，而AbstractController實現了Controller介面。
（五）快取處理
在研究Spring對快取處理的功能支援前，我們先來了解一個概念：Last-Modified快取機制。
（1）在客戶端第一次輸入URL時，伺服器會返回內容和狀態碼200，表示請求成功，同時會新增一個“Last-Modified”的響應頭，表示此檔案在伺服器上的最後更新時間，例如，“Last-Modified:Wed, 14 Mar 2012 10:22:42 GMT”表示最後更新時間為（2012-03-14 10:22）。
（2）客戶端第二次請求此URL時，客戶端會向伺服器傳送請求頭”If-Modified-Since”。詢問伺服器該時間之後當前請求內容是否有被修改過，如” If-Modified-Since: Wed, 14 Mar 2012 10:22:42 GMT”，如果伺服器端的內容沒有變化，則自動返回HTTP 304狀態碼（只要響應頭，內容為空，這樣就節省了網路頻寬）。
Spring提供的對Last-Modified機制的支援，只需要實現LastModified介面，如下所示：
1 public class HelloWorldLastModifiedCacheController extends AbstractController implements LastModified{ 2 private long lastModified; 3 protected ModelAndView handleRequestInternal(HttpServletRequest req, HttpServletResponse resp) throws Exception{ 4 //點選後再次請求當前頁面 5 resp.getWrite().write("<a href=''>this</a>"); 6 return null; 7 } 8 9 public long getLastModified(HttpServletRequest request){ 10 if(lastModified == 0L){ 11 //第一次或者邏輯有變化的時候，應該重新返回內容最新修改的時間戳 12 lastModified = System.currentTimeMillis(); 13 } 14 return lastModified; 15 } 16 }
HelloWorldLastModifiedCacheController只需要實現LastModified介面的getLastModified方法，保證當內容發生改變時返回最新的修改時間即可。
Spring判斷是否過期，通過判斷請求”If-Modified-Since”是否大於等於當前的getLastModified方法的時間戳。如果是，則認為沒有修改。上面的Controller與普通的Controller並無太大的差別，宣告如下：
<bean name="/helloLastModified" class="com.test.controller.HelloWorldLastModifiedCacheController"/>
（六）HandlerInterceptor的處理
Servlet API定義的servlet過濾器可以在servelt處理每個Web請求的前後分別對它進行前置處理和後置處理。此外，有些時候，你可能只想處理由某些SpringMVC處理程式處理的Web請求，並在這些處理程式返回的模型屬性被傳遞到檢視之前，對它們進行一些操作。
SpringMVC允許你通過處理攔截Web請求，進行前置處理和後置處理。處理攔截是在Spring的Web應用程式上下文中配置的，因此它們可以利用各種容器特性，並引用容器中宣告的任何bean。處理攔截是針對特殊的處理程式對映進行註冊的，因此它只攔截通過這些處理程式對映的請求。每個處理攔截都必須實現HandlerInterceptor介面，它包含三個需要你實現的回撥方法：preHandle()、postHandle()和afterCompletion()。第一個和第二個方法分別是在處理程式處理請求之前和之後被呼叫的。第二個方法還允許訪問返回的ModelAndView物件，因此可以在裡面操作之前和之後被呼叫。第二個方法還允許訪問返回的ModelAndView物件，因此可以在它裡面操作模型屬性。最後一個方法是在所有請求處理完成之後被呼叫的（如檢視呈現之後），以下是HandlerInterceptor的簡單實現：
1 public class MyTestInterceptor implements HandlerInterceptor{ 2 public boolean preHandler(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception{ 3 long startTime = System.currentTimeMillis(); 4 request.setAttribute("startTime", startTime); 5 return true; 6 } 7 8 public void postHandler(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception{ 9 long startTime = (Long)request.getAtribute("startTime"); 10 request.removeAttribute("startTime"); 11 long endTime = System.currentTimeMillis(); 12 modelAndView.addObject("handlingTime", endTime-startTime); 13 } 14 15 public void afterCompletion((HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception{ 16 } 17 }
在這個攔截器的preHandler()方法中，你記錄了起始時間，並將它儲存到請求屬性中。這個方法應該返回true，執行DispatcherServlet繼續處理請求。否則DispatcherServlet會認為這個方法已經處理了請求，直接將響應返回給使用者。然後，在postHandler()方法中，從請求屬性中載入起始時間，並將它與當前時間進行比較。你可以計算總的持續時間，然後把這個時間新增到模型中，傳遞給檢視。最後afterCompletion()方法無事可做，空著就可以了。
（七）邏輯處理
對於邏輯處理其實是通過介面卡中轉呼叫Handler並返回檢視的，對應程式碼：
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
同樣，還是以引導示例為基礎進行處理邏輯分析，之前分析過，對於普通的Web請求，Spring預設使用SimpleControllerHandlerAdapter類進行處理，我們進入SimpleControllerHandlerAdapter類的handle方法如下：
1 public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) 2 throws Exception { 3 4 return ((Controller) handler).handleRequest(request, response); 5 }
但是回顧引導示例中的UserController，我們的邏輯是寫在handleRequestInternal函式中而不是handleRequest函式，所以我們還需要進一步分析這期間所包含的處理流程。
（八）異常檢視的處理
有時候系統執行過程中出現異常，而我們並不希望就此中斷對使用者的服務。而是至少告知客戶當前系統在處理邏輯的過程中出現了異常，甚至告知他們因為什麼原因導致的。Spring中的異常處理機制會幫我們完成這個工作。其實，這裡Spring主要的工作就是將邏輯引導至HandlerExceptionResolver類的resolveException方法，而HandlerExceptionResolver的使用。我們再講解WebApplicationContext的初始化的時候已經介紹過了。
1 protected ModelAndView processHandlerException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception{ 2 //Check resistered handlerExceptionResolvers... 3 ModelAndView exMv = null; 4 for (HandlerExceptionResolver handlerExceptionResolver:this.handlerExceptionResolvers){ 5 exMv = handlerExceptionResolver.resolveException(request, response, handler, ex); 6 if (exMv != null){ 7 break; 8 } 9 } 10 if (exMv != null) { 11 if (exMv.isEmpty()){ 12 return null; 13 } 14 //We might still need view name translation for a plain error model.. 15 if (!exMv.hasView()){ 16 exMv.setViewName(getDefaultViewName(request)); 17 } 18 if (logger.isDebugEnabled()){ 19 logger.debug("Handler execution resulted in exception - forwarding to resolved error view:" + exMv, ex); 20 } 21 WebUtils.exposeErrorRequestAttributes(request, ex, getServletName()); 22 return exMv; 23 } 24 throw ex; 25 }
（九）根據檢視跳轉頁面
無論一個系統還是一個站點，最重要的工作都是和使用者進行互動，使用者作業系統後無論下發的命令是否成功都需要給使用者一個反饋，以便於使用者進行下一步的判斷。所以，在邏輯處理的最後一定會涉及一個頁面的跳轉的問題。
1 protected void render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response) throws Exception { 2 // Determine locale for request and apply it to the response 3 Local local = this.localResolver.resolveLocale(request); 4 response.setLocale(locale); 5 6 View view; 7 if (mv.isReference()){ 8 //We need to resolve the view name 9 view = resolveViewName(mv.getViewName(), mv.getModelInternal(), locale, request); 10 if (view == null) { 11 throw new ServletException("Could not resolve view with name'" + mv.getViewName() + "'in servlet with name '" + getServletName() + "'"); 12 } 13 } 14 else { 15 //No need to lookup:the ModelAndView object contains the actual View objects. 16 view = mv.getView(); 17 if (view == null) { 18 throw new ServletException("ModelAndView [" + mv + "] neither contains a view name nor a " + "View object in servlet with name '" + getServletName() + "'" ); 19 } 20 } 21 22 // Delegate to the View object for rendering 23 if (logger.isDebugEnable()){ 24 logger.debug("Rendering view [" + view "] in DispatcherServlet with name '" + getServletName() + "'"); 25 } 26 view.render(mv.getModelInternal(), request, response); 27 }
1. 解析檢視名稱
在上文中我們提到DispatcherServlet會根據ModelAndView選擇合適的檢視來進行渲染，而這一個功能是在resolveViewName函式中完成的。
1 protected View resolveViewName(String viewName, @Nullable Map<String, Object> model, 2 Locale locale, HttpServletRequest request) throws Exception { 3 4 if (this.viewResolvers != null) { 5 for (ViewResolver viewResolver : this.viewResolvers) { 6 View view = viewResolver.resolveViewName(viewName, locale); 7 if (view != null) { 8 return view; 9 } 10 } 11 } 12 return null; 13 }
我們以org.Springframework.web.servlet.view.InternalResourceViewResolver為例分析ViewResolver邏輯的解析過程，其中resolveViewName是在其父類AbstractCachingViewResolver（package org.springframework.web.servlet.view）中完成的。
1 public View resolveViewName(String viewName, Locale locale) throws Exception { 2 if (!isCache()) { 3 //不存在快取的情況下直接建立檢視 4 return createView(viewName, locale); 5 } 6 else { 7 //直接從快取中提取 8 Object cacheKey = getCacheKey(viewName, locale); 9 View view = this.viewAccessCache.get(cacheKey); 10 if (view == null) { 11 synchronized (this.viewCreationCache) { 12 view = this.viewCreationCache.get(cacheKey); 13 if (view == null) { 14 // Ask the subclass to create the View object. 15 view = createView(viewName, locale); 16 if (view == null && this.cacheUnresolved) { 17 view = UNRESOLVED_VIEW; 18 } 19 if (view != null && this.cacheFilter.filter(view, viewName, locale)) { 20 this.viewAccessCache.put(cacheKey, view); 21 this.viewCreationCache.put(cacheKey, view); 22 } 23 } 24 } 25 } 26 else { 27 if (logger.isTraceEnabled()) { 28 logger.trace(formatKey(cacheKey) + "served from cache"); 29 } 30 } 31 return (view != UNRESOLVED_VIEW ? view : null); 32 } 33 }
在父類URLBasedViewResolver中重寫了createView函式。
1 protected View createView(String viewName, Locale locale) throws Exception { 2 // If this resolver is not supposed to handle the given view, 3 // return null to pass on to the next resolver in the chain. 4 //如果當前解析器不支援當前給定的view，如viewName為空等情況 5 if (!canHandle(viewName, locale)) { 6 return null; 7 } 8 9 // Check for special "redirect:" prefix. 10 //處理字首為redirect:xx的情況 11 if (viewName.startsWith(REDIRECT_URL_PREFIX)) { 12 String redirectUrl = viewName.substring(REDIRECT_URL_PREFIX.length()); 13 RedirectView view = new RedirectView(redirectUrl, 14 isRedirectContextRelative(), isRedirectHttp10Compatible()); 15 String[] hosts = getRedirectHosts(); 16 if (hosts != null) { 17 view.setHosts(hosts); 18 } 19 return applyLifecycleMethods(REDIRECT_URL_PREFIX, view); 20 } 21 22 // Check for special "forward:" prefix. 23 //處理字首為forward:xx的情況 24 if (viewName.startsWith(FORWARD_URL_PREFIX)) { 25 String forwardUrl = viewName.substring(FORWARD_URL_PREFIX.length()); 26 InternalResourceView view = new InternalResourceView(forwardUrl); 27 return applyLifecycleMethods(FORWARD_URL_PREFIX, view); 28 } 29 30 // Else fall back to superclass implementation: calling loadView. 31 return super.createView(viewName, locale); 32 }
1 protected AbstractUrlBasedView buildView(String viewName) throws Exception { 2 Class<?> viewClass = getViewClass(); 3 Assert.state(viewClass != null, "No view class"); 4 5 AbstractUrlBasedView view = (AbstractUrlBasedView) BeanUtils.instantiateClass(viewClass); 6 //新增字首和字尾 7 view.setUrl(getPrefix() + viewName + getSuffix()); 8 view.setAttributesMap(getAttributesMap()); 9 10 String contentType = getContentType(); 11 if (contentType != null) { 12 //設定ContenTye 13 view.setContentType(contentType); 14 } 15 16 String requestContextAttribute = getRequestContextAttribute(); 17 if (requestContextAttribute != null) { 18 view.setRequestContextAttribute(requestContextAttribute); 19 } 20 21 Boolean exposePathVariables = getExposePathVariables(); 22 if (exposePathVariables != null) { 23 view.setExposePathVariables(exposePathVariables); 24 } 25 Boolean exposeContextBeansAsAttributes = getExposeContextBeansAsAttributes(); 26 if (exposeContextBeansAsAttributes != null) { 27 view.setExposeContextBeansAsAttributes(exposeContextBeansAsAttributes); 28 } 29 String[] exposedContextBeanNames = getExposedContextBeanNames(); 30 if (exposedContextBeanNames != null) { 31 view.setExposedContextBeanNames(exposedContextBeanNames); 32 } 33 34 return view; 35 }
通讀以上程式碼，我們發現對於InternalResourceViewResolver所提供的解析功能主要考慮到了以下幾個方面的處理：
基於效率的考慮，提供了快取的支援。
提供了對redirect:xx和forward:xx字首的支援。
添加了字首及字尾，並向View中加入了必須的屬性設定。
2. 頁面跳轉
當通過viewName解析到對應的View後，就可以進一步處理跳轉邏輯了。
1 protected void render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response) throws Exception { 2 // Determine locale for request and apply it to the response. 3 Locale locale = 4 (this.localeResolver != null ? this.localeResolver.resolveLocale(request) : request.getLocale()); 5 response.setLocale(locale); 6 7 View view; 8 String viewName = mv.getViewName(); 9 if (viewName != null) { 10 // We need to resolve the view name. 11 view = resolveViewName(viewName, mv.getModelInternal(), locale, request); 12 if (view == null) { 13 throw new ServletException("Could not resolve view with name '" + mv.getViewName() + 14 "' in servlet with name '" + getServletName() + "'"); 15 } 16 } 17 else { 18 // No need to lookup: the ModelAndView object contains the actual View object. 19 view = mv.getView(); 20 if (view == null) { 21 throw new ServletException("ModelAndView [" + mv + "] neither contains a view name nor a " + 22 "View object in servlet with name '" + getServletName() + "'"); 23 } 24 } 25 26 // Delegate to the View object for rendering. 27 if (logger.isTraceEnabled()) { 28 logger.trace("Rendering view [" + view + "] "); 29 } 30 try { 31 if (mv.getStatus() != null) { 32 response.setStatus(mv.getStatus().value()); 33 } 34 view.render(mv.getModelInternal(), request, response); 35 } 36 catch (Exception ex) { 37 if (logger.isDebugEnabled()) { 38 logger.debug("Error rendering view [" + view + "]", ex); 39 } 40 throw ex; 41 } 42 }
本文摘自《Spring原始碼深度解析》SpringMVC，作者：郝佳。本文程式碼基於的Spring版本為5.2.4.BUILD-SNAPSHOT，和原書程式碼部分會略有不同。