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，和原書代碼部分會略有不同。
拓展閱讀：
Spring框架之beans源碼完全解析
Spring框架之AOP源碼完全解析
Spring框架之jdbc源碼完全解析
Spring源碼深度解析之數據庫連接JDBC
Spring框架之jms源碼完全解析
Spring框架之事務源碼完全解析
Spring源碼深度解析之事務
Spring源碼深度解析之Spring MVC
Spring框架之websocket源碼完全解析
WebSocket協議中文版
Spring框架之spring-web web源碼完全解析
Spring框架之spring-web http源碼完全解析
Spring框架之spring-webmvc源碼完全解析