Spring框架之spring-webmvc源碼徹底解析

Spring框架之spring-webmvc源碼徹底解析

       Spring框架提供了構建Web應用程序的全功能MVC模塊。Spring MVC分離了控制器、模型對象、分派器以及處理程序對象的角色，支持多種視圖技術，如JSP、Velocity、Tiles、iText和POI。

       Spring Web模型視圖控制器（MVC）框架是基於Servlet功能實現的。經過實現Servlet接口的DispatcherServlet來封裝其核心功能實現，經過將請求分派給處理程序，同時具備可配置的處理程序映射，視圖解析，區域設置，本地化和主題解析，而且支持上傳文件。

       Spring MVC框架功能主要三點：一、將Web頁面的請求傳給服務器；二、根據不一樣的請求處理不一樣的邏輯單元；三、返回處理結果數據並跳轉到響應的頁面。

       本文基於version爲5.2.4.BUILD-SNAPSHOT的Spring源碼，對Spring-webmvc十一個子模塊中包含的接口和類進行分析。

       介紹spring-webmvc接口和類前先介紹幾個概念：

       （1）spring-web和spring-webmvc關係：

       spring-web 提供了核心 HTTP 集成，包括一些便捷的 servlet 過濾器， Spring HTTP 調用，用於集成其它 web 框架的基礎結構以及技術（Hessian，Burlap）。

       spring-webmvc 是 Spring MVC 的一個實現。spring-webmvc 依賴於 spring-web，這樣包含它就會間接地添加 spring-web，沒必要顯示添加 spring-web。

       （2）MVC（Model-View-Controller）三元組的概念

       Model（模型）：數據模型，提供要展現的數據，所以包含數據和行爲，能夠認爲是領域模型或JavaBean組件（包含數據和行爲），不過如今通常都分離開來：Value Object（數據） 和 服務層（行爲）。也就是模型提供了模型數據查詢和模型數據的狀態更新等功能，包括數據和業務。

       View（視圖）：負責進行模型的展現，通常就是咱們見到的用戶界面，客戶想看到的東西。

       Controller（控制器）：接收用戶請求，委託給模型進行處理（狀態改變），處理完畢後把返回的模型數據返回給視圖，由視圖負責展現。 也就是說控制器作了調度員的工做。

       在Web MVC模式下，模型沒法主動推數據給視圖，若是用戶想要視圖更新，須要再發送一次請求（即請求-響應模型）。

       （3）Servlet簡介

       Servlet就是一個Java接口，只有5個方法的接口，Servlet接口中的5大方法：

       一、void init(ServletConfig)：初始化servlet，它是servlet的生命週期方法，由web容器調用一次。

       二、void service(ServletRequest, ServletResponse)：爲傳入的請求提供響應，它由容器的每一個請求調用。

       三、void destroy()：僅被調用一次，代表servlet正在被銷燬。

       四、ServletConfig getServletConfig()：返回ServletConfig對象。

       五、String getServletInfo()：返回有關servlet的信息，如做者、版權、版本等。

       Servlet接口定義的是一套處理網絡請求的規範，全部實現servlet的類，都要實現它的5個方法。其中最主要的是兩個生命週期方法init()和destroy()，還有一個處理請求service()。也就是說全部實現servlet接口的類，或者說，全部想要處理網絡請求的類，都要回答三個問題：初始化要作什麼，銷燬時要作什麼，接受到請求時要作什麼。

       Spring主要經過DispatcherServlet實現了Servlet。init()接口在其父類HttpServletBean中實現。service()接口在其父類FrameworkServlet中實現（回調了DispatcherServlet的doService()方法）。destroy()接口在父類FrameworkServlet中實現。

       實現了servlet的類還不能處理請求。請求是經過servlet容器來到servlet，好比咱們最經常使用的tomcat。因此須要將servlet部署到一個容器中，不然servlet根本不會起做用。容器（如tomcat）纔是與客戶端直接打交道的，它監聽了端口，請求過來後，根據url等信息，肯定要將請求交給哪一個servlet去處理，而後調用那個servlet的service方法，service方法返回一個response對象，容器再把這個response返回給客戶端。

 

1、web/servlet/

1.1  DispatcherServlet

       在整個 Spring MVC 框架中，DispatcherServlet（前置控制器） 處於核心位置，負責協調和組織不一樣組件完成請求處理並返回響應工做。配置在web.xml文件中的，攔截匹配的請求，將攔截下來的請求，依據相應的規則分發到目標Controller來處理，主要用於進行調度，控制流程。功能主要有：

       一、文件上傳解析，若是請求類型是multipart將經過MultipartResolver進行文件上傳解析；

       二、經過HandlerMapping，將請求映射處處理器（返回一個HandlerExecutionChain，它包括一個處理器、多個HandlerInterceptor攔截器）；

       三、經過HandlerAdapter支持多種類型的處理器(HandlerExecutionChain中的處理器)；

       四、經過ViewResolver解析邏輯視圖名到具體視圖實現；

       五、本地化解析；

       六、渲染具體的視圖等；

       七、若是執行過程當中遇到異常將交給HandlerExceptionResolver來解析。

 

       DispatcherServlet默認使用WebApplicationContext做爲上下文，上下文中有一些特殊的Bean：

       一、Controller：處理器/頁面控制器，實現的是MVC中C 那個組成部分，但控制邏輯轉移到前端控制器了，用於對請求進行處理；

       二、HandlerMapping：請求處處理器的映射，若是映射成功返回一個HandlerExecutionChain對象（包含一個Handler處理器（頁面控制器）對象、多個HandlerInterceptor攔截器）對象，如BeanNameUrlHandlerMapping將URL與Bean名字映射，映射成功的Bean就是此處的處理器；

       三、HandlerAdapter：HandlerAdapter將會把處理器包裝爲適配器，從而支持多種類型的處理器，即適配器設計模式的應用，從而很容易支持不少類型的處理器；如SimpleControllerHandlerAdapter將對實現了Controller接口的Bean進行適配，而且掉處理器的handleRequest方法進行功能處理；

       四、ViewResolver：ViewResolver將把邏輯視圖名解析爲對應的視圖，經過這種策略模式，很容易更換其餘視圖技術；如InternalResourceViewResolver將邏輯視圖名映射爲jsp視圖；

       五、LocalResover：本地化解析，由於Spring支持國際化，所以LocalResover解析客戶端的Locale信息從而方便進行國際化；

       六、ThemeResovler：主題解析，解析你的web應用所使用的主題，以提供個性化的佈局。經過它來實現一個頁面多套風格，即常見的相似於軟件皮膚效果；

       七、MultipartResolver：文件上傳解析，用於支持文件上傳；

       八、HandlerExceptionResolver：處理器異常解析，能夠將異常映射到相應的統一錯誤界面，從而顯示用戶友好的界面（而不是給用戶看到具體的錯誤信息）；

       九、RequestToViewNameTranslator：當處理器沒有返回邏輯視圖名等相關信息時，自動將請求URL映射爲邏輯視圖名；

       十、FlashMapManager：用於管理FlashMap的策略接口，FlashMap用於存儲一個請求的輸出，當進入另外一個請求時做爲該請求的輸入，一般用於重定向場景。

 

       DispatcherServlet 處理請求的流程：

       一、Tomcat 啓動，對 DispatcherServlet 進行實例化，而後調用它的 init() 方法進行初始化，在這個初始化過程當中完成了：對 web.xml 中初始化參數的加載、創建 WebApplicationContext (SpringMVC的IOC容器)、進行組件的初始化；

       二、客戶端發出請求，由 Tomcat 接收到這個請求，若是匹配 DispatcherServlet 在 web.xml 中配置的映射路徑，Tomcat 就將請求轉交給 DispatcherServlet 處理；

       三、DispatcherServlet 從容器中取出全部 HandlerMapping 實例（每一個實例對應一個 HandlerMapping 接口的實現類）並遍歷，每一個 HandlerMapping 會根據請求信息，經過本身實現類中的方式去找處處理該請求的 Handler（執行程序，如Controller中的方法），而且將這個 Handler 與一堆 HandlerInterceptor（攔截器）封裝成一個 HandlerExecutionChain 對象，一旦有一個 HandlerMapping 能夠找到 Handler 則退出循環；

       四、DispatcherServlet 取出 HandlerAdapter 組件，根據已經找到的 Handler，再從全部 HandlerAdapter 中找到能夠處理該 Handler 的 HandlerAdapter 對象；

       五、執行 HandlerExecutionChain 中全部攔截器的 preHandler() 方法，而後再利用 HandlerAdapter 執行 Handler ，執行完成獲得 ModelAndView，再依次調用攔截器的 postHandler() 方法；

       六、利用 ViewResolver 將 ModelAndView 或是 Exception（可解析成 ModelAndView）解析成 View，而後 View 會調用 render() 方法再根據 ModelAndView 中的數據渲染出頁面；

       七、最後再依次調用攔截器的 afterCompletion() 方法，這一次請求就結束了。

1.2  FrameworkServlet

       FrameworkServlet是Spring web框架的基本servlet實現類，經過JavaBean的方式集成了Application context，全部新實現的servlet最好都繼承於該類。該類提供了HttpServlet的全部接口實現，自帶了一個web容器，它實現了WebApplicationContextAware接口，因此能根據指定的容器配置文件，來初始化本身管理的容器。

       FrameworkServlet提供兩個功能：

       一、爲每一個servlet管理一個WebApplicationContext實例（即每一個servlet會本身的一個web容器），每一個servlet都有本身的配置空間，相互獨立。

       二、對每個請求，不管是否成功處理，都會在每一個請求上發佈事件。

1.3  HttpServletBean

       dispatcherServlet 繼承FrameworkServlet 繼承 HttpServletBean 繼承 HttpServlet。HttpServletBean繼承HttpServlet，所以在Web容器啓動時將調用它的init方法，該初始化方法的主要做用：

       將Servlet初始化參數（init-param）設置到該組件上（如contextAttribute、contextClass、namespace、contextConfigLocation），經過BeanWrapper簡化設值過程，方便後續使用；

       提供給子類初始化擴展點，initServletBean()，該方法由FrameworkServlet覆蓋。

1.4  FlashMap

       FlashMap繼承自HashMap，一個FlashMap保存着一套Redirect轉發所傳遞的參數。實際的Session中保存的FlashMap是List<FlashMap>類型，也就是說一個Session能夠保存多個FlashMap。

1.5  FlashMapManager

       FlashMapManger用於管理FlashMap，FlashMap能夠從Manger獲取。

