DispatcherServlet代碼分析及運行過程

1??? 首先該類有一靜態語塊，用以加載缺省策略。

??? static {

??????????? ClassPathResource resource =new ClassPathResource(DEFAULT_STRATEGIES_PATH,DispatcherServlet.class);

??????????? defaultStrategies = PropertiesLoaderUtils.loadProperties(resource);

}

缺省的策略文件為當前包下的DispatcherServlet.properties，主要包括

LocaleResolver(本地化解析器，AcceptHeaderLocaleResolver)

ThemeResolver(主題解析器，FixedThemeResolver)

HandlerMapping(處理器映射，BeanNameUrlHandlerMapping)

HandlerAdapter(控制適配器，多個)

ViewResolver(視圖解析器，InternalResourceViewResolver)

RequestToViewNameTranslator(請求到視圖名的翻譯器，DefaultRequestToViewNameTranslator)

?

2??? 通過繼承關系調用HttpServletBean類的init()初始化方法

??? 在該方法體內，首先將這個servlet視為一個bean對其包裝并將配置文件中當前servlet下的初始參數值賦倒這個servlet中。然后調用子類(FrameworkServlet)的initServletBean(),而子類通過模板模式再調用其子類（DispatcherServlet）的initFrameworkServlet()方法。在initServletBean()方法中主要代碼片段如下：

??????????? this.webApplicationContext = initWebApplicationContext();

??????????? initFrameworkServlet();

而在initWebApplicationContext()中,它首先是從ServletContext中獲得由ContextLoader類設置進的key為WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE屬性的值（即Spring容器的實例）,然后以實例為parent創建一個新的容器。這也是為什么說一個DispatcherServlet就對應一個WebApplicationContext（每個DispatcherServlet都有各自的上下文）。最后將該WebApplicationContext綁定到到ServletContext上,如果允許發布話。

由此可以看出：

WebApplicationContextUtils.getWebApplicationContext(servletContext)與

servletContext.getAttribute(SERVLET_CONTEXT_PREFIX+ getServletName())之間的主要區別在于：后者包括了該servlet的所有配置信息而前者是全局性的沒有這部分信息

?

3??? 類DispatcherServlet中initFrameworkServlet()方法初始化工作

??? ???initMultipartResolver();

??????? initLocaleResolver();

??????? initThemeResolver();

??????? initHandlerMappings();

??????? initHandlerAdapters();

??????? initHandlerExceptionResolvers();

??????? initRequestToViewNameTranslator();

??????? initViewResolvers();

??? 如果在配置文件沒有設置將缺省的策略文件DispatcherServlet.properties。由此可見，因為DispatcherServlet是單例的，所以設置的信息是全局的也就是所有的解析器不能動態的變化。

?

4??? 當調用類FrameworkServlet中的doGet()/doPost()/doPut()/doDelete()方法時

以上方法均調用相同方法processRequest(request, response)。注意：Spring放棄了對HttpServlet中service()方法的覆蓋而用具體的操作方法取代。

?

5??? 調用類FrameworkServlet中的processRequest(request, response)方法

??? ???try {

??????? doService(request, response);

???? }

??????? finally {

??????? ??? if (isPublishEvents()) {

??????????????? this.webApplicationContext.publishEvent(

??????????????????? new ServletRequestHandledEvent(this,

??????????????????? request.getRequestURI(), request.getRemoteAddr(),

??????????????????? request.getMethod(), getServletConfig().getServletName(),

??????????????????? WebUtils.getSessionId(request), getUsernameForRequest(request),

??????????????????????????????? processingTime, failureCause));

??????????? }

???? }

通過代碼摘要可以看出該類有一個webApplicationContext引用，除了執行doService()這個核心方法外，每次都會發布一個ServletRequestHandledEvent事件如果publishEvents為true,其值可以在web.xml文件中增加添加context參數，或servlet初始化參數(

<init-param>

<param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/application.xml</param-value>

</init-param>)。

DispatcherServlet初始化參數