1.6  HandlerAdapter

       HandlerAdapter處理適配器，就是適配不一樣的處理器，將他們封裝起來調用同一個接口方法，這樣DispatcherServlet就只須要調用接口方法，而不須要在DispatcherServlet判斷調用哪個具體的HandlerAdapter的實現類了。

       HandlerAdapter處理流程：

       一、DispatcherServlet會根據配置文件信息註冊HandlerAdapter，若是在配置文件中沒有配置，那麼DispatcherServlet會獲取HandlerAdapter的默認配置，若是是讀取默認配置的話，DispatcherServlet會讀取DispatcherServlet.properties文件，該文件中配置了三種HandlerAdapter：HttpRequestHandlerAdapter，SimpleControllerHandlerAdapter和AnnotationMethodHandlerAdapter。DispatcherServlet會將這三個HandlerAdapter對象存儲到它的handlerAdapters這個集合屬性中，這樣就完成了HandlerAdapter的註冊。

       二、DispatcherServlet會根據handlerMapping傳過來的controller與已經註冊好了的HandlerAdapter進行匹配，看哪種HandlerAdapter支持該controller類型，若是找到了其中一種HandlerAdapter是支持傳過來的controller類型，那麼該HandlerAdapter會調用本身的handle方法，handle方法運用java的反射機制執行controller的具體方法來得到ModelAndView，例如SimpleControllerHandlerAdapter是支持實現了controller接口的控制器，若是本身寫的控制器實現了controller接口，那麼SimpleControllerHandlerAdapter就會去執行本身寫控制器中的具體方法來完成請求。

       幾種適配器對應的處理器以及這些處理器的做用：

       一、AnnotationMethodHandlerAdapter主要是適配註解類處理器，註解類處理器就是咱們常用的@Controller的這類處理器。

       二、HttpRequestHandlerAdapter主要是適配靜態資源處理器，靜態資源處理器就是實現了HttpRequestHandler接口的處理器，這類處理器的做用是處理經過SpringMVC來訪問的靜態資源的請求。

       三、SimpleControllerHandlerAdapter是Controller處理適配器，適配實現了Controller接口或Controller接口子類的處理器，好比咱們常常本身寫的Controller來繼承MultiActionController，那麼本身寫的這些Controller就會由SimpleControllerHandlerAdapter來適配。

       四、SimpleServletHandlerAdapter是Servlet處理適配器，適配實現了Servlet接口或Servlet的子類的處理器，咱們不只能夠在web.xml裏面配置Servlet，其實也能夠用SpringMVC來配置Servlet，不過這個適配器不多用到，並且SpringMVC默認的適配器沒有他，默認的是前面的三種。

1.7  HandlerExecutionChain

       HandlerExecutionChain類（處理器執行鏈）：由一個handler（處理器對象）和若干的HandlerInterceptor（攔截器）構成。就是對handle進行包裝，將攔截器和handle組合起來執行。HandlerExecutionChain只能經過HanderMapping接口中的getHandler方法（getHandler方法是HandlerMapping接口中的惟一方法，此方法能夠利用用戶請求request中的信息來生成HandlerExecutionChain對象）來得到。

       這個類中有幾個主要的方法：

       一、applyPreHandle()，按照列表中interceptor的順序來執行它們的preHandle方法，直到有一個返回false。返回false後這個方法就會調用triggerAfterCompletion方法，此時this.interceptorIndex指向上一個返回true的interceptor的位置，因此它會按逆序執行全部返回true的interceptor的afterCompletion方法。

       二、applyPostHandle()，就是按照逆序執行全部interceptor的postHandle方法。

       三、triggerAfterCompletion()也是從最後一次preHandle成功的interceptor處逆序執行afterCompletion方法。

       SpringMVC的流程。

       一、 用戶發送請求，通過前端控制器Dispacherservlet（Controller的核心）將url交給處理器映射器HandlerMapping處理。

       二、 處理器映射器HandlerMapping處理url，返回HandlerExecutionChain（可能包含攔截器，必定包含自定義的Controller(handler)）。

       三、 前端控制器將Controller交給處理器適配器HandlerAdapter處理，處理完成後，返回MV對象（ModelAndView）。

       四、 前端控制器將MV交給視圖解析器處理ViewResolver，處理的過程：將MV拆分紅Model和view兩個對象，而且將model渲染到view視圖上，而且將view返回給前端控制器。

       五、 最後，前端控制器將視圖響應給用戶。

1.8  HandlerInterceptor

       HandlerInterceptor是一個Spring Web接口，實現該接口的組件能夠攔截客戶端請求並提供自定義處理邏輯。該接口定義了三種核心方法：

       一、boolean preHandle()

       此方法攔截請求處理的執行。在控制器處理請求並返回布爾值（用於肯定下一步處理）以前將其觸發。若是方法返回true，則請求轉處處理程序。若是返回錯誤，則請求被中斷。該方法可用於驗證先決條件，例如令牌。

       二、void postHandle()

       在 Spring控制器處理程序以後，但在呈現視圖以前（若是您構建的是遵循MVC架構的應用程序），將觸發此方法。所以，在這種狀況下，您能夠修改ModelAndView將要顯示的內容並附加其餘數據。好比，當咱們想向用戶顯示用於渲染頁面的時間時。

       三、void afterCompletion()

       最後，這裏的第三個方法afterCompletion()是在處理程序處理完並向用戶呈現視圖以後調用。在處理程序執行的任何狀況下都將調用此方法，但前提是相應的preHandle()方法返回true。咱們可使用這種方法來記錄處理程序處理的結果。

       運行流程總結以下：

       一、攔截器執行順序是按照Spring配置文件中定義的順序而定的。

       二、會先按照順序執行全部攔截器的preHandle方法，一直遇到return false爲止，好比第二個preHandle方法是return false，則第三個以及之後全部攔截器都不會執行。若都是return true，則按順序加載完preHandle方法。

       三、而後執行主方法（本身的controller接口），若中間拋出異常，則跟return false效果一致，不會繼續執行postHandle，只會倒序執行afterCompletion方法。

       四、在主方法執行完業務邏輯（頁面還未渲染數據）時，按倒序執行postHandle方法。若第三個攔截器的preHandle方法return false，則會執行第二個和第一個的postHandle方法和afterCompletion（postHandle都執行完纔會執行這個，也就是頁面渲染完數據後，執行after進行清理工做）方法。（postHandle和afterCompletion都是倒序執行）

       HandlerInterceptor攔截器常見的用途有：

       一、日誌記錄：記錄請求信息的日誌，以便進行信息監控、信息統計、計算PV（Page View）等。

       二、權限檢查：如登陸檢測，進入處理器檢測檢測是否登陸，若是沒有直接返回到登陸頁面；

       三、性能監控：有時候系統在某段時間莫名其妙的慢，能夠經過攔截器在進入處理器以前記錄開始時間，在處理完後記錄結束時間，從而獲得該請求的處理時間（若是有反向代理，如apache能夠自動記錄）；

       四、通用行爲：讀取cookie獲得用戶信息並將用戶對象放入請求，從而方便後續流程使用，還有如提取Locale、Theme信息等，只要是多個處理器都須要的便可使用攔截器實現。

       本質也是AOP（面向切面編程），也就是說符合橫切關注點的全部功能均可以放入攔截器實現。

1.9  AsyncHandlerInterceptor

       繼承自HandlerInterceptor接口，新增了一個afterConcurrentHandlingStarted()方法，這個方法會在Controller方法異步執行時開始執行（HandlerInterceptor的postHandle方法則是須要等到Controller的異步執行完才能執行） 。

       當開始處理一個異步請求的時候，DispatcherServlet退出，不會去調用postHandle和afterCompletion（這兩個函數主要用於同步請求），由於請求處理的結果（如ModelAndView）可能從另外一個線程中產生，可能還沒準備完畢。在這種狀況下，會調用afterConcurrentHandlingStarted方法，從而去執行一些任務，好比：將線程釋放到Servlet容器以前，清除線程綁定的屬性等。

       當異步處理完成時，請求會被分發到容器中作進一步的處理。這個時候，DispatcherServlet就能夠調用preHandle ， postHandle和afterCompletion 方法了。攔截器經過檢查javax.servlet.ServletRequest的javax.servlet.DispatcherType屬性值是」REQUEST」仍是」ASYNC」來區分是「原始的請求」仍是「異步處理完成後分發的請求」。

       須要注意的是，當網絡錯誤引起的異步請求超時或者完成，HandlerInterceptor的實現類都要作一些處理工做。由於這種狀況下，Servlet容器不會調度，postHandle和afterCompletion方法天然也不會被調用。相反，能夠經過WebAsyncManager中的registerCallbackInterceptor和registerDeferredResultInterceptor方法註冊攔截器來跟蹤異步請求。對於每個異步請求，在其開始被處理以前，這項工做就能夠經過preHandle提早進行。

1.10  HandlerMapping

       HandlerMapping接口的實現對象定義了web請求映射和處理器（Handler）之間的映射。根據request找到相應的Handler處理器，並將 Handler與一堆 HandlerInterceptor（攔截器）封裝到 HandlerExecutionChain 對象中。

       在 HandlerMapping 接口的內部只有一個方法：HandlerExecutionChain getHandler(HttpServletRequest request);。HandlerMapping 是由 DispatcherServlet 調用，DispatcherServlet 會從容器中取出全部 HandlerMapping 實例並遍歷，讓 HandlerMapping 實例根據本身實現類的方式去嘗試查找 Handler。

       HandlerMapping的使用主要分爲兩步：註冊和查找。

       註冊是根據配置文件中的配置將一個字符串和一個Controller類以<key,value>的形式存入到Map中，這個key就是對應的url中的某個字段。

       查找就是HandlerMapping根據url中的的某個字段，在Map中以這個字段爲key值對應的Controller類，並將Controller類封裝成一個HandlerExecutionChain對象，HandlerExecutionChain中除了有Controller對象外，還有一組攔截器。

       HandlerMapping有三種比較常見

       一、BeanNameUrlHandlerMapping 根據bean標籤的名稱找到對應的Controller類

       二、SimpleUrlHandlerMapping 根據bean的id查找對應的Controller類。

       三、ControllerClassNameHandlerMapping 根據controller類的名字找到對應的Controller。

1.11  RequestToViewNameTranslator

       RequestToViewNameTranslator 組件，視圖名稱轉換器，用於解析出請求的默認視圖名。就是說當 ModelAndView 對象不爲 null，可是它的 View 對象爲 null，則須要經過 RequestToViewNameTranslator 組件根據請求解析出一個默認的視圖名稱。

       RequestToViewNameTranslator就是一個請求解析器，他的每一個實現有各自的一個解析請求的算法（SpringMVC提供一個DefaultRequestToViewNameTranslator實現類），通過這個算法，從請求的url中得到一個字符串，將這個字符串做爲要顯示的jsp的名字，去jsp文件目錄中查找，找到就顯示，找不到才最終顯示404。

1.12  View

       視圖基礎接口，它的各類實現類是無狀態的，所以是線程安全的。 該接口定義了兩個方法：　getContentType()獲取當前view的ContentType()，同http請求中的ContenType()是同樣的做用。

render()這個是爲視圖綁定Request，Response和Model的方法。

1.13  SmartView

       繼承自View，提供了一些額外的信息，好比是否執行重定向。

1.14  ModelAndView

       使用ModelAndView類用來存儲處理完後的結果數據，以及顯示該數據的視圖。從名字上看ModelAndView中的Model表明模型，View表明視圖，這個名字就很好地解釋了該類的做用。業務處理器調用模型層處理完用戶請求後，把結果數據存儲在該類的model屬性中，把要返回的視圖信息存儲在該類的view屬性中，而後讓該ModelAndView返回該Spring MVC框架。框架經過調用配置文件中定義的視圖解析器，對該對象進行解析，最後把結果數據顯示在指定的頁面上。

       具體做用：

       一、返回指定頁面：ModelAndView構造方法能夠指定返回的頁面名稱，也能夠經過setViewName()方法跳轉到指定的頁面 。

       二、返回所需數值：使用addObject()設置須要返回的值，addObject()有幾個不一樣參數的方法，能夠默認和指定返回對象的名字。

1.15  ViewResolver

       用來將String類型的視圖名和Locale解析爲View類型的視圖。該接口只有1個方法，經過視圖名稱viewName和Locale對象獲得View接口實現類。

1.16  ThemeResolver

       主題解析，這種相似於咱們手機更換主題，不一樣的UI，css等。

1.17  HandlerExceptionResolver

       在Spring MVC中，全部用於處理在請求處理過程當中拋出的異常，都要實現HandlerExceptionResolver接口。HandlerExceptionResolver是Spring MVC提供的很是好的通用異常處理工具，不過須要注意的是，它只能處理請求過程當中拋出的異常，異常處理自己所拋出的異常和視圖解析過程當中拋出的異常它是不能處理的。

       一個基於Spring MVC的Web應用程序中，能夠存在多個實現了HandlerExceptionResolver的異常處理類，他們的執行順序，由其order屬性決定， order值越小，越是優先執行， 在執行到第一個返回不是null的ModelAndView的Resolver時，再也不執行後續的還沒有執行的Resolver的異常處理方法。

1.18  LocaleResolver

       LocaleResolver主要做用在於從request中解析出Locale。Locale表示用戶的區域，好比zh-cn，對不一樣的區域的用戶，顯示不一樣的結果，好比針對美國用戶能夠提供一個視圖，而針對中國用戶則能夠提供另外一個視圖，這就是i18n。

1.19  LocaleContextResolver

       繼承自LocalResolver，添加對rich locale context的支持（可能包括區域設置和時區信息）。

1.20  ModelAndViewDefiningException

       繼承自ServletException，處理器處理任什麼時候候均可能拋出該異常。

1.21  NoHandlerFoundException

       默認狀況下，當DispatcherServlet爲一個請求找不到一個匹配的處理器的時候會發送一個404響應報文。可是當其屬性值throwExceptionIfNoHandlerFound設置爲true的時候，該異常拋出，可能會被一個HandlerExceptionResolver進行處理。

 

2、web/servlet/config

2.1  AnnotationDrivenBeanDefinitionParser 

       負責解析xml的<tx:annotation-driven>元素。

2.2  CorsBeanDefinitionParser

       實現BeanDefinitionParser 接口，包括一個parse方法。從xml文件中讀取跨域配置信息，對 CorsConfiguration進行初始化，最後在Spring中註冊。

2.3  DefaultServletHandlerBeanDefinitionParser

       實現BeanDefinitionParser 接口，解析default-servlet-handler元素，註冊DefaultServletHttpRequestHandler。

2.4  FreeMarkerConfigurerBeanDefinitionParser

       mvc:freemarker-configurer 標籤的解析器，同時註冊FreeMarkerConfigurer bean。

2.5  GroovyMarkupConfigurerBeanDefinitionParser

       解析mvc:groovy-configurer標籤，註冊GroovyConfigurer bean。

2.6  InterceptorsBeanDefinitionParser

       解析mvc:interceptors元素，並註冊成MappedInterceptorsDefinition集合。

2.7  MvcNamespaceHandler

       解析mvc命名空間。

2.8  MvcNamespaceUtils

       MVC 命名空間中的BeanDefinitionParsers使用到的功能函數。

2.9  ResourcesBeanDefinitionParser

       繼承自BeanDefinitionParser，解析resources元素，爲映射資源請求請求註冊ResourceHttpRequestHandler、SimpleUrlHandlerMapping和HttpRequestHandlerAdapter。同時也會使用ResourceResolvers和ResourceTransformers建立一個資源處理鏈。

2.10  ScriptTemplateConfigurerBeanDefinitionParser

       解析mvc:script-template-configurer元素，註冊一個ScriptTemplateConfigurer bean。

2.11  TilesConfigurerBeanDefinitionParser

       解析mvc: tiles-configurer元素，註冊一個相應的TilesConfigurer bean。

2.12  ViewControllerBeanDefinitionParser

       繼承自BeanDefinitionParser，用來下面三個MVC命名空間元素：view-controller、redirect-view-controller、status-controller。

2.13  ViewResolversBeanDefinitionParser

       解析MVC命名空間元素：view-resolvers，註冊ViewResolver bean definitions。

 

web/servlet/config/annotation   

2.14  AsyncSupportConfigurer

       爲異步請求處理進行配置選項的幫助類。

2.15  ContentNegotiationConfigurer

       建立一個ContentNegotiationManager，用一個或者多個ContentNegotiationStrategy實例配置它。

2.16  CorsRegistration

       協助建立CorsConfiguration實例，爲一個給定的URL路徑模式。

2.17  CorsRegistry

       跨域註冊表，同理持有一組CorsRegistration，而後能夠直接獲取CorsConfiguration。

2.18  DefaultServletHandlerConfigurer

       配置一個請求處理器，經過將請求轉發到Servlet容器的默認Servlet，主要爲靜態資源服務。

2.19  DelegatingWebMvcConfiguration

       DelegatingWebMvcConfiguration是對Spring MVC進行配置的一個代理類。它結合缺省配置和用戶配置定義Spring MVC運行時最終使用的配置。繼承自WebMvcConfigurationSupport，而WebMvcConfigurationSupport爲Spring MVC提供缺省配置。

2.20  EnableWebMvc

       在@Configuration註解的配置類中添加，用於爲該應用添加SpringMVC的功能，即添加以後能夠在項目中，可使用@RequestMapping，@Controller等註解來定義請求處理與請求uri的映射和其餘SpringMvc提供的功能。

2.21  InterceptorRegistration   

       幫助建立一個MappedInterceptor。

2.22  InterceptorRegistry

       攔截器註冊表，管理一組InterceptorRegistration攔截器配置類，能夠經過getInterceptor()方法獲得MappedInterceptor對象。

2.23  PathMatchConfigurer

       幫助配置一組mapped interceptors。

2.24  RedirectViewControllerRegistration

       幫助註冊一個單一的重定向視圖控制器。

2.25  ResourceChainRegistration

       幫助註冊資源解析器和轉換器。

2.26  ResourceHandlerRegistration

       封裝一些在建立資源處理器時須要的信息。

2.27  ResourceHandlerRegistry

       存儲資源處理器的註冊，主要是爲一些靜態資源服務，如圖片、CSS文件等。

2.28  UrlBasedViewResolverRegistration

       幫助配置一個UrlBasedViewResolver。Spring MVC使用ViewResolver來根據controller中返回的view名關聯到具體的View對象。使用View對象來渲染返回值以生成最終的視圖，如html，json或pdf等。

2.29  ViewControllerRegistration

       幫助註冊一個視圖控制器。

2.30  ViewControllerRegistry    

       幫助註冊一個簡單的自動配置的控制器。

2.31  ViewResolverRegistry

       幫助配置一系列的ViewResolver實例，該類會被configureViewResolvers使用。

2.32  WebMvcConfigurationSupport

       這是MVC Java配置的一個主要的類，經過在@Configuration應用類加入註解@EnableWebMvc導入，一個更有效的方法是直接繼承該類，而後從新裏面的方法，在繼承類中要添加@Configuration註解，要覆蓋的@Bean方法添加@Bean註解。

2.33  WebMvcConfigurer

       WebMvcConfigurer是一個接口，提供不少自定義的攔截器，例如跨域設置、類型轉化器等等。能夠說此接口爲開發者提早想到了不少攔截層面的需求，方便開發者自由選擇使用。

       WebMvcConfigurer配置類實際上是Spring內部的一種配置方式，採用JavaBean的形式來代替傳統的xml配置文件形式進行鍼對框架個性化定製。基於java-based方式的spring mvc配置，須要建立一個配置類並實現WebMvcConfigurer 接口。

2.34  WebMvcConfigurerAdapter

       在Spring Boot 1.5版本都是靠重寫WebMvcConfigurerAdapter的方法來添加自定義攔截器，消息轉換器等。SpringBoot 2.0 後，該類被標記爲@Deprecated（棄用）。官方推薦直接實現WebMvcConfigurer或者直接繼承WebMvcConfigurationSupport，方式一實現WebMvcConfigurer接口（推薦），方式二繼承WebMvcConfigurationSupport類。

2.35  WebMvcConfigurerComposite

       此類是一個委託代理類，在DelegatingWebMvcConfiguration類中實例化，並將系統自帶或者自定義的配置類注入到成員變量delegates之中。

 

3、web/servlet/function

3.1  DefaultEntityResponseBuilder

       EntityResponse.Builder的默認實現類。

3.2  DefaultRenderingResponseBuilder

       RenderingResponse.Builder的默認實現類。

3.3  DefaultServerRequest

       基於HttpServletRequest的ServerRequest的實現類。

3.4  DefaultServerRequestBuilder

       ServerRequest.Builder的默認實現類。

3.5  DefaultServerResponseBuilder

       ServerResponse.BodyBuilder的默認實現類。

3.6  EntityResponse

       指定實體的ServerResponse子接口，暴露了實體數據。

3.7  HandlerFilterFunction

       表示一個函數，用來過濾HandlerFunction。

3.8  HandlerFunction 

       一個函數接口，用來處理ServerRequest。

3.9  PathResourceLookupFunction

       查找函數，被RouterFunctions#resources(String, Resource)函數使用。

3.10  RenderingResponse

       指定渲染的ServerResponse的子接口，暴露模型和臨時性數據。

3.11  RequestPredicate

       表示一個用來評估給定的ServerRequest的函數。

3.12  RequestPredicates

       實現RequestPredicate接口的抽象類，實現了幾個有用的請求匹配的操做，如基於path、HTTP方法的匹配。

3.13  ResourceHandlerFunction

       基於資源的HandlerFunction接口的實現類。

3.14  RouterFunction

       表示路由到一個HandlerFunction的函數。

3.15  RouterFunctionBuilder

       RouterFunctions.Builder的默認實現類。

3.16  RouterFunctions

       Spring功能性web框架的核心入口。

3.17  ServerRequest

       表示服務端的HTTP請求，經過HandlerFunction處理。

3.18  ServerResponse

       表示服務器端的一個HTTP響應，經過HandlerFunction或HandlerFilterFunction返回獲得。

3.19  ToStringVisitor

       RouterFunctions.Visitor的實現類，用來建立表示router函數的格式化字符串。

 

web/servlet/function/support

3.20  HandlerFunctionAdapter

       HandlerAdapter接口實現類，用來支持HandlerFunction。

3.21  RouterFunctionMapping

       HandlerMapping實現類，用來支持RouterFunctions。

 

4、web/servlet/handler

4.1  AbstractDetectingUrlHandlerMapping

       抽象類，經過重寫initApplicationContext來註冊Handler，調用detectHandlers方法會根據配置的detectHand-lersInAcestorContexts參數從springMVC容器或者springMVC集羣父容器中找到全部bean的beanName，而後調用determineUrlsForHandler方法對每一個beanName解析出對應的urls，若是解析的結果不爲空，則將解析出的urls和beanName註冊到父類的map中。

4.2  AbstractHandlerExceptionResolver

       實現HandlerExceptionResolver接口和Orderd接口，是HandlerExceptionResolver類的實現的基類。ResponseStatusExceptionResolver等具體的異常處理類均在AbstractHandlerExceptionResolver之上，實現了具體的異常處理方式。