參數	描述
contextClass	實現WebApplicationContext接口的類，當前的servlet用它來創建上下文。如果這個參數沒有指定，默認使用XmlWebApplicationContext。
contextConfigLocation	傳給上下文實例（由contextClass指定）的字符串，用來指定上下文的位置。這個字符串可以被分成多個字符串（使用逗號作為分隔符）來支持多個上下文（在多上下文的情況下，如果同一個bean被定義兩次，后面一個優先）。
namespace	WebApplicationContext命名空間。默認值是[server-name]-servlet。
publishContext	我們發布的context是作為ServletContext的一個屬性嗎？默認值為true,屬性名為SERVLET_CONTEXT_PREFIX+ getServletName()
publishEvents	在執行每個請求后是否發布一個ServletRequestHandledEvent事件？默認值為true

??? 以上參數的初始加載是在HttpServletBean類的init()中，而所有DispatcherServlet的解析器是在initFrameworkServlet()方法中。

由此可見，DispatcherServlet的初始參數加載來源可分為兩部分，

5.1?? 在web.xml文件對于該servlet配置的<init-param>初始參數中

5.2?? 通過Spring的IOC容器實例化后，通過該類的初始化方法，將容器內的實例一一引用

?

6??? 調用類DispatcherServlet中的doService(request, response)方法

暴露在request屬性中DispatchServlet的一些特性，并且調用doDispatch(request, response)方法執行真正的分發動作。

???????? request.setAttribute(WEB_APPLICATION_CONTEXT_ATTRIBUTE, getWebApplicationContext());

request.setAttribute(LOCALE_RESOLVER_ATTRIBUTE,this.localeResolver);

??? request.setAttribute(THEME_RESOLVER_ATTRIBUTE,this.themeResolver);

??? request.setAttribute(THEME_SOURCE_ATTRIBUTE, getThemeSource());

??? try {

??????? doDispatch(request, response);

??? }

?

7??? 調用類DispatcherServlet中的doDispatch(request, response)方法

7.1??? 在區域上下文持有者（LocaleContextHolder）中當前線程下的值做一次替換。暴露當前localeResolver與request中的Locale

??????? LocaleContext previousLocaleContext = LocaleContextHolder.getLocaleContext();

??????? LocaleContextHolder.setLocaleContext(new LocaleContext() {

??????????? public Locale getLocale() {

??????????????? returnlocaleResolver.resolveLocale(request);

??????????? }});

由源碼可見，將當前線程下的LocaleContext取出，再從當前區域解析器(LocaleResolver)中得到Locale前創建為LocaleContext后再賦到LocaleContextHolder中

?

7.2?? 在請求上下文持有者（RequestContextHolder）中當前線程下的值做一次替換。暴露當前RequestAttributes到當前線程中

RequestAttributes previousRequestAttributes = RequestContextHolder.getRequestAttributes();

ServletRequestAttributes requestAttributes =new ServletRequestAttributes(request);

RequestContextHolder.setRequestAttributes(requestAttributes);

??? 在此注意，ServletRequestAttributes類只能獲得session或request有屬性，而無法獲得request的參數(parameter)

7.3?? 轉換request為MultipartHttpServletRequest類型的實例，如果不是就簡單的返回

??? ??? protected HttpServletRequest checkMultipart(HttpServletRequest request) {

if (this.multipartResolver != null &&this.multipartResolver.isMultipart(request)) {

??????????? if (requestinstanceof MultipartHttpServletRequest) {

??????????? }

??????????? else

??????????????? returnthis.multipartResolver.resolveMultipart(request);

??????????? }

??????? return request;

??? }

由代碼可以看出，如果要支持文件上傳要有兩個前提