4.3  AbstractHandlerMapping

       AbstractHandlerMapping是HandlerMapping的抽象實現，全部的HandlerMapping都繼承自AbstractHandlerMapping。

       AbstractHandlerMapping採用模板模式設計了HandlerMapping實現的總體結構，子類只須要提供一些初始值或者具體的算法便可。

       HandlerMapping的做用是根據request查找Handler和Interceptors。獲取Handler的過程經過模板方法getHandlerInternal交給子類。AbstractHandlerMapping保存了所用配置的Interceptor，在獲取Handler以後會本身根據從request中提取的lookupPath將相應的Interceptors裝配上去。

 

       定義了getHandlerInternal基本流程，進行url匹配HandlerMethod，若是有多於1個HandlerMethod被匹配，拋出錯誤信息，不然設置request的attribute信息將HandlerMapping接口中的幾個屬性暴露出來，最後返回HandlerMethod。同時它也實現了Handler和Method的收集和url映射規則。它實現了InitializingBean，在初始化時調用子類斷定bean和method是否須要映射，若是須要將映射信息保存到MappingRegistry內部類中。

4.4  AbstractHandlerMethodExceptionResolver

       它是ExceptionHandlerExceptionResolver的抽象父類，服務於處理器類型是HandlerMethod類型的拋出的異常，它並不規定實現方式必須是@ExceptionHandler。它複寫了抽象父類AbstractHandlerExceptionResolver的shouldApplyTo方法。

       AbstractHandlerMethodExceptionResolver和ExceptionHandlerExceptionResolver一塊兒使用，完成使用@ExceptionHandler註釋的方法進行對異常的解析。

4.5  AbstractHandlerMethodMapping

       HandlerMapping實現類的抽象基類，定義了請求和HandlerMethod之間的映射關係。

4.6  AbstractUrlHandlerMapping

       AbstractUrlHandlerMapping是AbstractHandlerMapping中兩個主要繼承類中的一個，任何以URL映射Handler的HandlerMapping都是繼承了AbstractUrlHandlerMapping，其中主要負責的流程有兩個，一個是自身的建立和初始化，而初始化則是爲了初始化內部的HandlerMap，但是初始化HandlerMap實際上是由子類實現的，AbstractUrlHandlerMapping只是提供子類註冊Handler的途徑，而後由不一樣的子類註冊不一樣的Handler到Map中去，以後在AbstractUrlHandlerMapping就可使用註冊完成的HandlerMap對Handler進行查找。

4.7  BeanNameUrlHandlerMapping

       BeanNameUrlHandlerMapping處理器映射器，會根據請求的url和Spring容器中定義的處理器bean的name屬性值進行匹配，從而在spring容器中找處處理器bean的實例。

4.8  ConversionServiceExposingInterceptor   

       Spring MVC的一個HandlerInterceptor，用於向請求添加一個屬性，屬性名稱爲ConversionService.class.getName()，值是Spring MVC配置定義的一個類型轉換服務。該類型轉換服務會在請求處理過程當中用於請求參數或者返回值的類型轉換。缺省狀況下，Spring MVC配置機制會主動構建一個ConversionServiceExposingInterceptor應用於全部的請求。

4.9  DispatcherServletWebRequest

       ServletWebRequest子類。

4.10  HandlerExceptionResolverComposite   

       做爲容器使用，能夠封裝別的Resolver，它並不會解析具體的異常，而是調用其餘的異常解析器處理異常。

4.11  HandlerInterceptorAdapter

       有三個方法：方別是preHandle，postHandle， afteCompletion。當咱們須要使用的HandlerInterceptorAdapter實現相應的功能的時候（配置一個攔截器），就須要繼承HandlerInterceptorAdapter，並實現其中相應的方法。

4.12  HandlerMappingIntrospector

       從HandlerMapping中獲取信息的幫助類，用來爲一個指定的請求服務。提供了方法getMatchableHandlerMapping獲取一個HandlerMapping，方法getCorsConfiguration獲取CORS配置。

4.13  HandlerMethodMappingNamingStrategy

       策略接口，用於將一個名字分配給一個handler method的 mapping。

4.14  MappedInterceptor

       一個包括includePatterns和excludePatterns字符串集合並帶有HandlerInterceptor的類。用於對於某些地址作特殊包括和排除的攔截器。

4.15  MatchableHandlerMapping

       繼承自HandlerMapping，用來判斷指定的請求是否符合請求條件。

4.16  RequestMatchResult

       用來保存經過MatchableHandlerMapping方法進行請求模式匹配獲得的結果的容器。

4.17  SimpleMappingExceptionResolver

       經過配置的異常類和view的對應關係來解析異常。

4.18  SimpleServletHandlerAdapter

       簡單Servlet處理器適配器，它是spring提供的處理適配器，專門適配類型爲javax.servlet.Servlet的處理器，其最終執行的方法是Servlet的service方法。

4.19  SimpleServletPostProcessor

       BeanPostProcessor接口實現類，將初始化和銷燬回調函數應用到實現Servlet接口的bean。

4.20  SimpleUrlHandlerMapping

       經過指定urlMap屬性來實現請求URL到控制器（controller handler bean）的映射，當咱們訪問特定的URL時，就會查詢由哪一個handler處理該請求。

4.21  UserRoleAuthorizationInterceptor

       繼承了抽象類HandlerInterceptorAdapter，實現了用戶登陸認證的攔截功能，若是當前用戶沒有經過認證，會報403錯誤。

4.22  WebRequestHandlerInterceptorAdapter

       實現了Servlet HandlerInterceptor接口的適配器，封裝了一個WebRequestInterceptor。

 

5、web/servlet/i18n

5.1  AbstractLocaleContextResolver

       LocaleContextResolver實現類的抽象基類，提供了對默認地區和默認時區的支持。

5.2  AbstractLocaleResolver

       LocaleResolver接口實現類的抽象基類，提供了對默認地區的支持。

5.3  AcceptHeaderLocaleResolver

       其實沒有任何具體實現，是經過瀏覽器頭部的語言信息來進行多語言選擇。

5.4  CookieLocaleResolver

       將語言信息設置到Cookie中，這樣整個系統就能夠得到語言信息。

5.5  FixedLocaleResolver

       設置固定的語言信息，這樣整個系統的語言是一成不變的。

5.6  LocaleChangeInterceptor

       地區更改攔截器，能夠經過配置請求的參數（默認的參數名爲「locale」）在每一個請求中對當前的地區值進行更改。

5.7  SessionLocaleResolver

       與CookieLocaleResolver相似將語言信息放到Session中，這樣整個系統就能夠從Session中得到語言信息。

 

6、web/servlet/mvc

6.1  AbstractController

       若是你想讓控制器具有一些基本的特性，如過濾受支持的HTTP方法（GET、POST和HEAD），以及在HTTP響應中生成cache-control頭部等，你可讓它擴展AbstractController類。

6.2  AbstractUrlViewController

       根據請求URL路徑直接轉化爲邏輯視圖名的支持基類。

6.3  Controller    

       Controller接口，定義一個方法，做用就是處理用戶請求。

6.4  HttpRequestHandlerAdapter

       主要是適配靜態資源處理器，靜態資源處理器就是實現了HttpRequestHandler接口的處理器，這類處理器的做用是處理經過SpringMVC來訪問的靜態資源的請求。

6.5  LastModified

       支持最新修改的HTTP請求，方便進行內容的緩存。

6.6  ParameterizableViewController

       參數化視圖控制器，根據參數的邏輯視圖名直接選擇須要展現的視圖。

6.7  ServletForwardingController

       將Spring Handler接收的請求轉發給一個Servlet去執行。

6.8  ServletWrappingController

       Servlet包裝控制器。

6.9  SimpleControllerHandlerAdapter

       是Controller處理適配器，適配實現了Controller接口或Controller接口子類的處理器，好比咱們常常本身寫的Controller來繼承MultiActionController，那麼本身寫的這些Controller就會由SimpleControllerHandlerAdapter來適配。

6.10  UrlFilenameViewController

       url解析後直接訪問資源視圖.能夠簡單的配置BeanName映射而後訪問靜態資源。

6.11  WebContentInterceptor

       支持最新修改的HTTP請求，方便進行內容的緩存。

 

web/servlet/mvc/annotation

6.12  ModelAndViewResolver

       SPI，用於解析從指定的處理器方法中的自定義的返回值。一般，其實現類用來檢測檢查專門的返回類型，解析經常使用的返回值。

       SPI全稱Service Provider Interface，是Java提供的一套用來被第三方實現或者擴展的API，它能夠用來啓用框架擴展和替換組件。面向的對象的設計裏，咱們通常推薦模塊之間基於接口編程，模塊之間不對實現類進行硬編碼。一旦代碼裏涉及具體的實現類，就違反了可拔插的原則，若是須要替換一種實現，就須要修改代碼。爲了實如今模塊裝配的時候不用在程序裏動態指明，這就須要一種服務發現機制。java spi就是提供這樣的一個機制：爲某個接口尋找服務實現的機制。這有點相似IOC的思想，將裝配的控制權移到了程序以外。

       咱們在「調用方」和「實現方」之間須要引入「接口」，那麼什麼狀況應該把接口放入調用方，何時能夠把接口歸爲實現方。

       先來看看接口屬於實現方的狀況，這個很容易理解，實現方提供了接口和實現，咱們能夠引用接口來達到調用某實現類的功能，這就是咱們常常說的api，它具備如下特徵：

       一、概念上更接近實現方；

       二、組織上位於實現方所在的包中；

       三、實現和接口在一個包中。

       當接口屬於調用方時，咱們就將其稱爲spi，全稱爲：service provider interface，spi的規則以下：

       一、概念上更依賴調用方；

       二、組織上位於調用方所在的包中；

       三、實現位於獨立的包中（也可認爲在提供方中）。

6.13  ResponseStatusExceptionResolver

       當程序發生異常時，ResponseStatusExceptionResolver異常解釋器用來解析@ResponseStatus標註的異常類，並把異常的狀態碼返回給客戶端。DispatcherServlet默認裝配了ResponseStatusExceptionResolver 的Bean。

 

web/servlet/mvc/condition

6.14  AbstractMediaTypeExpression

       支持在RequestMapping的consumes()和produces()中描述的MIME類型表達式。

6.15  AbstractNameValueExpression

       支持在RequestMapping#params()和headers()中描述的"name=value"類型的表達式。

6.16  AbstractRequestCondition

       框架對接口RequestCondition有一組具體實現類。對這些具體實現類的一些通用邏輯，好比equals、hashCode和toString，是被放到抽象基類AbstractRequestCondition來實現的。同時AbstractRequestCondition還經過protected抽象方法約定了實現類其餘的一些內部通用邏輯。

6.17  CompositeRequestCondition

       自己不帶任何的匹配條件，只是用於包裝其餘的RequestCondition進行匹配。

6.18  MediaTypeExpression

       MIME類型表達式（如"text/plain"、 "!text/plain"）的約定，這些表達式在"consumes"和 "produces" 條件的@RequestMapping註解中定義。

6.19  NameValueExpression

       "name!=value"類型表達式的約定，用來在@RequestMapping註解中指定請求參數和請求頭條件。

6.20  RequestCondition

       接口RequestCondition是Spring MVC對一個請求匹配條件的概念建模。最終的實現類多是針對如下狀況之一：路徑匹配，頭部匹配，請求參數匹配，可產生MIME匹配，可消費MIME匹配，請求方法匹配，或者是以上各類狀況的匹配條件的一個組合。

6.21  RequestConditionHolder

       一個匹配條件持有器，用於持有某個RequestCondition對象。若是你想持有一個RequestCondition對象，但其類型事先不可知，那麼這種狀況下該工具頗有用。但要注意的是若是要合併或者比較兩個RequestConditionHolder對象，也就是兩者所持有的RequestCondition對象，那麼兩者所持有的RequestCondition對象必須是類型相同的，不然會拋出異常ClassCastException。

6.22  ConsumesRequestCondition

       ConsumesRequestCondition（請求媒體類型過濾器）。

       一、 建立跟請求匹配的過濾條件對象：篩選出同請求Accpet匹配的媒體類型表達式列表， 而後建立新的過濾條件對象， 並返回。

       二、組合兩個過濾條件對象：若是傳入的過濾器的媒體類型表達式列表不爲空， 則優先使用，這樣處理的目的是方法的匹配覆蓋類的配置。

       三、比較過濾條件對象優先級：同請求Accpet匹配度高的過濾對象優先級高。

6.23  ProducesRequestCondition

       ProducesRequestCondition（應答媒體類型過濾器）。

       一、 建立跟請求匹配的過濾條件對象：篩選出同請求Content-Type匹配的媒體類型表達式列表， 而後建立新的過濾條件對象， 並返回。

       二、組合兩個過濾條件對象：若是傳入的過濾器的媒體類型表達式列表不爲空， 則優先使用，這樣處理的目的是方法的匹配覆蓋類的配置。

       三、比較過濾條件對象優先級：同請求Content-Type匹配度高的過濾對象優先級高。

6.24  RequestMethodsRequestCondition

       RequestMethodsRequestCondition （請求方法過濾器）。

       一、 建立跟請求匹配的過濾條件對象：篩選出同request請求匹配的方法名稱， 而後建立新的過濾條件對象，並返回，若是返回null，則認爲過濾器不匹配請求。

       二、組合兩個過濾條件對象：把兩個過濾對象的方法名稱集合累加起來，  而後建立新的過濾對象， 並返回。

       三、比較過濾條件對象優先級：請求方法名稱個數多的那個過濾器優先級高。

6.25  HeadersRequestCondition

       HeadersRequestCondition（頭字段過濾器）。

       一、 建立跟請求匹配的過濾條件對象：判斷全部的頭字段表達式是否都匹配請求對象， 是則返回本過濾器，不然返回null，認爲過濾器不匹配request請求。

       二、組合兩個過濾條件對象：把兩個過濾對象的頭字段表達式集合累加起來，  而後建立新的過濾對象， 並返回。

       三、比較過濾條件對象優先級：頭字段表達式個數多的過濾器優先級高。

6.26  ParamsRequestCondition

       ParamsRequestCondition（請求參數過濾器）。

       一、 建立跟請求匹配的過濾條件對象：判斷全部的參數表達式是否都匹配request請求對象， 是則返回本過濾對象， 不然返回null，認爲過濾對象不匹配request請求。

       二、組合兩個過濾條件對象：把兩個過濾對象的參數表達式集合累加起來，  而後建立新的請求參數過濾對象， 並返回。

       三、比較過濾條件對象優先級：參數表達式個數多的那個過濾器優先級高。

6.27  PatternsRequestCondition

       PatternsRequestCondition（模式請求路徑過濾器）。

       一、 建立跟請求匹配的過濾器對象：從持有的模式請求路徑列表中篩選出同request請求匹配的模式請求路徑，可能會有多個，對篩選後的模式請求路徑列表執行排序，最詳細最具體的路徑排在前面，而後使用過濾後的模式請求列表建立一個新的過濾器並返回。多個模式請求路徑之間是或關係，只要有一個模式請求路徑跟request請求匹配，就認爲過濾對象跟request請求匹配。

       二、組合兩個過濾條件對象：對兩個模式請求路徑列表中的元素進行天然鏈接後，再執行簡單拼接，

而後建立新的模式請求路徑過濾條件對象， 並返回。

       三、比較過濾條件對象優先級：規則是誰的模式請求路徑跟請求路徑匹配度更高。

 

web/servlet/mvc/method    

6.28  AbstractHandlerMethodAdapter

       HandlerAdapter接口的簡單抽象類，實現了接口定義的方法，同時增長了執行順序Order。

6.29  RequestMappingInfo

       使用@RequestMapping註解時，配置的信息最後都設置到了請求映射信息對象RequestMappingInfo中。

       RequestMappingInfo封裝了PatternsRequestCondition，RequestMethodsRequestCondition，ParamsRequestCondition等，全部的工做都是委託給具體的condition處理。

       springMVC在啓動時會掃描全部的@RequestMapping並封裝成對應的RequestMapingInfo。一個請求過來會與RequestMapingInfo進行逐個比較，找到最適合那個RequestMapingInfo。

6.30  RequestMappingInfoHandlerMapping

       爲Handler引入具化類型RequestMappingInfo，同時實現部分父類抽象方法。

6.31  RequestMappingInfoHandlerMethodMappingNamingStrategy

       RequestMappingHandlerMapping繼承於AbstractHandlerMethodMapping，其中AbstractHandlerMethodMapping系列是將method做爲handler來使用，裏面涉及三個map：

       一、handlerMethods：保存着匹配條件（也就是RequestCondition）和HandlerMethod的對應關係。

       二、urlMap：保存着URL與匹配條件的對應關係。

       三、nameMap：這個Map保存着name和HandlerMethod的對應關係，一個name能夠有多個HandlerMethod，這裏的name是使用HandlerMethodMappingNamingStratety策略的實現類從HandlerMethod中解析處理。解析規則是：類名裏的大寫字母+「#」+方法名。

       該類就是HandlerMethodMappingNamingStratety接口的實現類。

 

web/servlet/mvc/method/annotation        

6.32  AbstractMappingJacksonResponseBodyAdvice

       ResponseBodyAdvice接口實現的抽象基類，在JSON序列化以前對響應進行定製。

6.33  AbstractMessageConverterMethodArgumentResolver

       抽象基類，使用HttpMessageConverters從請求體中解析方法參數值。

6.34  AbstractMessageConverterMethodProcessor

       繼承自AbstractMessageConverterMethodArgumentResolver，經過HttpMessageConverters寫入響應，從而處理方法返回值。

6.35  AsyncTaskMethodReturnValueHandler

       處理WebAsyncTask類型的返回值。

6.36  CallableMethodReturnValueHandler

       處理Callable類型的返回值。

6.37  DeferredResultMethodReturnValueHandler

       處理DeferredResult、ListenableFuture、CompletionStage類型的返回值。

6.38  ExceptionHandlerExceptionResolver

       繼承自AbstractHandlerMethodExceptionResolver，經過@ExceptionHandler註解的方法解析異常。

6.39  ExtendedServletRequestDataBinder

       ServletRequestDataBinder的子類，將URI信息也一塊兒綁定到對象屬性中。

6.40  HttpEntityMethodProcessor

       解析HttpEntity、RequestEntity方法參數值，同時也處理HttpEntity、RequestEntity返回值。

6.41  HttpHeadersReturnValueHandler

       支持返回類型HttpHeaders。

6.42  JsonViewRequestBodyAdvice

       RequestBodyAdvice接口的實現類，增長了對Jackson的@JsonView註解的支持，該註解聲明在Spring MVC @HttpEntity或者@RequestBody方法參數上。

6.43  JsonViewResponseBodyAdvice

       RequestBodyAdvice接口的實現類，增長了對Jackson的@JsonView註解的支持，該註解聲明在Spring MVC @RequestMapping或者@ExceptionHandler方法上。

6.44  MatrixVariableMapMethodArgumentResolver

       解析一個使用@MatrixVariable註解的Map類型的參數，該註解並不指定一個名字。換句話來講，這個解析器的目的是提供到multiple matrix變量的訪問方法。

6.45  MatrixVariableMethodArgumentResolver

       解析使用@MatrixVariable註解的參數。

6.46  ModelAndViewMethodReturnValueHandler

       處理ModelAndView類型的返回值，將view和model信息拷貝到ModelAndContainer。若是返回值爲空，那麼ModelAndViewContainer#setRequestHandled(boolean)標誌位設置爲true，表示請求已經直接被處理了。

6.47  ModelAndViewResolverMethodReturnValueHandler

       該返回值處理器排在其餘全部處理器以後，用來處理任意類型的返回值。

6.48  MvcUriComponentsBuilder

       經過Spring MVC控制器的@RequestMapping註解的方法，建立UriComponentsBuilder實例。

6.49  PathVariableMapMethodArgumentResolver

       支持Map參數類型的@PathVariable註解解析。

6.50  PathVariableMethodArgumentResolver

       支持非Map參數類型的@PathVariable註解解析。

6.51  ReactiveTypeHandler

       幫助處理響應式返回值類型。

6.52  RedirectAttributesMethodArgumentResolver      

       解析RedirectAttributes類型的方法參數。

6.53  RequestAttributeMethodArgumentResolver

       支持參數註解@RequestAttribute解析。

6.54  RequestBodyAdvice

       在讀取請求body以前或者在body轉換成對象以前能夠作相應的加強。

6.55  RequestBodyAdviceAdapter

       ResponseBodyAdvice接口實現類的抽象基類，對接口的一些方法進行了實現。

6.56  RequestMappingHandlerAdapter

       該類繼承了 AbstractHandlerMethodAdapter 類，真正意義上實現了 HandlerAdapter 接口定義的功能。

       該方法的具體過程以下：

       一、校驗請求，即檢查是否支持當前 rqeuest 的 method 和 session；

       二、判斷控制器是否存在 @SessionAttributes 註解，有則設置緩存，不然準備響應；

       三、處理器調用，返回 ModelAndView 。

       對RequestMappingInfo這個Handler的具化處理，這是一個主要的映射處理類。初始化了默認的參數解析器，@InitBinder時調用的參數解析器，返回值參數解析器，支持了@ControllerAdvice註解類中@InitBinder方法的全局調用，@ModelAttribute註解的方法級調用和全局調用。

6.57  RequestMappingHandlerMapping

       引入@Controller和@RequestMapping註解的實現，實現父類須要具體判斷的抽象方法。

6.58  RequestPartMethodArgumentResolver

       支持參數註解@RequestPart解析。

6.59  RequestResponseBodyAdviceChain

       持有一組RequestBodyAdvice和ResponseBodyAdvice。在RequestResponseBodyMethodProcessor對參數進行解析先後，觸發全部的回調。

6.60  RequestResponseBodyMethodProcessor

       經過HttpMessageConverter對請求和響應進行讀寫，從而解析@RequestBody註解的方法參數、處理@ResponseBody返回值。

6.61  ResponseBodyAdvice

       是spring4.1的新特性，其做用是在響應體寫出以前作一些處理；好比，修改返回值、加密等。

6.62  ResponseBodyEmitter

       一個控制器方法，爲異步請求處理返回值類型。

6.63  ResponseBodyEmitterReturnValueHandler

       ResponseBodyEmitter類型的返回的的處理器，SseEmitter等的子類。

6.64  ResponseEntityExceptionHandler

       ResponseEntityExceptionHandler中包裝了各類SpringMVC在處理請求時可能拋出的異常的處理，處理結果都是封裝成一個ResponseEntity對象。經過ResponseEntity咱們能夠指定須要響應的狀態碼、header和body等信息，響應的body會被HttpMessageConverter處理，因此若是你響應的body是一個對象，而你的HttpMessageConverter列表中有一個是能夠把對象轉換爲JSON的HttpMessageConverter，那麼客戶端收到的就是一段JSON。

       ResponseEntityExceptionHandler是一個抽象類，一般咱們須要定義一個用來處理異常的使用@ControllerAdvice註解標註的異常處理類來繼承自ResponseEntityExceptionHandler。如下是ResponseEntityExceptionHandler的源碼，從源碼中咱們能夠看出它能夠處理的異常，併爲每一個異常的處理都單獨定義了一個方法，若是默認的處理不能知足你的需求，則能夠重寫對某個異常的處理。默認的實現最終都會調用handleExceptionInternal()方法，若是有通用的處理也能夠從這裏入手。