??? 1.在應用的配置文件中添加MultipartResolver(分段文件解析器)，目前Spring支持兩種上傳文件的開源項目Commons FileUpload(http://jakarta.apache.org/commons/fileupload)和COS FileUpload(http://www.servlets.com/cos)

<bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver"/> <bean id="multipartResolver" class="org.springframework.web.multipart.cos.CosMultipartResolver"/>

注意：Bean的id必須為’ multipartResolver’, DispatcherServlet中的成員屬性this.multipartResolver是在初始化時與容器中的實例引用在一起的。

??? 2. 通過multipartResolver.isMultipart(request)判斷request的ContextType是否是’ multipart/form-data’。所以表單格式應為

??? ????<form method="post" action="upload.form" enctype="multipart/form-data"> ??????????? <input type="file" name="file"/><input type="submit"/> ??????? 這個元素的名字（“file”）和服務器端處理這個表單的bean（在下面將會提到）中類型為byte[]的屬性名相同。在這個表單里我們也聲明了編碼參數(enctype="multipart/form-data")以便讓瀏覽器知道如何對這個文件上傳表單進行編碼

最后由相應的MultipartResolver(分段文件解析器)將request封裝為與解析器對應的MultipartHttpServletRequest實例并返回

??????

7.4?? 根據當前請求URL為其找到指定的處理器(handler)與欄截器(HandlerInterceptor)，并將它們封裝為HandlerExecutionChain實例。

HandlerExecutionChain mappedHandler = getHandler(processedRequest,false);

在此過程中分為如下幾個步驟

1.? 循環所有已注冊的HandlerMapping(處理器映射),對于不同的處理器映射對其映射的處理方式不同。BeanNameUrlHandlerMapping只要在配置文件中bean元素的name屬性以/開頭它都認為是一個映射如<bean name=”/editaccount”>。而SimpleUrlHandlerMapping只關注自身定義的<property name=”mappings”>下的那些映射，而且支持Ant風格的定義

2.? 通過客戶請求的URL與處理器映映射的鍵值做匹配(也可以使用Ant風格匹配,參見AbstractUrlHandlerMapping.lookupHandler()方法),如果滿足匹配條件，就返回與其對應的處理器(Handler)，一般情況下，都是Controller(控制器)接口子孫類的實例。

3.? 根據匹配上的處理器映射取得攔截器數組，并與找到的處理器一同作為構建函數的參數創建出HandlerExecutionChain實例

?

7.5?? 執行所有攔截器的前置方法

HandlerInterceptor接口提供了如下三個方法：

1.? preHandle(…)前置方法，在處理器執行前調用，當返回false時，DispatcherServlet認為該攔截器已經處理完了請求，而不再繼續執行執行鏈中的其它攔截器和處理器

2.? postHandle(…)后置方法，在處理器執行后調用

3.? afterCompletion(…)完成前置方法，在整個請求完后調用。注意如果第n個攔截器的preHandle方法返回的是false則只會調用第n個攔截器之前所有該方法，而n++不會被調用

另：Spring還提供了一個adapter類HandlerInterceptorAdapter讓用戶更方便的擴展HandlerInterceptor接口

?

7.6?? 獲得與當前處理器相匹配的HandlerAdapter(處理器適配器)，

??? protected HandlerAdaptergetHandlerAdapter(Object handler) throws ServletException {

??????? Iterator it = this.handlerAdapters.iterator();

??????? while (it.hasNext()) {

??????????? HandlerAdapter ha = (HandlerAdapter) it.next();

??????????? if (ha.supports(handler)) {

??????????????? return ha;

??????????? }

??? }

循環所有已注冊的HandlerAdapter(處理器適配器),如果該適配器支持ha.supports(handler)當前處理器,就返回。由此可見，Spring通過HandlerAdapter使處理器解耦，實處理器(Handler)不只是僅僅局限于控制器(Controller)這一種形式。目前Spring可以支持，Servlet、HttpRequestHandler、ThrowawayController、Controller,從這一點上看Spring已為客戶留出了很大空間作為擴展的口子。

?

7.7?? 根據處理器適配器調用處理器的指定方法,執行真正的處理操作。如Controller(控制器)接口調用handleRequest()、ThrowawayController接口調用execute()、Servlet接口調用service()….但無論調用那種自理器，HandlerAdapter中的handle()方法都要求返回ModelAndView的一個實例

mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

在Spring中最常用的處理器是以Controller接口下的所有子孫類控制器,繼承結構如圖

在這些控制器中又以SimpleFormController控制器最為常用，下圖為該類的完整執行過程

7.8?? 執行所有攔截器的后置方法

7.9?? 根據處理器(Handle)返回的ModelAndView對象，找到或創建View對象，并調用View對象的render()方法

render(mv, processedRequest, response)

在此有幾個關鍵性的概念：

ModelAndView:它是模形(Model,實際上只是一個Map,最終會將模形存放到request的屬性中，以Map的key為request屬性的鍵，Map的value為值)與視圖(View)的持有者。而View又提供了兩種形態，即以View接口為祖先的實例對象，以字符串的視圖的名字。該類通過isReference()方法判斷是一個字符串的引用還是一個真正的View對象。注意：該類有些奇怪：它將有狀態的Model與無狀態的View合并到一個類中，這就導致每次請求都到對該類型的實例進行創建，而不無緩存。View對象Spring提供了緩存功能。

ViewResolver(視圖解析器)：主要提供的功能是從視圖名稱到實際視圖的映射。也就是說只有ModelAndView的isReference()返回true時，才會對視圖的名字做解析工作。這使視圖解析與真正的視圖相分離，這樣我們就可以通過不同的方式配置視圖，如可以采用properties、xml或是提供URI的前、后綴等形式配置視圖。但要注意視圖解析器與視圖之間還是緊密的關系，Sping在此沒實現全部的完全解耦

ViewResolver	描述
AbstractCachingViewResolver	抽象視圖解析器實現了對視圖的緩存。在視圖被投入使用之前，通常需要進行一些準備工作。從它繼承的視圖解析器將對要解析的視圖進行緩存。
InternalResourceViewResolver	作為UrlBasedViewResolver的子類，它支持InternalResourceView（對Servlet和JSP的包裝），以及其子類JstlView和TilesView。通過setViewClass方法，可以指定用于該解析器生成視圖使用的視圖類。
UrlBasedViewResolver	UrlBasedViewResolver實現ViewResolver，將視圖名直接解析成對應的URL，不需要顯式的映射定義。如果你的視圖名和視圖資源的名字是一致的，就可使用該解析器，而無需進行映射。
ResourceBundleViewResolver	ResourceBundleViewResolver實現ViewResolver，在一個ResourceBundle中尋找所需bean的定義。這個bundle通常定義在一個位于classpath中的屬性文件中。默認的屬性文件是views.properties。
XmlViewResolver	XmlViewResolver實現ViewResolver，支持XML格式的配置文件。該配置文件必須采用與Spring XML Bean Factory相同的DTD。默認的配置文件是/WEB-INF/views.xml。
VelocityViewResolver /FreeMarkerViewResolver	作為UrlBasedViewResolver的子類，它能支持VelocityView（對Velocity模版的包裝）和FreeMarkerView以及它們的子類。

View(視圖)：處理請求的準備工作， 并將該請求提交給某種具體的視圖技術。

如，InternalResourceView會通過RequestDispatcher類調用include()或forward()方法

? ?RedirectView會通過HttpServletResponse類調用sendRedirect()方法

AbstractExcelView會產生一個輸出流

區別：

1、forward與include區別在于forward本意是讓第一個頁面處理request，第二個頁面處理response.調用第二個頁面后，程序還會返回第一個頁面繼續執行，但是此時再使用response輸出已經沒有作用了；include服務器端的動態加載，執行完第二個頁面的程序后可以回到第一個頁面繼續輸出，即將第二個頁面的輸出拉到第一個頁面中。

2、forward與include共享Request范圍內的對象,而redirect則不行，即：如果一個javabean被聲明為request范圍的話，則被forward到的資源也可以訪問這個javabean,而redriect則不行。

3、forward與include基本上都是轉發到context內部的資源，而redirect可以重定向到外部的資源,如： req.sendRedriect("http://www.mocuai.com");

總結

以上是生活随笔為你收集整理的DispatcherServlet代码分析及运行过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。