6.65  ServletCookieValueMethodArgumentResolver

       繼承自AbstractCookieValueMethodArgumentResolver，從HttpServletRequest中解析cookie值。

6.66  ServletInvocableHandlerMethod

       ServletInvocableHandlerMethod是對InvocableHandlerMethod的進一步擴展，擴展了處理控制器方法返回值和註解@ResponseStatus的能力。而InvocableHandlerMethod是HandlerMethod的擴展，它基於一組HandlerMethodArgumentResolver從請求上下文中解析出控制器方法的參數值。HandlerMethod類在應用啓動過程當中蒐集Web控制器方法信息階段用於記錄每一個控制器方法的信息。

       ServletInvocableHandlerMethod對控制器方法返回值的處理是經過一組註冊了的HandlerMethodReturnValueHandler完成的。

       若是返回值是null或者void，則ServletInvocableHandlerMethod會綜合考慮@ResponseStatus註解，not-modified檢查條件，或者控制器方法參數中提供的response對象而後決定是否將請求設置爲已經處理。

       若是返回值不是null/void，可是有註解@ResponseStatus而且其屬性reason被設置，請求也將會被設置爲已處理。

       對於其餘返回值狀況，ServletInvocableHandlerMethod會構造一個ModelAndView對象給調用者。

       另外對於瀏覽器端重定向redirect，ServletInvocableHandlerMethod還會考慮對請求屬性flash attributes的更新設置。

6.67  ServletModelAttributeMethodProcessor

       繼承自ModelAttributeMethodProcessor，經過ServletRequestDataBinder類型的WebDataBinder進行數據綁定。

6.68  ServletRequestDataBinderFactory

       它繼承自InitBinderDataBinderFactory，用於建立ServletRequestDataBinder。ServletRequestDataBinder：在bind時支持將reqesut.getParameterNames中的屬性綁定到類對象屬性。

6.69  ServletRequestMethodArgumentResolver

       支持servlet的一些api參數解析，如：WebRequest、ServletRequest、MultipartRequest、HttpSession、PushBuilder、Principal、 InputStream、Reader、HttpMethod、Locale、TimeZone、java.time.ZoneId。

6.70  ServletResponseMethodArgumentResolver

       支持servlet的一些api返回值解析.如:ServletResponse、OutputStream、Writer。

6.71  ServletWebArgumentResolverAdapter

       繼承自AbstractWebArgumentResolverAdapter，從ServletRequestAttributes建立一個NativeWebRequest。

6.72  SessionAttributeMethodArgumentResolver

       支持參數註解@SessionAttribute解析。

6.73  SseEmitter

       該類繼承自ResponseBodyEmitter，專門用來發送Server-Sent Events。

       SSE(Server-Sent Events)，一種基於HTTP的，以流的形式由服務端持續向客戶端發送數據的技術。咱們常見的 http 交互方式是客戶端發起請求，服務端響應，而後一次請求完畢；可是在 sse 的場景下，客戶端發起請求，鏈接一直保持，服務端有數據就能夠返回數據給客戶端，這個返回能夠是屢次間隔的方式。springmvc不斷輸出文本到網頁，採用的是對response不斷進行write和flush實現的。在spring 4.2版本的時候提供了一個SseEmitter能夠直接用來實現這個功能。

       SSE 最大的特色，能夠簡單規劃爲兩個：一、長鏈接。二、服務端能夠向客戶端推送信息。

       websocket也是長鏈接，能夠推送信息，可是它們有一個明顯的區別：SSE是單通道，只能服務端向客戶端發消息；而 webscoket 是雙通道。

6.74  StreamingResponseBody

       一個Controller在處理異步請求的時候，StreamingResponseBody會直接把流寫入到response的輸出流中，而且不會佔用Servlet容器線程。

6.75  StreamingResponseBodyReturnValueHandler

       HandlerMethodReturnValueHandler接口的實現類，支持StreamingResponseBody類型的返回值。

6.76  UriComponentsBuilderMethodArgumentResolver

       解析UriComponentsBuilder類型的參數，返回的實例經過fromServletMapping(HttpServletRequest)進行初始化。

6.77  ViewMethodReturnValueHandler

       處理View類型的返回值。

6.78  ViewNameMethodReturnValueHandler

       支持String類型的返回值當作viewName進行解析。

 

web/servlet/mvc/support    

6.79  DefaultHandlerExceptionResolver

       DefaultHandlerExceptionResolver是Spring MVC對接口HandlerExceptionResolver的一個內置實現，這個HandlerExceptionResolver，顧名思義，是做爲」缺省」HandlerExceptionResolver被使用的，也就是說，若是其餘HandlerExceptionResolver不能處理指定的異常，最後會使用DefaultHandlerExceptionResolver來處理。而DefaultHandlerExceptionResolver可以解析標準Spring MVC異常，將其翻譯成相應的HTTP狀態碼，經過response.sendError方法處理響應。

       該異常解析器是Spring MVC的前端控制器DispatcherServlet缺省啓用的HandlerExceptionResolver之一，而且被設置爲最低優先級。

       核心方法是#doResolveException，該方法內部根據異常的類型調用不一樣的方法將異常翻譯成相應的HTTP狀態碼並sendError到響應對象，而且返回值是一個空ModelAdnView對象，也就是一個其#isEmpty方法老是爲true的對象，此返回值告訴調用者：請使用缺省視圖渲染相應的錯誤信息。

6.80  RedirectAttributes

       RedirectAttributes是Spring mvc 3.1版本以後出來的一個功能，專門用於重定向以後還能帶參數跳轉的，有兩種帶參的方式：

       第一種：attr.addAttribute(「param」, value);

       這種方式就至關於重定向以後，在url後面拼接參數，這樣在重定向以後的頁面或者控制器再去獲取url後面的參數就能夠了，但這個方式由於是在url後面添加參數的方式，因此暴露了參數，有風險。

       第二種：attr.addFlashAttribute(「param」, value);

       這種方式也能達到從新向帶參，並且能隱藏參數，其原理就是放到session中，session在跳到頁面後立刻移除對象。因此你刷新一下後這個值就會丟掉。

6.81  RedirectAttributesModelMap

       繼承自ModelMap、RedirectAttributes，使用DataBinder將值格式爲String類型。同時提供了存儲flash attributes的空間，使得在重定向的時候得以保存，而不用嵌入到重定向URL中。

 

7、web/servlet/resource

7.1  AbstractResourceResolver

       ResourceResolver接口實現類的抽象基類，提供了一致的日誌記錄。

7.2  AbstractVersionStrategy

       VersionStrateg接口實現類的抽象基類。

7.3  AppCacheManifestTransformer

       幫助處理 HTML5 離線應用的 AppCache 清單內的文件

7.4  CachingResourceResolver

       CachingResourceResolver 用於緩存其它 Resource Resolver 查找到的資源。所以 CachingResourceResolver 會被放在解析器鏈的最外層。請求先到達 CachingResourceResolver ，嘗試在緩存中查找，若是找到，則直接返回，若是找不到，則依次調用後面的 resolver ，直到有一個 resolver 可以找到資源， CachingResourceResolver 將找到的資源緩存起來，下次請求一樣的資源時，就能夠從緩存中取了。

7.5  CachingResourceTransformer

       緩存其它 transfomer 的結果，做用同 CachingResourceResolver。

7.6  ContentVersionStrategy    

       繼承自AbstractVersionStrategy，用於計算資源的MD5哈希值，用十六進制表示，並將其加到文件名中，如："styles/main-e36d2e05253c6c7085a91522ce43a0b4.css"。

7.7  CssLinkResourceTransformer

       處理 css 文件中的連接，爲其加上版本號。

7.8  DefaultResourceResolverChain

       便於經過責任鏈模式操做ResourceResolver列表。

7.9  DefaultResourceTransformerChain

       便於經過責任鏈模式操做ResourceTransformer列表。

7.10  DefaultServletHttpRequestHandler

       DefaultServletHttpRequestHandler是Spring MVC提供的使用Servlet容器缺省Servlet處理靜態文件的HttpRequestHandler實現。

       由於Spring MVC能夠支持多種Servlet容器，好比Tomat、Jetty、Jboss、GlassFish、Resin、GAE、WebLogic、WebSphere等。而在這些容器中，缺省Servlet的名字又不盡相同。因此該HttpRequestHandler會運行時檢測ServletContext所對應的Servlet容器的類型，從而確保不管使用哪一種Servlet容器，它老是可以正確地獲取到缺省Servlet並轉發相應的靜態文件處理請求。

7.11  EncodedResourceResolver

       解析器，若是發現一個資源，它將嘗試找到一個編碼器（如gzip、brotli），此編碼器要被請求頭"Accept-Encoding"所接受。

7.12  FixedVersionStrategy

       繼承自AbstractVersionStrategy，使用一個固定的版本做爲請求路徑的前綴，如縮減的SHA、版本名、發佈時間等。

7.13  GzipResourceResolver

       用來查找資源的壓縮版本，它首先使用下一個 Resource Resolver 查找資源，若是能夠找到，則再嘗試查找該資源的 gzip 版本。若是存在 gzip 版本則返回 gzip 版本的資源，不然返回非 gzip 版本的資源。

7.14  HttpResource

       繼承自Resource的接口，用來寫入到一個HTTP響應中。

7.15  PathResourceResolver

       一個簡單的資源解析器，嘗試在給定的位置找到一個和請求路徑相匹配的資源。該解析器是解析器鏈的最後一個，不會對解析器鏈作任何操做。

7.16  ResourceHttpRequestHandler

       一個HttpRequestHandler實現類，用於處理靜態資源請求。

7.17  ResourceResolver

       策略接口，用於解析一個請求到服務器端資源。

7.18  ResourceResolverChain

       調用資源解析器鏈的約定，每一個解析器都提供一個到鏈的引用，以方便在須要的時候調用。

7.19  ResourceTransformer

       轉換給定的資源。

7.20  ResourceTransformerChain

       資源轉換器鏈。

7.21  ResourceTransformerSupport

       ResourceTransformer接口實現類的抽象基類，提供了一些幫助性的方法。

7.22  ResourceUrlEncodingFilter

       過濾器，封裝了HttpServletResponse，重寫了其encodeURL()方法來版本化的資源地址。

7.23  ResourceUrlProvider

       一個核心組件，用來獲取公共的URL路徑，從而可讓客戶端使用來訪問一個靜態的資源。

7.24  ResourceUrlProviderExposingInterceptor

       Spring MVC的一個HandlerInterceptor，用於向請求添加一個屬性，屬性名稱爲ResourceUrlProvider.class.getName()，值是Spring MVC配置定義的一個資源URL提供者對象ResourceUrlProvider。

       缺省狀況下，Spring MVC配置機制會主動構建一個ResourceUrlProviderExposingInterceptor應用於全部的請求。

7.25  TransformedResource

       繼承自ByteArrayResource，資源轉換器可使用該類來表示一個原始的資源，只保留其內容而去除了其餘全部的信息。

7.26  VersionPathStrategy

       策略接口，用來在它的URL路徑中提取出或者嵌入資源的版本。

7.27  VersionResourceResolver

       解析包含了一個版本字符串的請求路徑。

7.28  VersionStrategy 

       繼承自VersionPathStrategy，增長了一個判斷資源實際版本的方法。

7.29  WebJarsResourceResolver

       資源解析器，負責解析一個包含WebJar JAR文件的資源。webjars 是將前端的庫（好比 jQuery）打包成 Jar 文件，而後使用基於 JVM 的包管理器（好比 Maven、Gradle 等）管理前端依賴的方案。

 

8、web/servlet/support

8.1  AbstractAnnotationConfigDispatcherServletInitializer

       自動被加載，負責應用程序中 servlet 上下文中的 DispatcherServlet 和 Spring 其餘上下文的配置。在Spring3.0環境中，容器會在類路徑中查找實現javax.servlet.ServletContainerInitializer接口的類，若是能發現的話，就會用它來配置Servlet容器。Spring提供了這個接口的實現，名爲SpringServletContainerInitializer。這個類反過來會查找實現WebApplicationInitializer的類並將配置的任務交給它們來完成。

       Spring3.2引入了一個便利的WebApplicationInitializer基礎實現，也就是AbstractAnnotationConfigDispatcherServletInitializer，DispatcherServlet實現了AbstractAnnotationConfigDispatcherServletInitializer，所以當部署到Servlet3.0容器中的時候，容器會自動發現它，並用它來配置Servlet上下文。

8.2  AbstractDispatcherServletInitializer

       WebApplicationInitializer實現類的父類，在servlet context中註冊一個DispatcherServlet。

8.3  AbstractFlashMapManager

       FlashMapManager實現類的基類。

8.4  BindStatus

       用於暴露一個域或對象的綁定狀態。此類被JSP bind tag和FreeMarker macros做爲一個變量使用。

8.5  JspAwareRequestContext

       JSP-aware的RequestContext的子類。

8.6  JstlUtils

       準備JSTL視圖的幫助類，特別是用於暴露一個JSTL本地化的上下文。

       JSTL（Java server pages standarded tag library，即JSP標準標籤庫），主要提供給Java Web開發人員一個標準通用的標籤庫，開發人員能夠利用這些標籤取代JSP頁面上的Java代碼，從而提升程序的可讀性，下降程序的維護難度。

8.7  RequestContext

       請求的上下文，保存着請求的狀態，如當前web應用上下文，當前的地區信息、當前的主題、綁定錯誤等。

8.8  RequestContextUtils

       提供訪問請求狀態的方便，經過DispatcherServlet設置。

8.9  RequestDataValueProcessor

       請求數據在被視圖渲染或者重定向以前，對其進行檢查和修改，好比URL請求參數、表單數據等。

8.10  ServletUriComponentsBuilder

       UriComponentsBuilder同其餘靜態工廠方法一道，基於當前的HttpServletRequest建立links。

8.11  SessionFlashMapManager

       將FlashMap存儲到HTTP session，或者從HTTP session中提取FlashMap。

8.12  WebContentGenerator     

       便捷的爲任何類型的網頁內容產生的父類，像AbstractController、WebContentInterceptor

也可用於自定義處理器HandlerAdapter 。支持HTTP緩存控制選項。 對應的HTTP頭的使用能夠經過控制」cacheSeconds」和」cacheControl」屬性。

 

9、web/servlet/tags

9.1  ArgumentAware  

       容許實現該接口的標籤使用嵌套的spring:argument標籤。

       Aware接口：Spring提供了普遍的Aware回調接口，讓bean向容器代表它們須要某種基礎設施依賴。一般Aware有這樣一個規則：Aware接口的名稱，表示依賴對象的類名稱。例如，一個bean須要使用ApplicationContext，實現ApplicationContextAware接口便可。

9.2  ArgumentTag

       <argument>標籤基於JSTL fms:param標籤，目的是支持消息和主題標籤裏的參數。

9.3  BindErrorsTag

       <hasBindErrors>標籤在發生綁定錯誤狀況下提供了Errors實例。

9.4  BindTag

       <bind>標籤爲一個某個bean或者bean屬性綁定errors。

9.5  EditorAwareTag

       被JSP標籤類實現的接口，爲一個屬性暴露當前綁定到的屬性編輯器。

9.6  EscapeBodyTag

       <escapeBody>標籤用來轉義它封閉的正文內容，使用HTML轉義和/或JavaScript轉義。

9.7  EvalTag

       <eval>標籤用於評估一個SpEL，而後要麼將結果打印出來要麼將它賦值給一個變量。

9.8  HtmlEscapeTag

       設置當前頁面的默認HTML轉義值。

9.9  HtmlEscapingAwareTag

       輸出內容可能獲得HTML轉義的標籤的一個父類。

9.10  MessageTag

       使用給定的代碼檢索消息，若是代碼不可解析則返回文本。

9.11  NestedPathTag

       設置綁定標記的路徑要使用的嵌套路徑。

9.12  Param

       該bean用來將ParamTag的鍵-值對傳送到ParamAware標籤。

9.13  ParamAware

       實現該接口的標籤方便使用嵌套的spring:param標籤。

9.14  ParamTag

       <param>標籤負責收集鍵-值對參數，而後將他們傳送到標籤層級樹的ParamAware的父類。

9.15  RequestContextAwareTag

       全部須要RequestContext的標籤的父類。

9.16  ThemeTag

       使用給定的代碼檢索主題消息，若是代碼不可解析，則檢索文本。

9.17  TransformTag

       使用BindTag中的適當自定義PropertyEditor將變量轉換爲String（只能在BindTag中使用）。

9.18  UrlTag

       <url>標籤建立URLs。

 

web/servlet/tags/form

9.19  AbstractCheckedElementTag

       抽象基類，爲實現databinding-aware的JSP標籤提供一些通用的方法，使用'checkbox' 或者' radio'渲染HTML的‘input’元素。

9.20  AbstractDataBoundFormElementTag

       全部data-binding aware的JSP格式的標籤的父類。

9.21  AbstractFormTag

       全部JSP標籤的父類。

9.22  AbstractHtmlElementBodyTag

       使用AbstractHtmlElementTag的databinding features進行內容渲染的Html標籤的父類。

9.23  AbstractHtmlElementTag

       渲染HTML元素的databing-aware JSP標籤的基類。

9.24  AbstractHtmlInputElementTag

       渲染HTML格式input元素的databing-aware JSP標籤的基類。

9.25  AbstractMultiCheckedElementTag

       爲實現databing-aware JSP標籤的類通用方法的抽象基類，這些JSP標籤使用‘checkbox’、‘radio’渲染多個HTML元素。

9.26  AbstractSingleCheckedElementTag

       爲實現databing-aware JSP標籤的類通用方法的抽象基類，這些JSP標籤使用‘checkbox’、‘radio’渲染一個單獨的HTML‘input’元素。

9.27  ButtonTag

       <button>標籤，渲染一個在HTML ‘button’標籤中的表單field label。

9.28  CheckboxesTag

       <checkboxes>標籤使用’checkbox’來渲染多個HTML ‘input’標籤。

9.29  CheckboxTag

       <checkboxes>標籤使用‘checkbox’來渲染一個HTML ‘input’標籤。

9.30  ErrorsTag

       <errors>標籤渲染在一個HTML ‘span’標籤中的域錯誤。

9.31  FormTag    

       <form>標籤渲染一個HTML ‘form’標籤，暴露一個binding path給內部的標籤用於綁定。

9.32  HiddenInputTag

       <hidden>標籤渲染一個HTML ‘input’標籤。

9.33  InputTag

       <input>標籤使用‘text’渲染一個HTML ‘input’標籤。

9.34  LabelTag

       <label>標籤渲染渲染在HTML ‘lablel’標籤中的form filed label。

9.35  OptionsTag

       <options>標籤渲染一列HTML ‘option’標籤。

9.36  OptionTag

       <option>標籤渲染單獨一個HTML ‘option’。

9.37  OptionWriter

       提供了渲染一列‘option’標籤功能性函數。這些標籤基於相同的源對象，這些對象要麼是數組、集合或者map。

9.38  PasswordInputTag

       <password>標籤使用‘password’類型來渲染HTML ‘input’標籤。

9.39  RadioButtonsTag

       <radiobuttons>標籤使用‘radio’類型來渲染多個HTML ‘input’標籤。

9.40  RadioButtonTag

       <radiobutton>標籤使用‘radio’渲染一個HTML ‘input’標籤。

9.41  SelectedValueComparator

       該類用來測試一個value是否和BindStatus#getValue匹配。

9.42  SelectTag

       <select>標籤渲染一個HTML ‘select’元素。

9.43  TagIdGenerator

       JSP標籤id生成器。

9.44  TagWriter

       將HTML內容寫入到一個Writer實例中。

9.45  TextareaTag

       <textarea>標籤，用來渲染一個HTML ‘textarea’。

9.46  ValueFormatter

       數據格式器，格式化數據以經過標籤標籤進行渲染。

 

10、web/servlet/theme

10.1  AbstractThemeResolver

       ThemeResolver實現類的抽象基類，對默認的主題名提供支持。

10.2  CookieThemeResolver

       使用客戶端cookie存儲的主題。

10.3  FixedThemeResolver

       默認的主題解析器，使用固定的主題，經過defaultThemeName屬性設置，即此屬性指定主題屬性文件的文件名。此解析器不能動態設置主題。

10.4  SessionThemeResolver    

       經過用戶會話來保持主題，每一個會話（session）僅需設置一次，全部請求共享主題，可是不能兩個會話共享。

10.5  ThemeChangeInterceptor

       該攔截器用來根據一個可配置的請求參數（默認的參數名爲：「theme」），來指定每一個請求當前使用的主題。

 

11、web/servlet/view

11.1  AbstractCachingViewResolver 

       帶有緩存功能的ViewResolver接口基礎實現抽象類，該類有個屬性名爲viewAccessCache的以 「viewName_locale」 爲key， View接口爲value的Map。

       該抽象類實現的resolveViewName方法內部會調用createView方法，方法內部會調用loadView抽象方法。

11.2  AbstractTemplateView    

       繼承自AbstractUrlBasedView抽象類，重寫了renderMergedOutputModel方法，在該方法中會調用renderMergedTemplateModel方法，renderMergedTemplateModel方法爲新定義的抽象方法。

       該抽象類有幾個boolean屬性exposeSessionAttributes，exposeRequestAttributes。 設置爲true的話會將request和session中的鍵值和值丟入到renderMergedTemplateModel方法中的model這個Map參數中。

       這個類是某些模板引擎視圖類的父類。 好比FreemarkerView，VelocityView。

11.3  AbstractTemplateViewResolver

       繼承自UrlBasedViewResolver，重寫了buildView方法，主要就是構造AbstractTemplateView以及爲它設置相應的屬性。

11.4  AbstractUrlBasedView

       繼承自AbstractView抽象類，增長了1個類型爲String的url參數。

11.5  AbstractView

       View接口的基礎實現類。

11.6  BeanNameViewResolver

       使用視圖的名字來解析視圖。

11.7  ContentNegotiatingViewResolver

       實現ViewResolver根據請求文件名或Accept頭解析視圖的界面。

11.8  DefaultRequestToViewNameTranslator

       RequestToViewNameTranslator就是一個請求解析器，他的每一個實現有各自的一個解析請求的算法，通過這個算法，從請求的url中得到一個字符串，將這個字符串做爲要顯示的jsp的名字，去jsp文件目錄中查找，找到就顯示，找不到才最終顯示404。

       在springmvc中默認使用的是一個名字爲DefaultRequestToViewNameTranslator（默認也只有這一個實現類），他解析請求的算法是將咱們的請求直接解析爲jsp的名字，而後從存放jsp的目錄中去找，好比咱們上面的請求是/view/hellojsp，那麼通過這個實現類的解析後獲得的即是/view/hellojsp這個字符串，有了這個值後，就會在執行一次就等同於在controller中return 「/view/viewjsp」同樣的效果，也就是去jsp目錄下的view文件夾下去找viewjsp.jsp文件，若是找到就顯示，找不到就404，由於咱們沒有這個文件，因此就最終404了。

11.9  InternalResourceView

       內部資源視圖.經過RequestDispatcher的include(request, response);方法直接解析。

11.10  InternalResourceViewResolver

       內部資源視圖解析器。比較經常使用的視圖解析器，能夠配置先後綴方便代碼簡化，之前使用的很是多，如今先後端分離後幾乎不使用了。

11.11  JstlView

       JSTL視圖，繼承自InternalResourceView，該類大體上與InternalResourceView類一致。

11.12  RedirectView

       繼承自AbstractUrlBasedView，並實現SmartView接口。SmartView接口定義了1個boolean isRedirectView();方法。

       該視圖的renderMergedOutputModel方法主要就是經過response.sendRedirect進行重定向。

11.13  ResourceBundleViewResolver

       實現ViewResolver它使用bean定義ResourceBundle，由bundle基本名稱指定。一般，您能夠在屬性文件中定義bundle，該屬性文件位於類路徑中。默認文件名是views.properties。

11.14  UrlBasedViewResolver

       繼承自AbstractCachingViewResolver抽象類、並實現Ordered接口的類，是ViewResolver接口簡單的實現類。

11.15  ViewResolverComposite

       ViewResolver接口實現類整體的就有四大類（StaticViewResolver 除外 用於單元測試）：BeanNameViewResolver、ContentNegituatingViewResolver、AbstractCachingViewResolver、ViewResolverComposite。

       ViewResolverComposite: 是包含其餘幾種的組合類。

11.16  XmlViewResolver

       實現ViewResolver它接受使用與Spring的XML bean工廠相同的DTD使用XML編寫的配置文件。默認配置文件是/WEB-INF/views.xml。

11.17  AbstractPdfStamperView

       Pdf視圖抽象基類，可經過Bruno Lowagie的iText庫將數據導出到pdf文件。

11.18  AbstractPdfView

       輸出格式爲pdf的視圖的父類。

11.19  AbstractXlsView

       傳統XLS格式的Excel文檔視圖的父類，兼容Apache POI 3.5或者更高的版本。

11.20  AbstractXlsxStreamingView

       Office 2007版的XLSX格式的Excel文檔視圖的父類，使用POI的流變體。

       Apache POI是基於Office Open XML標準（OOXML）和Microsoft的OLE 2複合文檔格式（OLE2）處理各類文件格式的開源項目。 簡而言之，您可使用Java讀寫MS Excel文件，可使用Java讀寫MS Word和MS PowerPoint文件。

11.21  AbstractXlsxView

       Office 2007版的XLSX格式的Excel文檔視圖的父類（被POI-OOXML支持）。和Apache POI 3.5或者更高的版本兼容。

 

web/servlet/view/feed

11.22  AbstractAtomFeedView

       Atom Feed視圖的父類，使用ROME包。

       Rome是爲RSS聚合而開發的開源包，它能夠支持0.9一、0.9二、0.9三、0.9四、1.0、2.0，能夠說rss的版本基本上都支持了。

       RSS是站點用來和其餘站點之間共享內容的一種簡易方式（也叫聚合內容），一般被用於新聞和其餘按順序排列的網站，例如Blog。

11.23  AbstractFeedView

       Atom 和RSS Feed視圖的父類，使用ROME包。

11.24  AbstractRssFeedView

       RSS Feed視圖的父類，使用ROME包。

 

web/servlet/view/freemarker

11.25  FreeMarkerConfig

       實現該接口的對象會在web環境中對FreeMarker配置對象進行配置和管理。該接口實現類被FreeMarkerView檢測和使用。

11.26  FreeMarkerConfigurer

       JavaBean，經過configLocation、freemarkerSettings、templateLoaderPath來爲web使用配置FreeMarker。

11.27  FreeMarkerView

       使用FreeMarker模板引擎的視圖。

       FreeMarker是一個用Java語言編寫的模板引擎，它基於模板來生成文本輸出。FreeMarker與Web容器無關，即在Web運行時，它並不知道Servlet或HTTP。它不只能夠用做表現層的實現技術，並且還能夠用於生成XML，JSP或Java 等。

       簡而言之，Freemarker就是在Jave Web開發中以模板的方式在頁面展現從服務器端獲取的信息。

11.28  FreeMarkerViewResolver

       UrlBasedViewResolver的子類，支持FreeMarkerView和其自定義子類。

 

web/servlet/view/groovy

11.29  GroovyMarkupConfig    

       實現該接口的對象負責配置和管理Groovy MarkupTemplateEngine，用於在web環境中自動查找。該接口實現類被GroovyMarkupView檢測和實現。

11.30  GroovyMarkupConfigurer

       繼承自TemplateConfiguration、實現Spring MVC的GroovyMarkupConfig接口，用來建立在web應用中使用的MarkupTemplateEngine。配置該類最基本的方式是經過設置「resourceLoaderPath」。

11.31  GroovyMarkupView

       繼承自AbstractTemplateView，基於Groovy XML/XHTML標記模板。

       Groovy 是 用於Java虛擬機的一種敏捷的動態語言，它是一種成熟的面向對象編程語言，既能夠用於面向對象編程，又能夠用做純粹的腳本語言。使用該種語言沒必要編寫過多的代碼，同時又具備閉包和動態語言中的其餘特性。

       Groovy是JVM的一個替代語言（替代是指能夠用 Groovy 在Java平臺上進行 Java 編程），使用方式基本與使用 Java代碼的方式相同，該語言特別適合與Spring的動態語言支持一塊兒使用，設計時充分考慮了Java集成，這使 Groovy 與 Java 代碼的互操做很容易。

11.32  GroovyMarkupViewResolver

       繼承自AbstractTemplateViewResolver，支持GroovyMarkupView（如：Groovy XML/XHTML markup templates）和它的子類。

 

web/servlet/view/json

11.33  AbstractJackson2View

       基於Jackson和內容類型無關的AbstractView接口實現類的抽象基類。兼容Jackson 2.6或者更高的版本。

11.34  MappingJackson2JsonView

       Spring MVC 視圖，使用Jackson 2 的ObjectMapper爲當前的請求，經過序列化model來渲染JSON內容。

 

web/servlet/view/script

11.35  RenderingContext

       傳給ScriptTemplateView的上下文，渲染函數，使得應用的上下文、地區、模板載入器、url在腳本端均可獲取。

11.36  ScriptTemplateConfig    

       實現該接口的類用來配置和管理JSR-223腳本引擎，用於在web環境中進行自動查找。該類被ScriptTemplateView檢測和使用。

11.37  ScriptTemplateConfigurer

       Spring MVC的ScriptTemplateConfig接口的實現類，用來在web應用中建立腳本引擎。

11.38  ScriptTemplateView

       AbstractUrlBasedView的子類，設計用來基於一個JSR-223腳本引擎來運行任意的模板庫。

11.39  ScriptTemplateViewResolver

       UrlBasedViewResolver子類，支持ScriptTemplateView及其子類。

 

web/servlet/view/tiles3

11.40  AbstractSpringPreparerFactory

       org.apache.tiles.preparer.PreparerFactory接口的抽象實現類，獲取當前的Spring WebApplicationContext容器，實現方法getPreparer(String,WebApplicationContext)。

       Apache Tiles是表現層的佈局引擎。Tiles 是複合視圖模式（Composite View pattern）的一個實現。Tiles將該模式添加到本身的概念中是該模式具體化。Tiles的實現是以複合式模式爲理論。概念包括：Template，Attribute和Definition、View Preparer 。

       一、模板（Template）：在Tiles中，模板（Template）是一個頁面的佈局部分。你能將一個頁面結構當作是由不一樣的須要填補空白組成。

       二、屬性（Attribute）：屬性是模板中的空白，它在你的應用程序中被填充到模板中。屬性能夠是如下三種類型：

       string:屬性是string的話，會將string直接呈如今頁面。

       template:屬性是一個模板（Template），有無屬性都行。若是有屬性的話，你也要將他們填充後再呈現頁面。

       definition:它是一個可重複使用組成的頁面，包含全部的屬性來填充以呈現頁面。

       三、定義（definition）：定義是呈現給最終用戶的組合物；本質上，一個定義是由一個模板和徹底或部分填充的屬性組成的。說白了就是：一個定義是由一個模板和屬性組成的。

       若是全部的「屬性」都填充了，它將能夠呈現給最終用戶。

       若是不是全部的屬性都填充了，這個定義稱爲「抽象定義」（abastract definition），它能夠被用做「父定義」，讓其餘「定義」繼承，失去的「屬性」能在運行時填充。

       四、視圖助手（View Preparer）：有時候一個定義在呈現以前須要「預處理」。例如，顯示一個menu時，menu的結構必須被建立而且已經保存在request範圍內。爲了達到「預處理 」，視圖助手將會被用到，視圖助手將在呈現定義以前被調用，所以在將「定義」呈現所需的東西都會被正確的「預處理 」。

11.41  SimpleSpringPreparerFactory

       Tiles的PrepareFactory接口實現類，用來建立視圖助手實例。

11.42  SpringBeanPreparerFactory

       Tiles的PrepareFactory接口實現類，從Spring的ApplicationContext容器中獲取視圖助手bean的名字和beans。

11.43  SpringLocaleResolver

       Tiles的LocaleResolver適配器，代理Spring的LocaleResolver。

11.44  SpringWildcardServletTilesApplicationContext

       Tiles ServletApplicationContext中的Spring特定的子類。

11.45  TilesConfigurer

       爲Spring框架配置Tiles 3.X的幫助類。

11.46  TilesView

       視圖接口的實現類，經過Tiles 請求API進行渲染。

11.47  TilesViewResolver

       UrlBasedViewResolver的子類，支持TilesView（如Tiles定義）及其子類。

 

web/servlet/view/xml

11.48  MappingJackson2XmlView

       Spring MVC的視圖，使用Jackson 2的XmlMapper，爲當前的請求經過序列化model來渲染XML內容。

11.49  MarshallingView

       Spring MVC的視圖，渲染響應的上下文做爲marshalling的結果。

       marshal:直譯爲「編排」，在計算機中特 指將數據按某種描述格式編排出來，一般來講通常是從非文本格式到文本格式的數據轉化。unmarshal天然是指marshal的逆過程。好比在WebService中，咱們須要把java對象以xml方式表示並在網絡間傳輸，把java對象轉化成xml片斷的過程就是marshal。

 

web/servlet/view/xslt

11.50  XsltView

       XSLT-driven視圖，容許響應上下文被渲染，做爲XSLT轉換的結果。

11.51  XsltViewResolver

       ViewResolver的實現類，經過將提供的視圖名稱轉換成XSLT stylesheet的URL，來進行XsltView實例的解析。

 

 拓展閱讀：

　　Spring框架之beans源碼徹底解析
　　Spring框架之AOP源碼徹底解析
　　Spring框架之jms源碼徹底解析
　　Spring框架之spring-web http源碼徹底解析
　　Spring框架之spring-web web源碼徹底解析
　　Spring源碼深度解析之Spring MVC