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

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

        spring-web是Spring webMVC的基礎，由http、remoting、web三部分組成，核心爲web模塊。http模塊封裝了http協議中的client/server端的request請求/response響應，編解碼，一些格式的轉換（如cbor、Rss、json、xml）。remoting模塊負責遠程調用，包括caucho、httpinvoker、jaxws。

        spring-web的web模塊封裝了快速開發spring-web須要的基礎組件。包括：Initializer、accept、bind、client、context、cors、filter、jsf、method、multipart、server、util。

        Initializer部分：主要經過web/目錄下面的SpringServletContainerInitializer和WebApplicationInitializer作初始化的工做（例如註冊servlet或者filtes等）。

        accept部分：主要用來負責協商http內容的MIME TYPE是否知足要求的。同一資源能夠有多種表現形式，好比xml、json等。具體使用哪一種表現形式，是能夠協商的。這是RESTfull的一個重要特性，Spring Web MVC也支持這個功能。

        bind部分：數據綁定部分，將不一樣類型的http請求上的數據設置到特定的對象上，如javabean等，支持multipart的綁定。綁定支持兩種方式：編程式和註解式。

        client部分：客戶端部分，核心類RestTemplate，與許多其餘Spring 模板類（例如JdbcTemplate、JmsTemplate）設計原則相同，爲執行復雜任務提供了一種具備默認行爲的簡化方法。

        context部分：上下文部分，包含了一系列web應用的WebApplicationContext，不一樣功能的監聽器等。

        cors部分：對cors跨域資源操做提供了支持。

        filter部分：封裝了各類不一樣的過濾器。

        jsf部分：增長了對一種以組件爲中心的用戶界面構建方法的頁面表示技術JSF的支持。

        method部分：提供給spring mvc使用的方法處理類。

        multipart部分：對rfc1867爲http協議新增的文件上傳功能multipart/form-data提供支持。

        server部分：服務器部分。包括ServerWebExchange、WebSession、WebFilter、WebHandler等類。

        util部分：提供了公共的工具類。

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

 

1、web/

1.1  SpringServletContainerInitializer

        servlet規範規定，在容器啓動時，會經過ServletContainerInitializer的實現類來作初始化的工做（例如註冊servlet或者filtes等）。

        具體使用方法爲：

        一、實現ServletContainerInitializer接口。（SpringServletContainerInitializer類）

        二、在對應的jar包的META-INF/services 目錄建立一個名爲javax.servlet.ServletContainerInitializer的文件。（..\spring-web\src\main\resources\META-INF\services\，tomcat默認就會去讀取META-INF）

        三、ServletContainerInitializer文件內容爲實現類的全類名，即包名+類名。（內容爲：org.springframework.web.SpringServletContainerInitializer）

        SpringServletContainerInitializer類實現了ServletContainerInitializer接口。這意味着servlet（3.0以上版本）容器啓動時，該類被容器自動加載並執行其onStartup(webAppInitializerClasses, servletContext)方法。

　　SpringServletContainerInitializer 類使用了@HandlesTypes(WebApplicationInitializer.class)註解。代表給onStartup方法傳遞了類路徑下全部實現了WebApplicationInitializer類。spring將初始化全部這些具體實現類，並調用它們的WebApplicationInitializer#onStartup(servletContext)方法。這些類能夠在其onStartup方法中，經過可編程方式註冊和初始化servlet組件。

        簡單介紹下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接口的類，或者說，全部想要處理網絡請求的類，都要回答三個問題：初始化要作什麼，銷燬時要作什麼，接受到請求時要作什麼。

        實現了servlet的類能處理請求嗎，不能。那請求怎麼來到servlet呢，經過servlet容器，好比咱們最經常使用的tomcat。因此須要將servlet部署到一個容器中，不然servlet根本不會起做用。

        容器（如tomcat）纔是與客戶端直接打交道的，它監聽了端口，請求過來後，根據url等信息，肯定要將請求交給哪一個servlet去處理，而後調用那個servlet的service方法，service方法返回一個response對象，tomcat再把這個response返回給客戶端。

1.2  WebApplicationInitializer

        如今JavaConfig配置方式在逐步取代xml配置方式。而WebApplicationInitializer能夠看作是Web.xml的替代，它是一個接口。經過實現WebApplicationInitializer，在其中能夠添加servlet，listener等，在加載Web項目的時候會加載這個接口實現類，從而起到web.xml相同的做用。

        WebApplicationInitializer的調用執行要經過SpringServletContainerInitializer類實現。SpringServletContainerInitializer 類使用了@HandlesTypes(WebApplicationInitializer.class)註解。代表給其onStartup方法傳遞了類路徑下全部實現了WebApplicationInitializer類。spring將初始化全部這些具體實現類，並調用他們的WebApplicationInitializer#onStartup(servletContext)方法。

        進入SpringServletContainerInitializer 類的onStartup方法：

        一、先判斷webAppInitializerClasses這個Set是否爲空。

        二、若是不爲空的話，找到這個Set中不是接口，不是抽象類，而且是WebApplicationInitializer接口實現類的類，將它們保存到List中。

        三、判斷這個list是否爲空，爲空則記錄日誌，返回。

        四、不爲空的話就按照必定的順序排序，並將它們按照必定的順序實例化。調用每個WebApplicationInitializer的onStartup(servletContext)方法執行。

1.3  HttpRequestHandler

        Http請求處理器，一個專門用來處理Http請求，並生成對應的響應的處理器。只有一個handlerRequest方法，其處理邏輯隨子類的實現不一樣而不一樣。該接口相似於javaEE中的Servlet，目的都是處理請求，產生響應結果。

1.4  HttpMediaTypeException

        和媒體類型(Media Types)相關的異常的抽象基類。

1.5  HttpMediaTypeNotAcceptableException

        客戶端請求指望響應的媒體類型與服務器響應的媒體類型不一致形成的。例如客戶端但願返回的媒體類型是json對象（application/json），服務器返回的媒體類型是一個普通的json字符串（text/plain）；又或者是客戶端但願返回的是html頁面，服務器返回的倒是json對象。

1.6   HttpMediaTypeNotSupportedException

        每條HTTP 請求報文都包含一個方法。這個方法會告訴服務器要執行什麼動做，不一樣於GET、HEAD、DELETE方法，PUT、POST、PATCH方法須要發送客戶端數據，HttpRequestHandler處理這三種請求報文時，客戶端數據的類型不被支持拋出的異常。

1.7  HttpRequestMethodNotSupportedException

        當一個請求報文處理器不支持該請求報文的方法時拋出的異常。一些常見的HTTP方法：

        GET：從服務器向客戶端發送命名資源；

        HEAD：僅發送命名資源響應中的HTTP 首部；

        DELETE：從服務器中刪除命名資源；

        PUT：未來自客戶端的數據存儲到一個命名的服務器資源中去；

        POST：將客戶端數據發送到一個服務器網關應用程序；

        PATCH：方法是新引入的，是對PUT方法的補充，用來對已知資源進行局部更新。

1.8  HttpSessionRequiredException

        一個HttpRequestHandler須要session，但從當前請求得到不到session時拋出的異常。

 

2、web/accept

accept部分就是負責協商http內容的Mime Type是否知足要求的。幾個HTTP請求報文示例：

　　GET /tools.html HTTP/1.0

　　User-agent: Mozilla/4.75 [en] (Win98; U)

　　Host: www.joes-hardware.com

　　Accept: text/html, image/gif, image/jpeg

　　Accept-language: en

 

　　GET /seasonal/index-fall.html HTTP/1.1

　　Host: www.joes-hardware.com

　　Accept: *

 

　　HEAD /seasonal/index-fall.html HTTP/1.1

　　Host: www.joes-hardware.com

　　Accept: *

 

rfc-2616中HTTP/1.1中標準頭域Accept的語法和語義：

        對於實體頭域來講，發送者和接收者都既能夠指客戶端也能夠指服務器，取決於誰發送和誰接收此實體。

        Accept請求頭域被用於指定哪些媒體類型的響應對請求端是可接受的。Accept頭域被用於指明請求只對某些指望的媒體類型有效，例如請求一個內嵌的圖像。

       Accept           = "Accept" ":"

                                  #( media-range [ accept-params ] )

       media-range  = ( "*/*"

                                 | ( type "/" "*" )

                                 | ( type "/" subtype )

                                  ) *( ";" parameter )

       accept-params  = ";" "q" "=" qvalue *( accept-extension )

       accept-extension = ";" token [ "=" ( token | quoted-string ) ]

　　星號」*」字符用於把媒體類型組合成一個範圍，「*/*」指明瞭全部的媒體類型而「type/*」指明type類型的全部子類型。Media-range可能包含一個媒體類型參數。

　　每個media-range可能會跟隨一個或多個accept-params，以「q」參數指明一個相對的喜好程度的質量因子。經過第一個「q」參數（若是有的話）把accept-params和media-range參數分離。喜好程度質量因子容許用戶或用戶代理去指明對那個media-range 的相對喜好程度，qvalue的範圍是從0到1。缺省是q=1。

　　注意：利用「q」參數名字將媒體類型參數（譯註：media-range裏的parameter）和acceptextension分離開來是基於歷史的實踐。儘管這能防止任何以「q」命名的媒體類型參數應用於media-range 裏，但在一個media-range 裏使用「q」被認爲是不可能發生的，這是由於在IANA的媒體類型註冊表裏是沒有「q」參數的而且在Accept頭域裏利用媒體類型參數也是不多見。未來的媒體類型不被鼓勵任何以「q」命名的參數註冊。

　　例子：

      　　 Accept: audio/*; q=0.2, audio/basic

       該例應該被解釋成「我喜歡audio/basic，可是能夠給我發送任何audio類型若是它最容易獲得，但在喜好程度質量要降低80%」。

       若是沒有Accept頭域出現，那麼會假設客戶端能接受全部媒體類型。若是Accept頭域在請求消息裏出現，而且若是服務器根據聯合Accept頭域值發現它不能發送客戶端可接受的響應，那麼服務器應發送406（不可接受的）響應。

　　一個更加詳盡的例子以下：

      　　 Accept: text/plain; q=0.5, text/html,

               　　text/x-dvi; q=0.8, text/x-c

　　這可能被口頭地解釋成「text/html 和 text/x-c是更喜好的媒體類型，可是若是他們不存在，那麼發送text/x-dvi實體，但若是text/x-dvi也不存在，那麼發送text/plain實體。

        Media-range能被更具備特殊性的media-range或媒體類型覆蓋。若是多個media-range應用了一個特指的類型，那麼最具備特殊性的應該優先。例如：

      　　 　　Accept: text/*, text/html, text/html;level=1, */*

　　擁有下面的優先順序：

　　　　1) text/html;level=1

　　　　2) text/html

　　　　3) text/*

　　　　4) */*

　　一個媒體類型的喜好程度質量因子是和一個給定的媒體類型聯繫在一塊兒的，它是由查找能最高優先匹配那個媒體類型的media-range決定的。例如：

      　　 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,

              　　 text/html;level=2;q=0.4, */*;q=0.5

　　可能會引發下面值被聯繫：

     　　  text/html;level=1      = 1

     　　  text/html                  = 0.7

      　　 text/plain                 = 0.3

      　　 image/jpeg               = 0.5

     　　  text/html;level=2      = 0.4

   　　    text/html;level=3      = 0.7

　　注意：一個用戶代理可能會爲一個特定的media-range提供一個缺省的質量值的集合。然而，除非用戶代理是一個不能和其餘的呈現代理交互的封閉的系統，不然這個缺省的集合應該能夠被用戶可設置的。

 

　　什麼是內容協商：簡單點說，就是同一資源，能夠有多種表現形式，好比xml、json等，具體使用哪一種表現形式，是能夠協商的。這是RESTfull的一個重要特性，Spring Web MVC也支持這個功能。

　　Spring MVC REST展現內容（視圖）採用的幾種方式：

　　一、根據Http請求的header中的Accept屬性的值來判讀，好比：

        　　Accept: application/xml                將返回xml格式數據

       　　 Accept: application/json               將返回json格式數據

        　　優勢：是這種方式是理想的標準方式

        　　缺點：是因爲瀏覽器的差別，致使發送的Accept Header頭可能會不同，從而致使服務器不知要返回什麼格式的數據

　　二、根據擴展名來判斷，好比：

       　　 /mvc/test.xml  將返回xml格式數據

        　　/mvc/test.json 將返回json格式數據

       　　 /mvc/test.html 將返回html格式數據

        　　缺點：喪失了同一URL的多種展示方式。在實際環境中使用仍是較多的，由於這種方式更符合程序員的習慣

　　三、根據參數來判斷

        　　/mvc/test?format=xml        將返回xml數據

        　　/mvc/test?format=json       將返回json數據

        　　缺點：須要額外的傳遞format參數，URL變得冗餘繁瑣，缺乏了REST的簡潔風範

 

2.1  ContentNegotiationStrategy

        策略接口，用於從請求對象中的信息中判斷該請求的MediaType，即客戶端須要什麼類型（MediaType）的數據。

        該接口主要定義了一個方法List<MediaType> resolveMediaTypes(NativeWebRequest webRequest)。該方法接受一個參數NativeWebRequest（請求對象），分析該請求對象，從而得到它的MediaType列表。

2.2  FixedContentNegotiationStrategy

        該策略對象建立時固定了一組MediaType，無論請求對象是什麼，都返回這組MediaType。

2.3  HeaderContentNegotiationStrategy

        該策略對象分析請求頭部Accept 得出該請求的一組MediaType，若是請求頭部Accept未設置，返回的MediaType只包含*/*。

2.4  AbstractMappingContentNegotiationStrategy

        抽象基類，經過request獲取MediaType所需的Key，再根據Key找出對應的MediaType列表並返回。ParameterContentNegotiationStrategy，PathExtensionContentNegotiationStrategy，ServletPathExtensionContentNegotiationStrategy都是從該類派生出來的。

2.5  ParameterContentNegotiationStrategy

        根據一個查詢參數（query parameter）判斷請求的MediaType，該查詢參數缺省使用format`。

2.6  PathExtensionContentNegotiationStrategy

        根據請求URL 路徑中所請求的文件資源的擴展名部分判斷請求的MediaType。

2.7  ServletPathExtensionContentNegotiationStrategy

        擴展自PathExtensionContentNegotiationStrategy，將使用ServletContext#getMimeType(String)方法判斷請求MediaType。

 

2.8  MediaTypeFileExtensionResolver

        MediaType和路徑擴展名解析策略的接口，例如將 json 解析成 application/json 或者反向解析。

        主要定義了兩個方法：List<String> resolveFileExtensions(MediaType mediaType)方法，根據指定的mediaType返回一組文件擴展名；List<String> getAllFileExtensions()方法，返回該策略接口中註冊的全部文件擴展名。

2.9  MappingMediaTypeFileExtensionResolver

        此類維護一些Map以及提供操做的方法，它維護了一個文件擴展名和MediaType的雙向查找表。擴展名和MediaType的對應關係：一個MediaType對應N個擴展名；一個擴展名最多隻會屬於一個MediaType。

 

2.10  ContentNegotiationManager

        內容協商管理器ContentNegotiationManager是Spring Web一個重要的工具類，用於判斷一個請求的媒體類型MediaType列表。具體的作法是委託給它所維護的一組ContentNegotiationStrategy實例。實際上它自身也實現了接口ContentNegotiationStrategy，使用者能夠直接將它做爲一個ContentNegotiationStrategy使用。

        另外，ContentNegotiationManager也實現了接口MediaTypeFileExtensionResolver，從而能夠根據MediaType查找到相應的文件擴展名。這一點也是經過將任務委託給他所維護的一組MediaTypeFileExtensionResolver實例完成的。

        ContentNegotiationManager其實就是一個組合容器：組合了一組用於判斷請求媒體類型的ContentNegotiationStrategy實例；組合了一組用於根據媒體類型獲取文件擴展名的MediaTypeFileExtensionResolver實例，而ContentNegotiationManager又實現了這兩個接口ContentNegotiationStrategy/MediaTypeFileExtensionResolver。它對這兩個接口的功能實現最終委託給了它所維護的這些實例來完成。經過這種組合-委託模式，使用者本身不用維護這些單個的ContentNegotiationStrategy/MediaTypeFileExtensionResolver的實例以及對它們的組合使用了，而是隻須要經過使用ContentNegotiationManager便可。

2.11  ContentNegotiationManagerFactoryBean

        用來生成ContentNegotiationManager，並使用ContentNegotiationStrategy配置它。

 

3、web/bind

　　數據綁定部分，綁定的意思是將不一樣類型的http請求上的數據設置到特定的對象object上如javabean等，支持multipart的綁定。綁定支持兩種方式：編程式和註解式。其中，註解的實現由HandlerMethodInvoker觸發HandlerMethodResolver來完成。

3.1  WebDataBinder

        它的做用就是從web request 裏（注意：這裏指的web請求，並不必定就是ServletRequest請求）把web請求的parameters綁定到JavaBean上。

        Controller方法的參數類型能夠是基本類型，也能夠是封裝後的普通Java類型。若這個普通Java類型沒有聲明任何註解，則意味着它的每個屬性都須要到Request中去查找對應的請求參數。不管客戶端傳入的是什麼類型的請求參數，最終都要以字節的形式傳給服務端。而服務端經過Request的getParameter方法取到的參數也都是字符串形式的結果。因此，須要有一個把字符串形式的參數轉換成服務端真正須要的類型的轉換工具，在spring中這個轉換工具爲WebDataBinder。

3.2  ServletRequestDataBinder

        從Servlet Request裏把參數綁定到JavaBean裏，支持multipart。

3.3  ServletRequestParameterPropertyValues

        PropertyValue類：保存單個bean屬性的信息和值的對象。

        PropertyValues接口：包含一個或多個PropertyValue對象的容器。

        MutablePropertyValues類： PropertyValues接口的默認實現。

        ServletRequestParameterPropertyValues繼承自MutablePropertyValues，可以查找以特定前綴（好比""spring""）加前綴分割器（默認爲""_""）開頭的全部property values。

3.4  ServletRequestUtils

        操做request的工具類。主要用來從ServletRequest中析取被綁定的參數。

3.5  EscapedErrors

        各類錯誤類型包裝器，增長了automatic HTML escaping錯誤類型，在HTML視圖中方便使用。經過RequestContext的getErrors方法得到該wrapped的實例。

3.6  MethodArgumentNotValidException

        檢驗使用@Valid註解的參數失敗拋出的異常。

3.7  ServletRequestBindingException

        綁定時致命異常錯誤，這些綁定異常時不可恢復的。拓展自ServletException，爲了在Servlet資源（如Filter）中方便拋出。

3.8  MissingMatrixVariableException

        ServletRequestBindingException子類，當一個使用了@RequestMapping標註的方法在其參數中指望的一個matrix variable不在從URL提取出來的matrix variables時拋出的異常。

3.9  MissingPathVariableException

        ServletRequestBindingException的子類，當一個使用@RequestMapping註解標註的方法在其參數中指望的一個path variable不在從URL中提取出來的URI variables中拋出的異常。

3.10  MissingRequestCookieException

        ServletRequestBindingException的子類，當一個使用@RequestMapping註解標註的方法在其參數中指望的request cookie不存在時拋出的異常。

3.11  MissingRequestHeaderException

        ServletRequestBindingException的子類，當一個使用@RequestMapping註解標註的方法在其參數中指望的request header不存在時拋出的異常。

3.12  MissingServletRequestParameterException

　　ServletRequestBindingException的子類，表示缺失了一個參數。

3.13  UnsatisfiedServletRequestParameterException

　　ServletRequestBindingException的子類，表示一個不知足的參數的情況。

 

web/bind/support

3.14  WebExchangeDataBinder

　　Spring5.0後提供的，對Reactive編程的Mono數據綁定提供支持。

3.15  WebRequestDataBinder

　　它是用於處理Spring本身定義的org.springframework.web.context.request.WebRequest的，旨在處理和容器無關的web請求數據綁定。

 

3.16  WebDataBinderFactory

　　爲一個目標對象建立一個WebDataBinder實例。

3.17  DefaultDataBinderFactory

　　建立一個WebRequestDataBinder實例，並使用WebBindingInitializer對其進行初始化。

3.18  SpringWebConstraintValidatorFactory

　　該類實現了JSR-303 ConstraintValidatorFactory接口，委託給當前的Spring WebApplicationContext，用以建立自動裝配的ConstraintValidator實例。

　　WebApplicationContext是專門爲web應用準備的，容許從相對於web根目錄的路勁中裝載配置文件完成初始化工做。

　　ConstraintValidator接口實現類能夠完成自定義註解校驗。咱們每每使用註解的方式對傳入的參數進行一個格式的校驗，但已有的註解不是萬能的，咱們在實現當前業務邏輯判斷時會遇到已有註解不能校驗的邏輯，咱們則須要本身自定義校驗註解進行對參數的校驗。

 

3.19  WebBindingInitializer      

　　實現此接口重寫initBinder方法註冊的屬性編輯器是全局的屬性編輯器，對全部的Controller都有效。

3.20  ConfigurableWebBindingInitializer

　　實現了接口WebBindingInitializer，用來初始化WebDataBinder，將請求的參數轉化爲對應的JavaBean，而且會結合類型、格式轉換等API一塊兒使用。

 

3.21  SessionAttributeStore

　　日後臺session存儲model attributes的策略接口。

3.22  DefaultSessionAttributeStore

　　SessionAttributeStore接口的默認實現類，用來往Web Request session（好比HttpSession）存取數據的工具類。

3.23  SessionStatus

　　一個簡單的接口，能夠在處理方法中使用，使他們能夠判斷會話的處理是否結束，若是結束能夠緊接着進行一些清理工做。定義了兩個函數：setComplete()、isComplete()。

3.24  SimpleSessionStatus

　　SessionStatus接口的簡單實現，定義了一個標示變量complete。

3.25  WebArgumentResolver

　　參數解析器。

3.26  WebExchangeBindException

　　繼承自ServerWebInputException，當數據綁定和驗證失敗時拋出的異常。該異常類也實現了接口BindingResult（包括它的父接口Errors），容許直接分析綁定和驗證的錯誤。

 

web/bind/annotation     

3.27  ControllerAdvice

　　此註解用於class上。使用@ControllerAdvice聲明一個類來統一對全部@RequestMapping方法來作@ExceptionHandler、``@InitBinder以及@ModelAttribute`處理。

3.28  CookieValue

　　此註解用在@RequestMapping聲明的方法的參數上，能夠把HTTP cookie中相應名稱的cookie綁定上去。

3.29  CrossOrigin

　　此註解用在class和method上用來支持跨域請求，是Spring 4.2後引入的。

3.30  DeleteMapping

　　使用DELETE方式進行交互。

3.31  ExceptionHandler

　　此註解使用在方法級別，聲明對Exception的處理邏輯。能夠指定目標Exception。

3.32  GetMapping

　　將 HTTP GET 請求映射到特定的處理程序方法。

3.33  InitBinder

　　此註解使用在方法上，聲明對WebDataBinder的初始化（綁定請求參數到JavaBean上的DataBinder）。在controller上使用此註解能夠自定義請求參數的綁定。

3.34  Mapping

　　元註解，用來註解一個web mapping註解。

　　元註解的做用就是負責註解其餘註解。Java 5 定義了四個標準的元註解類型，用以提供對其它註解的功能說明。

　　　　@Target用於描述註解的範圍，即註解在哪用。

　　　　@Retention用於描述註解的生命週期，表示須要在什麼級別保存該註解，即保留的時間長短。

　　　　@Documented用於描述其它類型的annotation應該被做爲被標註的程序成員的公共API，所以能夠被例如javadoc此類的工具文檔化。

　　　　@Inherited用於表示某個被標註的類型是被繼承的。

3.35  MatrixVariable

　　此註解使用在請求handler方法的參數上，Spring能夠注入matrix url中相關的值。這裏的矩陣變量能夠出如今url中的任何地方，變量之間用分號分隔。

3.36  ModelAttribute

　　被該註解定義的方法，會在該方法所在的controller的任何目標方法執行以前執行。

3.37  PatchMapping

　　PatchMapping註解將 HTTP Patch請求映射到特定的處理程序方法。PATCH方法是新引入的，是對PUT方法的補充，用來對已知資源進行局部更新。

3.38  PathVariable

　　能夠使用@PathVariable將路徑中的參數綁定到請求方法參數上。

3.39  PostMapping

　　PostMapping註解將 HTTP Post請求映射到特定的處理程序方法。

3.40  PutMapping

　　將 HTTP Put 請求映射到特定的處理程序方法。

3.41  RequestAttribute

　　此註解用在請求handler方法的參數上，用於將web請求中的屬性（request attributes，服務器放入的屬性值）綁定到方法參數上。

3.42  RequestBody

　　將請求信息的body內容綁定在程序的實體類中。

3.43  RequestHeader

　　此註解用在請求handler方法的參數上，用於將http請求頭部的值綁定到參數上。

3.44  RequestMapping

　　這個註解會將 HTTP 請求映射到 MVC 和 REST 控制器的處理方法上。

3.45  RequestParam

　　此註解用在請求handler方法的參數上，用於將http請求參數的值綁定到參數上。

3.46  RequestPart

　　此註解用在請求handler方法的參數上，用於將文件之類的multipart綁定到參數上。

3.47  ResponseBody

　　此註解將controller的方法返回的對象經過適當的轉換器轉換爲指定的格式以後，寫入到response對象的body區，一般用來返回JSON數據或者是XML。

3.48  ResponseStatus

　　此註解用於方法和exception類上，聲明此方法或者異常類返回的http狀態碼。能夠在Controller上使用此註解，這樣全部的@RequestMapping都會繼承。

3.49  RestController

　　此註解用於class上，聲明此controller返回的不是一個視圖而是一個領域對象。其同時引入了@Controller和@ResponseBody兩個註解。

3.50  RestControllerAdvice

　　此註解用於class上，同時引入了@ControllerAdvice和@ResponseBody兩個註解。

3.51  SessionAttribute

　　註解用於方法的參數上，用於將session中的屬性綁定到參數。

3.52  SessionAttributes

　　此註解用於type級別，用於將JavaBean對象存儲到session中。通常和@ModelAttribute註解一塊兒使用。

 

3.53  RequestMethod

　　枚舉類型，枚舉了HTTP請求方法：GET、HEAD、POST、PUT、PATCH、DELETE、OPTIONS、TRACE。

　　@RequestMapping註解會將 HTTP 請求映射到 MVC 和 REST 控制器的處理方法上。該枚舉類在RequestMapping註解類method()方法中使用。

3.54  ValueConstants

　　用在bind註解中的常量值。該接口只定義一個字符串常量DEFAULT_NONE。String DEFAULT_NONE = "\n\t\t\n\t\t\n\ue000\ue001\ue002\n\t\t\t\t\n";由於不能在註解的屬性中使用null來表示空值，因此用這段16位Unicode的字符串（ValueConstants.DEFAULT_NONE）來表示空值，而且是不會發生這段字符串與用戶定義的值是同樣的狀況。避免了用戶給出的值卻被看成是空值的狀況。

 

4、web/client

4.1  RestTemplate

　　spring框架提供的RestTemplate類可用於在應用中調用rest服務，它簡化了與http服務的通訊方式，統一了RESTful的標準，封裝了http連接， 咱們只須要傳入url及返回值類型便可。相較於以前經常使用的HttpClient，RestTemplate是一種更優雅的調用RESTful服務的方式。簡而言之就是簡化了發起HTTP請求以及處理響應的過程，而且支持REST。

　　在Spring應用程序中訪問第三方REST服務與使用Spring RestTemplate類有關。RestTemplate類的設計原則與許多其餘Spring 模板類（例如JdbcTemplate、JmsTemplate）相同，爲執行復雜任務提供了一種具備默認行爲的簡化方法。

　　RestTemplate默認依賴JDK提供http鏈接的能力（HttpURLConnection），若是有須要的話也能夠經過setRequestFactory方法替換爲例如 Apache HttpComponents、Netty或OkHttp等其它HTTP library。

　　考慮到RestTemplate類是爲調用REST服務而設計的，所以它的主要方法與REST的基礎緊密相連，後者是HTTP協議的方法：HEAD、GET、POST、PUT、DELETE和OPTIONS。例如，RestTemplate類具備headForHeaders()、getForObject()、postForObject()、put()和delete()等方法。

4.2  RestOperations

　　指定了一套RESTful操做的接口，定義rest的各類操做，使用了大量的重載方法。該接口被RestTemplate類所實現。

　　REST： Representational State Transfer 直接翻譯：表現層狀態轉移。全稱是 Resource Representational State Transfer，通俗來說就是：資源在網絡中以某種表現形式進行狀態轉移。REST實際上只是一種設計風格，不是標準。基於REST構建的API就是Restful風格。

　　REST就是選擇經過使用http協議和uri，利用client/server model對資源進行CRUD（Create/Read/Update/Delete）增刪改查操做。

　　REST是面向資源的，而資源是經過URI進行暴露。URI的設計只要負責把資源經過合理的方式暴露出來就能夠了，對資源的操做與它無關，操做是經過HTTP動詞來體現的，因此REST經過URI暴露資源時，會強調不要再URI中出現動詞。如GET /rest/api/getDogs 這種設計就不符合REST風格，URI裏面包含了對資源的操做。 GET /rest/api/dogs知足了，它的操做是用標準的HTTP動詞來體現的。

　　REST很好的利用HTTP自己就有的一些特徵，如HTTP動詞、HTTP狀態碼、HTTP報頭等等。REST API是基於HTTP的，因此你的API應該去使用HTTP的一些標準。這樣全部的HTTP客戶端（如瀏覽器）纔可以直接理解你的API（也有其餘好處，如利於緩存）。REST實際上也很是強調應該利用好HTTP原本就有的特徵，而不是隻把HTTP當成一個傳輸層這麼簡單。

　　REST基礎概念：

　　　　一、在REST中的一切都被認爲是一種資源。

　　　　二、每一個資源由URI標識。

　　　　三、同一資源有多種表現形式。例如XML，JSON。

　　　　四、使用統一的接口。處理資源使用POST、GET、PUT、DELETE操做相似建立，讀取，更新和刪除（CRUD）操做。

　　　　五、因此的操做都是無狀態。每一個請求是一個獨立的請求。從客戶端到服務器的每一個請求都必須包含全部必要的信息，以便於理解。

4.3  RequestCallback

　　回調接口，用在操做ClientHTTPRequest的代碼中，包括操做請求的頭，寫入請求體。在內部被RestTemplate類使用，應用代碼中也有做用。幾個工廠方法以下（工廠方法：定義一個用於建立對象的接口，可是讓子類決定將哪個類實例化。將實例化邏輯委託給子類的方法）：

　　acceptHeaderRequestCallback(Class)}

　　RestTemplate#httpEntityCallback(Object)}

　　RestTemplate#httpEntityCallback(Object, Type)

4.4  AsyncRestTemplate

　　Web應用程序一般須要查詢外部REST服務。 在爲知足這些需求擴展應用程序時，HTTP和同步調用的本質會帶來挑戰：可能會阻塞多個線程，等待遠程HTTP響應。

　　AsyncRestTemplate類，在開發REST客戶端時容許非阻塞異步支持。是Spring的中心類，用於異步客戶端HTTP訪問。 公開與RestTemplate類似的方法，但返回ListenableFuture包裝器，而不是具體的結果。AsyncRestTemplate經過getRestOperations()方法公開一個同步RestTemplate，並與該RestTemplate共享其錯誤處理程序和消息轉換器。

　　默認狀況下，AsyncRestTemplate依靠標準JDK工具創建HTTP鏈接。 您能夠經過使用接受AsyncClientHttpRequestFactory的構造函數來切換使用其餘HTTP庫，例如Apache HttpComponents，Netty和OkHttp。默認的AsyncRestTemplate構造函數註冊一個SimpleAsyncTaskExecutor來執行HTTP請求。

4.5  AsyncRestOperations

　　指定了一套異步RESTful操做的接口，該接口被AsyncRestTemplate類所實現。

4.6  AsyncRequestCallback

　　回調接口，用在操做AsyncClientHttpRequest的代碼中，包括操做請求的頭，寫入請求體。在內部被AsyncRestTemplate類使用，應用代碼中也有做用。

 

4.7  ResponseErrorHandler

　　RestTemplate請求結果的異常處理器接口，接口的第一個方法hasError用於判斷HttpResponse是不是異常響應（經過狀態碼），接口的第二個方法handleError用於處理異常響應結果（非200狀態碼段）。

4.8  DefaultResponseErrorHandler

　　ResponseErrorHandler的默認實現。該實現類進行處理異常響應：從HttpResponse解析出Http StatusCode，若是狀態碼StatusCode爲null，就拋出UnknownHttpStatusCodeException異常；若是StatusCode存在，則解析出StatusCode的series，也就是狀態碼段（除了200段，其餘全是異常狀態碼），解析規則是StatusCode/100取整。根據狀態碼段，進一步拋出HttpClientErrorException。

4.9  ExtractingResponseErrorHandler

　　繼承自DefaultResponseErrorHandler，利用HttpMessageConverter對象轉換器 將HTTP錯誤響應轉換RestClientException，須要指定ResponseErrorHandler。

4.10  ResponseExtractor

　　解析HTTP響應的數據，從Response中提取數據，經過它來從ClientHttpResponse提取出指定內容（好比請求頭、請求Body體等）。

4.11  HttpMessageConverterExtractor

　　返回值提取器，實現接口ResponseExtractor。

4.12  MessageBodyClientHttpResponseWrapper

　　ClientHttpResponse的包裝類，經過讀取輸入流來判斷這個響應是報文否包括響應體，響應體長度是否爲0（如：empty）。

 

4.13  HttpServerErrorException

　　當接收到HTTP 5XX（服務器自己發生錯誤）拋出的異常。

4.14  HttpStatusCodeException

　　基於HttpStatus狀態碼異常的抽象類。

4.15  RestClientException

　　服務器響應錯誤致使請求失敗拋出的異常，由RestTemplate拋出，由ResponseErrorHandler#hasError(ClientHttpResponse)肯定與否。

4.16  RestClientResponseException

　　包含HTTP響應數據的異常的基類。

4.17  ResourceAccessException

　　I/O error發生時拋出的異常。

4.18  HttpClientErrorException

　　當接收到HTTP 4xx（客戶端錯誤狀態碼）時拋出的異常。

4.19  UnknownHttpStatusCodeException

　　當接收到一個未知的HTTP狀態碼時拋出的異常。

 

web/client/support

4.20  RestGatewaySupport

　　做爲須要REST access的應用類的基類使用，須要設置一個ClientHttpRequestFactory或者RestTemplate實例。

 

5、web/context

5.1  WebApplicationContext

　　Web應用上下文 ，專門爲web應用準備。它容許從相對於web根目錄的路徑中裝載配置文件完成初始化工做，從WebApplicationContext中能夠得到ServletContext的引用，整個Web應用上下文對象將做爲屬性放置在ServletContext中，以便web應用能夠訪問spring上下文。spring中提供WebApplicationContextUtils的getWebApplicationContext(ServletContext src)方法來得到WebApplicationContext對象。

5.2  ConfigurableWebApplicationContext

　　擴展了WebApplicationContext，它容許經過配置的方式實例化，同時設置兩個重要方法：

　　一、setServletContext(ServletContext context) 爲spring設置web應用上下文，以便二者整合。

　　二、setConfigLocations(String[]locations) 設置Spring配置的文件地址。

5.3  ConfigurableWebEnvironment

　　ConfigurableWebEnvironment:繼承自ConfigurableEnvironment，而且提供配置Servlet上下文和Servlet參數的功能。

5.4  ContextCleanupListener

　　Web應用監聽器，用來清除在Servlet上下文中使用事後殘留的屬性。ServletContext，當WEB服務器啓動時，會爲每個WEB應用程序建立一塊共享的存儲區域。ServletContext在WEB服務器啓動時建立，服務器關閉時銷燬。

5.5  AbstractContextLoaderInitializer

　　該抽象類只是爲了建立ContextLoaderListener，並經過抽象方法createRootApplicationContext建立的RootApplicationContext注入進Servlet容器事件中。

5.6  ContextLoader

　　應用程序上下文Context是Spring管理的bean所在的容器。上下文加載器ContextLoader負責構建應用程序上下文。

5.7  ContextLoaderListener

　　ContextLoaderListener監聽器的做用就是啓動Web容器時，自動裝配ApplicationContext的配置信息。由於它實現了ServletContextListener這個接口，在web.xml配置這個監聽器，啓動容器時，就會默認執行它實現的方法。

　　ContextLoaderListener調用contextInitialized方法完成Spring上下文初始化；調用contextDestroyed方法完成Spring上下文銷燬。可自行定義ContextLoaderListener的子類，進而在上下文啓動與銷燬時加入自定義功能。

5.8  ServletConfigAware

　　ServletConfig是針對特定的Servlet的參數或屬性。當一個servlet被實例化後，對任何客戶端在任什麼時候候訪問有效，但僅對本servlet有效，一個servlet的ServletConfig對象不能被另外一個servlet訪問。

　　容器初始化一個servlet時，會爲這個servlet建一個惟一的ServletConfig。容器從web.xml讀出Servlet初始化參數，並把這些參數交給ServletConfig，而後把ServletConfig傳遞給servlet的init(ServletConfig config)方法。

　　ServletConfigAware接口會被但願獲得ServletConfig通知的對象所實現。

 

5.9  ServletContextAware

　　當 容器啓動時，容器會爲每一個 Web 應用建立一個惟一的 ServletContext 對象表明當前的 Web 應用，該對象封裝了當前 Web 應用的全部信息。能夠利用該對象獲取 Web 應用程序的初始化信息、讀取資源文件等。

　　一個web應用對應一個ServletContext實例，一個WEB應用中的全部Servlet共享同一個ServletContext對象，所以Servlet對象之間能夠經過ServletContext對象通信。Spring中，凡是實現ServletContextAware接口的類，均可以取得ServletContext。

 

web/context/annotation

5.10  ApplicationScope

　　該註解是@Scope的一個特例。

　　若是把變量放到application裏，就說明它的做用域是application，它的有效範圍是整個應用。 整個應用是指從應用啓動，到應用結束。沒有說「從服務器啓動，到服務器關閉」，是由於一個服務器可能部署多個應用，固然你關閉了服務器，就會把上面全部的應用都關閉了。 application做用域裏的變量，它們的存活時間是最長的，若是不進行手工刪除，它們就一直能夠使用。

　　@Scope註解是spring Ioc容器中的一個做用域，在 Spring IoC 容器中具備如下幾種做用域：基本做用域singleton（單例）、prototype(多例)，Web 做用域（reqeust、session、globalsession），自定義做用域。

　　一、singleton單例模式： 全局有且僅有一個實例。

　　二、prototype原型模式：每次獲取Bean的時候會有一個新的實例。

　　三、request： request表示該針對每一次HTTP請求都會產生一個新的bean，同時該bean僅在當前HTTP request內有效。

　　四、session：session做用域表示該針對每一次HTTP請求都會產生一個新的bean，同時該bean僅在當前HTTP session內有效。

　　五、globalsession： global session做用域相似於標準的HTTP Session做用域，不過它僅僅在基於portlet的web應用中才有意義。

5.11  RequestScope     

　　該註解是@Scope的一個特例。

　　若是把變量放到request裏，就說明它的做用域是request，它的有效範圍是當前請求週期。 所謂請求週期，就是指從http請求發起，到服務器處理結束，返回響應的整個過程。

5.12  SessionScope

　　該註解是@Scope的一個特例。

　　若是把變量放到session裏，就說明它的做用域是session，它的有效範圍是當前會話。所謂當前會話，就是指從用戶打開瀏覽器開始，到用戶關閉瀏覽器這中間的過程。這個過程可能包含多個請求響應。也就是說，只要用戶不關瀏覽器，服務器就有辦法知道這些請求是一我的發起的，整個過程被稱爲一個會話（session），而放到會話中的變量，就能夠在當前會話的全部請求裏使用。

 

web/context/request      

5.13  AbstractRequestAttributes

　　RequestAttributes接口實現類的抽象基類，提供了一個請求完成機制用於請求特定的銷燬回調和更新訪問過的會話屬性。

5.14  AbstractRequestAttributesScope

　　實現Scope接口的抽象基類，Request和Session做用域對應的Scope接口實例均繼承自該基類。

5.15  SessionScope

　　做用域是session，它的有效範圍是當前會話。所謂當前會話，就是指從用戶打開瀏覽器開始，到用戶關閉瀏覽器這中間的過程。這個過程可能包含多個請求響應。

5.16  RequestScope

　　做用域是request，它的有效範圍是當前請求週期。 所謂請求週期，就是指從http請求發起，到服務器處理結束，返回響應的整個過程。

5.17  DestructionCallbackBindingListener

　　該類是Servlet HttpSessionBindingListener監聽器接口的適配器，封裝了一個會話銷燬的回調函數。HttpSessionBindingListener 能夠監聽實現了該接口的對象在 Session 中被添加或者移除的事件。

5.18  RequestContextListener

　　RequestContextListener用於監聽用戶的請求，當一個用戶發送一個請求，會將用戶的請求request對象保存在RequestContextHolder中的requestAttributesHolder本地線程池中，當用戶的請求執行完畢，會清除RequestContextHolder中的requestAttributesHolder本地線程池中的request對象。

5.19  RequestAttributes

　　Request相關的屬性對象的抽象。

5.20  FacesRequestAttributes

　　RequestAttributes適配器，適配一個JSF javax.faces.context.FacesContext，在JSF環境中使用，封裝當前的FacesContext。

5.21  ServletRequestAttributes

　　基於Servlet的RequestAttributes接口的實現。

5.22  WebRequest

　　Web請求的通用接口。 主要用於通用Web請求攔截器，使它們能夠訪問通用請求元數據，而不是用於實際處理請求。

5.23  NativeWebRequest

　　拓展自WebRequest接口，暴露真正的request和response對象。

5.24  ServletWebRequest

　　繼承ServletRequestAttributes、實現NativeWebRequest接口，適配javax.servlet.http.HttpServletRequest。

5.25  FacesWebRequest

　　WebRequest適配器，適配一個JSF javax.faces.context.FacesContext。須要JSF2.1或者更高的版本。

　　Java Server Faces (JSF) 是一種用於構建Java Web 應用程序的標準框架（是Java Community Process 規定的JSR-127標準）。它提供了一種以組件爲中心的用戶界面（UI）構建方法，從而簡化了Java服務器端應用程序的開發。

5.26  WebRequestInterceptor

　　WebRequestInterceptor接口同HandlerInterceptor接口同樣定義了三個方法：preHandle 、postHandle 以及afterCompletion。兩個接口的方法名都相同，調用次序也相同。即preHandle是在請求處理以前調用；postHandle實在請求處理以後，視圖渲染以前調用；afterCompletion是在視圖渲染以後調用。這三個方法都傳遞了同一個參數WebRequest 。

5.27  AsyncWebRequestInterceptor

　　AsyncWebRequestInterceptor繼承自WebRequestInterceptor接口，增長了一個異步請求處理時調用的回調方法。

5.28  RequestContextHolder

　　持有上下文的Request容器。經過RequestContextHolder的靜態方法能夠隨時隨地取到當前請求的request對象。

 

web/context/request/async

5.29  AsyncRequestTimeoutException

　　一個異步請求超時時拋出的異常。默認狀況下，這個異常會被當作503錯誤（503狀態碼，Service Unavailable，因爲超載或系統維護，服務器暫時的沒法處理客戶端的請求）進行處理。或者應用也能夠註冊一個DeferredResultProcessingInterceptor或CallableProcessingInterceptor來處理這個超時。註冊能夠經過MVC Java配置或MVC XML命名空間或直接經過RequestMappingHandlerAdapter的屬性。

5.30  AsyncWebRequest

　　異步請求接口，繼承NativeWebRequest，增長了支持異步請求處理的方法。

5.31  CallableInterceptorChain

　　調用CallableProcessingInterceptor的輔助類。

5.32  CallableProcessingInterceptor

　　Callable攔截器。

5.33  CallableProcessingInterceptorAdapter

　　抽象類實現CallableProcessingInterceptor接口，空實現。

5.34  DeferredResult

　　遞延結果，在兩個線程中傳遞的對象結果。實現Comparable接口以保證加入PriorityQueue隊列的正確順序。

5.35  DeferredResultInterceptorChain

　　調用DeferredResultProcessingInterceptor的輔助類

5.36  DeferredResultProcessingInterceptor

　　DeferredResult處理過程攔截器。在start async前，超時後/異步處理完成後/網絡超時後觸發攔截。

5.37  DeferredResultProcessingInterceptorAdapter

　　抽象類實現DeferredResultProcessingInterceptor，作空實現。

5.38  StandardServletAsyncWebRequest

　　繼承ServletWebRequest，實現AsyncWebRequest、AsyncListener，一個標準異步web請求的實現類。

5.39  TimeoutCallableProcessingInterceptor

　　繼承CallableProcessingInterceptorAdapter，實現超時處理方法。

5.40  TimeoutDeferredResultProcessingInterceptor

　　繼承DeferredResultProcessingInterceptorAdapter，實現超時處理方法。

5.41  WebAsyncManager

　　對Callables和DeferredResults啓動的管理，包括攔截器的注入，Excutor的注入等，異步處理的入口類。

5.42  WebAsyncTask

　　web異步任務，包含一個Callable類，一個超時時間，一個任務執行着或名字。

5.43  WebAsyncUtils

　　實現getAsyncManager()和createAsyncWebRequest()方法。

 

web/context/support     

5.44  AbstractRefreshableWebApplicationContext

　　實現了ConfigurableWebApplicationContext和ThemeSource接口，主要是用於web環境下。在web程序啓動的時候，提供一個configLocations屬性，經過ConfigurableWebApplicationContext接口來進行填充。實現該接口主要就是實現loadBeanDefinitions方法，來實現你本身的bean定義的加載邏輯。

5.45  AnnotationConfigWebApplicationContext

　　繼承自AbstractRefreshableWebApplicationContext，接受註解的類做爲輸入（特殊的@Configuration註解類，通常的@Component註解類，與JSR-330兼容的javax.inject註解）。容許一個一個的注入，一樣也能使用類路徑掃描。對於web環境，基本上是和AnnotationConfigApplicationContext等價的。使用AnnotatedBeanDefinitionReader來對註解的bean進行處理，使用ClassPathBeanDefinitionScanner來對類路徑下的bean進行掃描。

5.46  GenericWebApplicationContext

　　繼承自GenericApplicationContext，實現了ConfigurableWebApplicationContext和ThemeSource接口。該類設計的目的不是在web.xml中進行聲明式的安裝，而是編程式的安裝，例如使用WebApplicationInitializers來構建內嵌的上下文。該接口在ConfigurableWebApplicationContext的內容都是一個僞實現，調用其中的大多數方法都會拋出異常。他實現了ThemeSource接口，設計的目的主要是用於消息的國際化。

5.47  GroovyWebApplicationContext

　　繼承自AbstractRefreshableWebApplicationContext，實現了GroovyObject接口，接受能被GroovyBeanDefinitionReader所理解的groovy bean定義腳本和XML文檔配置。對於web環境，基本上是和GenericGroovyApplicationContext是等價的。對於根上下文，默認的配置文件路徑是/WEB-INF/applicationContext.groovy，對於命名空間爲test-servlet的上下文，默認的配置文件路徑是/WEB-INF/test-servlet.xml（就像servlet-name爲test的DispatcherServlet實例）。

5.48  StaticWebApplicationContext

　　繼承自StaticApplicationContext，實現了ConfigurableWebApplicationContext和ThemeSource接口。該接口主要是用在測試的環境，不用於產品環境。

5.49  XmlWebApplicationContext

　　繼承自AbstractRefreshableWebApplicationContext，用於web容器的應用上下文，接受能被XmlBeanDefinitionReader所理解的XML文檔配置。對於根上下文，默認的配置文件路徑是/WEB-INF/applicationContext.xml，對於命名空間爲test-servlet的上下文，默認的配置文件路徑是/WEB-INF/test-servlet.xml（就像servlet-name爲test的DispatcherServlet實例）。

 

5.50  ServletContextAttributeExporter

　　接受Spring定義的對象並將其公開爲 ServletContext屬性。一般，bean引用轉換成Spring定義的bean，這些bean做爲ServletContext屬性用。

　　ServletContext是javax.servlet包內定義的接口，Web容器會爲每一個Web程序構造一個實現該接口的對象實例，經過這個對象，Servlet能夠和web容器進行交互，如獲取Web容器版本號，經過Web容器的日誌機制記錄信息等；也能夠和同一Web程序的其餘Servlet進行交流，如能夠經過該對象的屬性來共享數據。

5.51  ServletContextAttributeFactoryBean

　　FactoryBean接口實現類，用來獲取一個指定的、存在的ServletContext屬性。

5.52  ServletContextParameterFactoryBean

　　FactoryBean接口實現類，用來獲取一個指定的、存在的ServletContext參數。

5.53  ServletContextAwareProcessor

　　FactoryBean接口實現類，用來獲取一個指定的ServletContext初始參數（在web.xml中定義的一個"context-param"）。

5.54  ServletContextLiveBeansView

　　LiveBeansView子類，在web應用中尋找全部的ApplicationContexts，暴露在ServletContext屬性中。

5.55  ServletContextResource

　　Spring提供了ServletContextResource類來訪問Web Context下相對路徑下的資源，ServletContextResource構造器接受一個表明資源位置的字符串參數，該資源位置是相對於Web應用根路徑的位置。

　　使用ServletContextResource訪問的資源， 也可經過文件IO訪問或URL訪問。經過java.io.File訪問要求資源被解壓縮，並且在本地文件系統中；但使用ServletContextResource進行訪問時則無須資源是否被解壓縮出來，或則直接存放在JAR文件中，總可經過Servlet容器訪問。

5.56  ServletContextPropertySource

　　Spring3.1提供了新的屬性管理API，並且功能很是強大且很完善，對於一些屬性配置信息都應該使用新的API來管理。

　　PropertySource是新的屬性管理API，一個抽象類，它包含一個source和一個name。source能夠是map或其餘，一般是一組鍵值對。

　　ServletContextPropertySource的屬性來自ServletContext上下文初始化參數等等。

5.57  ServletConfigPropertySource

　　ServletConfigPropertySource的源爲ServletConfig。

5.58  ServletContextResourceLoader

　　繼承自DefaultReourceLoader，重寫了getResourceByPath(String path)方法，該類的擴展功能是能夠從Servlet上下文的根目錄加載資源。

5.59  ServletContextResourcePatternResolver

　　ServletContext-aware的PathMatchingResourcePatternResolver的子類，可以經過ServletContext#getResourcePaths方法在web應用根目錄下查找全部匹配額資源。轉到其父文件系統查找其餘資源。

5.60  ServletContextScope

　　表示其生命週期、做用範圍是ServletContext。

　　ServletContext是一個全局的儲存信息的空間，服務器開始，其就存在，服務器關閉，其才釋放。request，一個用戶可有多個；session，一個用戶一個；而servletContext，全部用戶共用一個。

　　運行在Java虛擬機中的每個Web應用程序都有一個與之相關的Servlet上下文。ServletContext對象是Web服務器中的一個已知路徑的根。一個ServletContext對象表示了一個Web應用程序的上下文。

 

5.61  ContextExposingHttpServletRequest

　　HttpServletRequest裝飾器，使得在一個給定的WebApplicationContext中的全部Spring beans可以當成請求屬性進行存取。

5.62  HttpRequestHandlerServlet

　　一簡單的HttpServlet，代理一個在Spring root WebApplicationContext中定義的HttpRequestHandler bean。目標bean的名字必須和在web.xml中定義的HttpRequestHandlerServlet servlet-name匹配。

5.63  LiveBeansViewServlet

　　暴露LiveBeansView MBean的Servlet。爲當前的beans和它們在全部ApplicationContexts中的依賴作一個json鏡像。

　　一般咱們的Bean都是由Spring啓動時經過讀取配置加載進Spring容器的，咱們可讓Spring去管理咱們的Bean的生成、配置以及Bean與Bean之間的依賴。可是Spring一旦啓動完畢，再想去修改Bean的配置，就要用到JMX了。JMX技術的前提就是你得提供MBean，把咱們的Spring Bean變爲Mbean。

　　JMX（Java Management Extensions，即Java管理擴展）是一個爲應用程序、設備、系統等植入管理功能的框架。

5.64  RequestHandledEvent

　　請求處理事件，當一個請求被處理完成時發佈。

5.65  ServletRequestHandledEvent

　　RequestHandledEvent的子類，增長了servlet-specific上下文信息。

5.66  SpringBeanAutowiringSupport

　　工具類，主要用來對Spring Web Application上下文的類提供@Autowired注入功能。

5.67  StandardServletEnvironment

　　Environment接口的實現類，被Servlet web應用所使用。全部web相關的ApplicationContext類默認都會初始化一個實例。

5.68  WebApplicationContextUtils

　　抽象類，其提供了一個很便利的方法來獲取spring應用的上下文即WebApplicationContext。

5.69  WebApplicationObjectSupport

　　在WebApplicationContext中運行的應用對象的功能父類，提供了getWebApplicationContext()、getServletContext()、getTempDir()等方法。

 

6、web/cors

6.1  CorsConfiguration

　　具體封裝跨域配置信息的pojo。

6.2  CorsConfigurationSource

       request與跨域配置信息映射的容器。

6.3  CorsProcessor

　　具體進行跨域操做的類。

6.4  CorsUtils

　　基於CORS W3C recommendation的跨域資源請求處理的工具類。

6.5  DefaultCorsProcessor

　　CorsProcessor接口的默認實現。

6.6  UrlBasedCorsConfigurationSource

　　存儲request與跨域配置信息的容器。

 

web/cors/reactive

6.7  CorsConfigurationSource

　　 request與跨域配置信息映射的容器。

6.8  CorsProcessor

　　具體進行跨域操做的類。

6.9  CorsUtils

　　基於CORS W3C recommendation的跨域資源響應式請求處理的工具類。

6.10  CorsWebFilter

　　WebFilter接口的實現類，處理CORS 跨域中的 preflight 請求，藉助於CorsProcessor接口的實現類（默認爲DefaultCorsProcessor）對CORS請求進行攔截，目的是在CorsConfigurationSource容器中添加相關的CORS響應頭（好比Access-Control-Allow-Origin）。

6.11  DefaultCorsProcessor

　　CorsProcessor接口的默認實現。

6.12  UrlBasedCorsConfigurationSource

　　存儲響應式request與跨域配置信息的容器。

 

7、web/filter

　　Spring的web包中有不少過濾器，這些過濾器位於org.springframework.web.filter，實現了javax.servlet.Filter，實現方式有如下幾類：

        一、直接實現Filter，這一類過濾器只有CompositeFilter。

        二、繼承抽象類GenericFilterBean，該類實現了javax.servlet.Filter，這一類的過濾器只有一個，即DelegatingFilterProxy。

        三、繼承抽象類OncePerRequestFilter，該類爲GenericFilterBean的直接子類，這一類過濾器包括CharacterEncodingFilter、HiddenHttpMethodFilter、HttpPutFormContentFilter、RequestContextFilter和ShallowEtagHeaderFilter。

        四、繼承抽象類AbstractRequestLoggingFilter，該類爲OncePerRequestFilter的直接子類，這一類過濾器包括CommonsRequestLoggingFilter、Log4jNestedDiagnosticContextFilter和ServletContextRequestLoggingFilter。

 

7.1  CompositeFilter

　　混合過濾器，經過將加入各類過濾器邏輯集filters加入到該混合器，按照過濾鏈FilterChain進行統一處理。

 

7.2  GenericFilterBean

　　抽象類GenericFilterBean實現了javax.servlet.Filter、org.springframework.beans.factory.BeanNameAware、org.springframework.context.EnvironmentAware、org.springframework.web.context.ServletContextAware、org.springframework.beans.factory.InitializingBean和org.springframework.beans.factory.DisposableBean六個接口，做用以下：

　　一、Filter，實現過濾器。

　　二、BeanNameAware，實現該接口的setBeanName方法，便於Bean管理器生成Bean。

　　三、EnvironmentAware，實現該接口的setEnvironment方法，指明該Bean運行的環境。

　　四、ServletContextAware，實現該接口的setServletContextAware方法，指明上下文。

　　五、 InitializingBean，實現該接口的afterPropertiesSet方法，指明設置屬性的操做。

　　六、DisposableBean，實現該接口的destroy方法，用於回收資源。

7.3  DelegatingFilterProxy

　　該類其實並不能說是一個過濾器，它的原型是FilterToBeanProxy，即將Filter做爲spring的bean，由spring來管理。該類提供了在web.xml和application context之間的聯繫。

　　有如下幾個參數能夠設置：

　　一、contextAttribute，使用委派Bean的範圍，其值必須從org.springframework.context.ApplicationContext.WebApplicationContext中取得，默認值是session；其餘可選的有request、globalSession和application。

　　二、targetFilterLifecycle，是否調用Filter的init和destroy方法，默認爲false。

　　三、targetBeanName，被代理的過濾器的bean的名字，該bean的類必須實現Filter接口。

 

7.4  OncePerRequestFilter

　　該類爲GenericFilterBean的直接子類，它保留了GenericFilterBean中的全部方法並對之進行了擴展，在oncePerRequestFilter中的主要方法是doFilter。

7.5  CharacterEncodingFilter

　　該過濾器是配置編碼格式的。服務器啓動的時候就會建立Filter，將init-param中的參數加載，注入到CharacterEncodingFilter 類中，瀏覽器每次發送請求都會通過這個過濾器，而後調用doFilterInternal。

7.6  HiddenHttpMethodFilter

　　html中form表單只支持GET與POST請求，而DELETE、PUT等method並不支持，spring3添加了一個過濾器，能夠將這些請求轉換爲標準的http方法，使得支持GET、POST、PUT與DELETE請求。

7.7  HttpPutFormContentFilter

　　由HiddenHttpMethodFilter可知，html中的form的method值只能爲post或get，咱們能夠經過HiddenHttpMethodFilter獲取put表單中的參數鍵值對，而在Spring3中獲取put表單的參數鍵值對還有另外一種方法，即便用HttpPutFormContentFilter過濾器。

　　HttpPutFormContentFilter過濾器的做爲就是獲取put表單的值，並將之傳遞到Controller中標註了method爲RequestMethod.put的方法中。

　　與HiddenHttpMethodFilter不一樣，在form中不用添加參數名爲_method的隱藏域，且method沒必要是post，直接寫成put，但該過濾器只能接受enctype值爲application/x-www-form-urlencoded的表單。

7.8  RequestContextFilter

　　這是在Spring2.0時添加的類，經過LocaleContextHolder和RequestContextHolder把Http request對象基於LocalThread綁定到請求提供服務的線程上。如今通常使用DispatcherServlet這個中央分發器。如今RequestContextFilter過濾器主要用於第三方的Servlet，如JSF的FacesServlet。在Spring2.5以前都是使用該過濾器配置。

7.9  ShallowEtagHeaderFilter

　　ShallowEtagHeaderFilter是spring提供的支持ETag的一個過濾器，所謂ETag是指被請求變量的實體值，是一個能夠與Web資源關聯的記號，而Web資源能夠是一個Web頁，也能夠是JSON或XML文檔，服務器單獨負責判斷記號是什麼及其含義，並在HTTP響應頭中將其傳送到客戶端。

7.10  CorsFilter

　　跨域請求過濾器。

7.11  FormContentFilter

　　該過濾器爲HTTP的PUT、 PATCH和 DELETE請求解析表單數據，並暴露它爲Servlet請求參數。默認狀況下，Servlet spec僅要求對HTTP post進行此過濾。

7.12  RelativeRedirectResponseWrapper

　　Response包裝器，主要在RelativeRedirectFilter和 ForwardedHeaderFilter中使用。

7.13  ForwardedHeaderFilter

　　RFC 7239提出了一個標準化的Forwarded頭部，來攜帶反向代理的基本信息，用於替代X-Forwarded系列及X-Real-IP等非標準化的頭部。而ForwardedHeadersFilter提供了Forwarded頭部的轉發支持。

7.14  RelativeRedirectFilter

　　Servlet過濾器，將request 請求暴露給當前的線程，主要經過org.springframework.context.i18n.LocaleContextHolder和RequestContextHolder。該過濾器在web.xml中註冊。

 

7.15  AbstractRequestLoggingFilter

　　上下文信息過濾器 ，定義了兩個方法beforeRequest和afterRequest分別用於設定過濾先後執行的操做，它有三個子類，分別是CommonsRequestLoggingFilter、ServletContextRequestLoggingFilter和Log4jNestedDiagnosticContextFilter，這三個子類分別實現了各自的beforeRequest和afterRequest。

7.16  CommonsRequestLoggingFilter

　　繼承自AbstractRequestLoggingFilter，CommonsRequestLoggingFilter在過濾先後分別打印出一段debug的信息。

7.17  ServletContextRequestLoggingFilter

　　繼承自AbstractRequestLoggingFilter，ServletContextRequestLoggingFilter在過濾先後分別向日志文件中寫入一段日誌信息，日誌文件可由log4j.properties等指定。

 

web/filter/reactive。

7.18  ForwardedHeaderFilter

　　從"Forwarded"和"X-Forwarded-*"頭部提取值，用來重寫請求報文的URI。

7.19  HiddenHttpMethodFilter

　　響應式的webFilter，html中form表單只支持GET與POST請求，而DELETE、PUT等method並不支持，spring3添加了一個過濾器，能夠將這些請求轉換爲標準的http方法，使得支持GET、POST、PUT與DELETE請求。

7.20  ServerWebExchangeContextFilter

　　在響應式Context中插入屬性（屬性名EXCHANGE_CONTEXT_ATTRIBUTE），使得當前的ServerWebExchange可得到。在想訪問ServerWebExchange可是又不顯示的將其傳奇給參與處理請求的組件時有用。

　　ServerWebExchange 命名爲 服務網絡交換器 ，存放着重要的請求-響應屬性、請求實例和響應實例等等。

 

8、web/jsf

　　JavaServer Faces (JSF) 是一種用於構建Java Web 應用程序的標準框架（是Java Community Process 規定的JSR-127標準）。它提供了一種以組件爲中心的用戶界面（UI）構建方法，從而簡化了Java服務器端應用程序的開發。它是一種頁面表示技術。

8.1  DecoratingNavigationHandler

　　JSF NavigationHandler實現類的基類，用來裝飾原始的NavigationHandler。

8.2  DelegatingNavigationHandlerProxy

　　JSF NavigationHandler實現類，代理從Spring root WebApplicationContext容器中獲取的NavigationHandler bean。

　　在faces-config.xml文件中配置該handler proxy。以下：

　　　　<pre class=""code"">

　　　　<application>

 　　　　 ...

 　　　　 <navigation-handler>

 　　　　   org.springframework.web.jsf.DelegatingNavigationHandlerProxy

 　　　　 </navigation-handler>

 　　　　 ...

　　　　</application>

　　　　</pre>

8.3  DelegatingPhaseListenerMulticaster

　　JSF PhaseListener接口實現類，代理一個或多個從Spring root WebApplicationContext容器中獲取的Spring-managed PhaseListener bean。

　　在faces-config.xml文件中配置該listener multicaster。以下：

　　　　<pre class=""code"">

　　　　<application>

  　　　　...

  　　　　<phase-listener>

   　　　　 org.springframework.web.jsf.DelegatingPhaseListenerMulticaster

　　　　  </phase-listener>

　　　　  ...

　　　　</application>

　　　　</pre>

8.4  FacesContextUtils

　　爲一個JSF FacesContext提取Spring的root WebApplication提供功能函數。用於在基於JSF框架的代碼中訪問Spring的application context狀況下。

它相似於Spring中爲ServletContext提供功能函數的WebApplicationContextUtils，該類是爲FacesContext提供工具包。

 

web/jsf/el

8.5  SpringBeanFacesELResolver

　　JSF ELResolver接口的實現類，代理Spring的root WebApplicationContext。將名稱引用解析成Spring定義的beans。

　　在faces-context.xml文件中配置該解析器以下：

　　　　<pre class=""code"">

　　　　<application>

  　　　　...

  　　　　<el-resolver>

　　　　　　org.springframework.web.jsf.el.SpringBeanFacesELResolver

　　　　</el-resolver>

　　　　</application>

　　　　</pre>

8.6  WebApplicationContextFacesELResolver

　　繼承自JSF ELResolver，暴露Spring的WebApplicationContext一個實例，該實例變量的名字爲"webApplicationContext"。

 

9、web/method

9.1  ControllerAdviceBean

　　該類關於@ControllerAdvice註解的相關信息，spring管理bean，並不要求必定要對其進行實例化。使用函數findAnnotatedBeans(ApplicationContext)能夠來查找這種bean。這種bean能夠被任何對象建立，包括沒有加@ControllerAdvice註解的對象。

　　對於@ControllerAdvice，咱們比較熟知的用法是結合@ExceptionHandler用於全局異常的處理，但其做用不只限於此。ControllerAdvice拆分開來就是Controller Advice，Advice用於封裝一個切面全部屬性的，包括切入點和須要織入的切面邏輯。這裏ContrllerAdvice也能夠這麼理解，其抽象級別應該是用於對Controller進行「切面」環繞的，而具體的業務織入方式則是經過結合其餘的註解來實現的。@ControllerAdvice是在類上聲明的註解，其用法主要有三點：

　　結合方法型註解@ExceptionHandler，用於捕獲Controller中拋出的指定類型的異常，從而達到不一樣類型的異常區別處理的目的；

　　結合方法型註解@InitBinder，用於request中自定義參數解析方式進行註冊，從而達到自定義指定格式參數的目的；

　　結合方法型註解@ModelAttribute，表示其標註的方法將會在目標Controller方法執行以前執行。

9.2  HandlerMethod

　　封裝了處理函數的信息，包括getMethod()、getBean()。提供了對方法的參數、返回值、註解等等方便的存取方法。

9.3  HandlerTypePredicate

　　繼承自Predicate接口。Predicate接口是JDK8 提供的函數式接口，提供一個抽象方法test， 接受一個參數，根據這個參數進行一些判斷，返回判斷結果 true/false。

 

web/method/annotation

9.4  AbstractCookieValueMethodArgumentResolver

　　抽象基類，用來解析帶@CookieValue註解的方法參數。實現的子類會從請求報文中將cookie值提取出來。@CookieValue註解主要是將請求的Cookie數據，映射到功能處理方法的參數上。

9.5  AbstractNamedValueMethodArgumentResolver

　　該抽象基類用來從命名值（named value）解析方法參數。如請求參數、請求的頭部信息、URL路徑變量都是命名值。每個都有一個名字，一個必要的標誌、一個默認值。

9.6  AbstractWebArgumentResolverAdapter

　　使用@WebArgumentResolver的基類，用於向後兼容適配WebArgumentResolver。

9.7  ErrorsMethodArgumentResolver

　　處理Errors子類參數。

9.8  ExceptionHandlerMethodResolver

　　在一個給定的類（包括它全部的子類）中找到用@ExceptionHandler註解的方法，而後幫助解析一個給定Exceptin到exception types。

9.9  ExpressionValueMethodArgumentResolver

　　解析@Value註解的參數。

9.10  RequestHeaderMapMethodArgumentResolver

　　處理使用@RequestHeader註解的map參數。

9.11  RequestHeaderMethodArgumentResolver

　　解析使用@RequestHeader註解的參數，不包括map類型。

9.12  RequestParamMapMethodArgumentResolver

　　處理使用@RequestParam註解的map參數。

9.13  RequestParamMethodArgumentResolver

　　解析從request流中獲取值的參數，如@RequestParam、MultipartFile、Part，默認使用時解析基本參數。

9.14  SessionStatusMethodArgumentResolver

　　處理SessionStatus類型參數。

 

9.15  SessionAttributesHandler

　　SessionAttributesHandler用來處理@SessionAttributes註釋的參數，不過它只是作一些宏觀的事情，好比，哪一個Handler均可以緩存哪些參數、某個參數在當前的SessionAttributes中是否存在、如何同時操做多個參數等，而具體的存儲工做是交給SessionAttributeStore去作的，不過SessionAttributeStore並非保存數據的容器，而是用於保存數據的工具，具體保存數據的容器默認使用的是Session。

9.16  ModelFactory

　　ModelFactory是用來維護Model的，具體包含兩個功能：一、初始化Model。二、處理器執行後將Model中相應的參數更新到SessionAttributes中。

9.17  InitBinderDataBinderFactory

　　經過@InitBinder註解的方法來初始化WebDataBinder。

9.18  MapMethodProcessor

　　處理map類型參數。

9.19  ModelMethodProcessor

　　處理model類型參數。

9.20  ModelAttributeMethodProcessor

　　解析使用@ModelAttribute註解參數。

9.21  MethodArgumentConversionNotSupportedException

　　在解析一個方法參數時引起的異常，提供了到目標MethodParameter的訪問方法。

9.22  MethodArgumentTypeMismatchException

　　在解析一個控制器方法參數時引起的異常，提供了到目標MethodParameter的訪問方法。

 

web/method/support

9.23  CompositeUriComponentsContributor

　　UriComponentsContributor接口的實現類，包含了一列contributors，還封裝了一個特定的ConversionService用來將方法參數值轉化成字符串格式。

9.24  HandlerMethodArgumentResolver

　　參數解析器，主要用途：統一封裝登陸的用戶信息；進行數據綁定，參數驗證。Spring MVC處理入參靠的是HandlerMethodArgumentResolver這個接口，解析返回值靠的是HandlerMethodReturnValueHandler這個策略接口。

9.25  HandlerMethodArgumentResolverComposite

　　全部的參數解析器的鏈表，保存了springMVC提供的全部的參數解析器，採用職責鏈的模式來完成參數解析器的查找，並完成參數解析生成目標對象。

9.26  HandlerMethodReturnValueHandler

　　策略接口，用來對調用處理函數以後的返回值進行處理，總共就兩個方法；

　　boolean supportsReturnType();

　　void handleReturnValue()

9.27  HandlerMethodReturnValueHandlerComposite

　　springMVC提供的全部的HandlerMethodReturnValueHandler集合，它定義了一個鏈表用於存儲全部實現的HandlerMethodReturnValueHandler。

9.28  AsyncHandlerMethodReturnValueHandler

　　繼承自HandlerMethodReturnValueHandler，支持異步模式。

9.29  InvocableHandlerMethod

　　InvocableHandlerMethod是對HandlerMethod的擴展，基於一組HandlerMethodArgumentResolver從請求上下文中解析出控制器方法的參數值，而後調用控制器方法。

9.30  ModelAndViewContainer

　　能夠把它定義爲ModelAndView上下文的容器，它承擔着整個請求過程當中的數據傳遞工做，保存着Model和View。記錄HandlerMethodArgumentResolver和 HandlerMethodReturnValueHandler在處理Controller的handler方法時 使用的模型model和視圖view相關信息.。

9.31  UriComponentsContributor

　　幫助構建一個UriComponents，經過查找一個方法參數和參數值，決定目標URL哪一部分須要更新。

 

10、web/multipart

multipart/form-data請求說明：

　　先看一個帶multipart/form-data的請求報文。假設客戶端發送內容構造，接受文件的網頁程序位於 http://192.168.29.65/upload_file/UploadFile，咱們要發送一個二進制文件、一個文本框表單項、一個密碼框表單項。文件名爲 E:\s ，其內容以下：（其中的XXX表明二進制數據，如 01 02 03）abbXXXccc 客戶端應該向 192.168.29.65 發送以下內容：

　　POST /upload_file/UploadFile HTTP/1.1

　　Accept: text/plain, */*

　　Accept-Language: zh-cn

　　Host: 192.168.29.65:80

　　Content-Type:multipart/form-data;boundary=---------------------------7d33a816d302b6

　　User-Agent: Mozilla/4.0 (compatible; OpenOffice.org)

　　Content-Length: 424

　　Connection: Keep-Alive -----------------------------7d33a816d302b6

　　Content-Disposition:form-data;

　　name="userfile1";

　　filename="E:\s"Content-Type:

　　application/octet-stream abbXXXccc

　　-----------------------------7d33a816d302b6

 

　　Content-Disposition: form-data;

 

　　name="text1" foo

 

　　-----------------------------7d33a816d302b6

 

　　Content-Disposition: form-data;

 

　　name="password1" bar

 

　　—-----------------------------7d33a816d302b6—

 

注意這一行：

　　Content-Type: multipart/form-data; boundary=---------------------------7d33a816d302b6

　　根據 rfc1867，multipart/form-data是必須的。---------------------------7d33a816d302b6 是分隔符，分隔多個文件、表單項。 其中33a816d302b6 是即時生成的一個數字，用以確保整個分隔符不會在文件或表單項的內容中出現。前面的 ---------------------------7d 是 IE 特有的標誌。

 

　　在最初的http協議中，沒有文件上傳功能。rfc1867爲http協議添加了這個功能：multipart/form-data。客戶端瀏覽器按照此規範將用戶指定的文件發送到服務器。服務器端的網頁程序（如php、asp、jsp）按照此規範解析出用戶發送來的文件。

　　一、multipart/form-data的基礎方式是post，也就是說經過post組合方式來實現的。

　　二、multipart/form-data於post方法的不一樣之處在於請求頭和請求體。

　　三、multipart/form-data的請求頭必須包含一個特殊的頭信息：Content-Type，其值也必須爲multipart/form-data，同時還須要規定一個內容分割用於分割請求提中多個post的內容，如文件內容和文本內容是須要分隔開來的，否則接收方就沒法解析和還原這個文件了，具體的頭信息以下：

　　Content-Type: multipart/form-data; boundary=${bound} 

　　其中${bound} 是一個佔位符，表明咱們規定的分割符，能夠本身任意規定，但爲了不和正常文本重複了，儘可能要使用複雜一點的內容。如上例中的：--------------------7d33a816d302b6

　　四、multipart/form-data的請求體也是一個字符串，不過和post的請求提不一樣的是它的構造方式，post是簡單的name=value鍵值鏈接，而multipart/form-data是添加了分隔符等內容的構造體。

 

10.1  MultipartFile

　　繼承自InputStreamSource接口，表示在一個接收到的multipart請求中的上傳文件。文件的內容要麼存儲在內存中，要麼暫時存在磁盤中。若是有要求的話，無論採起方式，用戶都須要將文件的內容拷貝到會話級別或者永久性的存儲中。臨時性的存儲會在multipart請求處理完畢後進行清空。

10.2  MultipartFileResource

　　使MultipartFile適配org.springframework.core.io.Resource，以InputStream暴露文件內容，重寫方法contentLength()和getFilename()。

10.3  MultipartRequest

　　這個接口定義了multipart請求的存取操做。該接口被MultipartHttpServletRequest繼承。

10.4  MultipartHttpServletRequest

　　繼承自HttpServletRequest、MultipartRequest。在servlet request中提供了額外的方法，專門用來處理multipart內容，容許存取上傳的文件。

10.5  MultipartResolver

　　MultipartResolver 用於處理文件上傳，當收到請求時 DispatcherServlet 的 checkMultipart() 方法會調用 MultipartResolver 的 isMultipart() 方法判斷請求中是否包含文件。若是請求數據中包含文件，則調用 MultipartResolver 的 resolveMultipart() 方法對請求的數據進行解析，而後將文件數據解析成 MultipartFile 並封裝在    MultipartHttpServletRequest （繼承了 HttpServletRequest）對象中，最後傳遞給 Controller，在 MultipartResolver 接口中有以下方法：

　　boolean isMultipart(HttpServletRequest request); // 是不是 multipart

　　MultipartHttpServletRequest resolveMultipart(HttpServletRequest request); // 解析請求

　　void cleanupMultipart(MultipartHttpServletRequest request);

10.6  MultipartException

　　multipart解析失敗時拋出的異常。

10.7  MaxUploadSizeExceededException

　　繼承自MultipartException，當上傳的文件大小超過了最大限制時拋出的異常。

 

web/multipart/commons

10.8  CommonsFileUploadSupport

　　使用Apache的Commons FileUpload組件（1.2或者更高的版本）的multipart解析器的基類。

10.9  CommonsMultipartFile

　　MultipartFile接口的實現類，專爲Apache Commons FileUpload。

10.10 CommonsMultipartResolver

　　使用 commons Fileupload 來處理 multipart 請求。在使用時要引入相應的 jar 包。

 

web/multipart/support

10.11  MultipartFilter

　　Servlet過濾器，在root WebApplicationContext容器中經過一個MultipartResolver來解析multipart請求。

10.12  MultipartResolutionDelegate

　　HandlerMethodArgumentResolver接口實現類的一個通用代理，用來解析MultipartFile和Part參數。

10.13  AbstractMultipartHttpServletRequest

　　MultipartHttpServletRequest接口實現類的抽象基類。提供了對預生成的MultipartFile實例的管理。

10.14  DefaultMultipartHttpServletRequest

　　MultipartHttpServletRequest接口的默認實現，提供了對預生成的參數值的管理。該類在CommonsMultipartResolver中使用。

10.15  RequestPartServletServerHttpRequest

　　ServerHttpRequest接口的實現類，用來存取multipart請求的一部分。若是使用MultipartResolver配置，該部分就經過MultipartFile進行存取。若是使用Servlet 3.0進行multipart處理，該部分就經過ServletRequest.getPart進行存取。

10.16  StandardMultipartHttpServletRequest

　　Spring MultipartHttpServletRequest的適配器，包裝了一個ervlet 3.0 HttpServletRequest和它的Parts對象。

10.17  StandardServletMultipartResolver

　　基於 Servlet 3.0來處理 multipart 請求的，因此不須要引用其餘 jar 包，可是必須使用支持 Servlet 3.0的容器才能夠，以tomcat爲例，從 Tomcat 7.0.x的版本開始就支持 Servlet 3.0了。

10.18  ByteArrayMultipartFileEditor

　　個性化的java.beans.PropertyEditor，用來將MultipartFiles轉換成字節數組。

10.19  StringMultipartFileEditor

　　個性化的java.beans.PropertyEditor，用來將MultipartFiles轉換成字符串。容許指定使用的字符集。

10.20  MissingServletRequestPartException

　　當經過名字進行尋找一個"multipart/form-data" 請求的一部分，可是查找不到時拋出異常。

 

11、web/server

11.1  ServerWebExchange

　　ServerWebExchange名爲服務網絡交換器，是一個HTTP請求-響應交互的契約。提供對HTTP請求和響應的訪問，並公開額外的服務器端處理相關屬性和特性，如請求屬性。存放着重要的請求-響應屬性、請求實例和響應實例等等，有點像Context的角色。

11.2  ServerWebExchangeDecorator

　　ServerWebExchange裝飾類，用於須要封裝一個ServerWebExchange的類的基類，經過委託給包裝實例預實現全部方法。

11.3  DefaultServerWebExchangeBuilder

　　ServerWebExchange的內部接口ServerWebExchange.Builder的實現類。

11.4  WebSession

　　使用服務器端會話的主要約定，提供了同HTTP請求間會話屬性的訪問。建立WebSession實例並不會自動開啓一個會話。會話屬性添加完畢後，調用WebSession.start()函數纔開啓一個會話，繼而將會話id發送到客戶端（好比經過cookie）。

　　Cookie機制和Session機制用來惟一標識一個用戶，同時記錄該用戶的狀態。cookie是存儲子在客戶端，而Session是存儲在服務器端。

　　Session機制：採用的是在服務器端保持Http狀態信息的方案。服務器使用一種相似於散列表的結構（也可能就是使用散列表）來保存信息。

　　當程序須要爲某個客戶端的請求建立一個session時，服務器首先檢查這個客戶端的請求裏是否包含了一個session標識（即sessionId），若是已經包含一個sessionId則說明之前已經爲此客戶建立過session，服務器就按照session id把這個session檢索出來使用。若是客戶請求不包含sessionId，則爲此客戶建立一個session而且生成一個與此session相關聯的sessionId，這個sessionId將在本次響應中返回給客戶端保存。

11.5  WebFilter

　　使用攔截器鏈的方式來處理web請求的約定，主要被用來實現橫切請求，好比安全。

11.6  WebFilterChain

　　過濾器鏈，使得鏈中的web過濾器轉到下一個。

11.7  WebHandler

　　處理一個web請求。該接口定義了一個函數handle(ServerWebExchange exchange)。

11.8  WebExceptionHandler

　　對在執行處理ServerWebExchange時發生的異常進行處理。

 

11.9  ResponseStatusException

　　和指定的HTTP響應狀態碼相關的異常的基類。

11.10  ServerWebInputException

　　Spring web應用中遇到了響應狀態碼400（400 bad request，請求報文存在語法錯誤）拋出的異常。

11.11  MethodNotAllowedException

　　接收到響應狀態碼405（Method Not Allowed，請求行中指定的請求方法不能被用於請求相應的資源。）時拋出的異常。

11.12  ServerErrorException

　　HttpStatus爲INTERNAL_SERVER_ERROR（服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理。）時拋出的異常。

11.13  NotAcceptableStatusException

　　發生response status 406（Not Acceptable請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體。）拋出的異常。

11.14  MediaTypeNotSupportedStatusException

　　發生response status 415（Unsupported Media Type，對於當前請求的方法和所請求的資源，請求中提交的實體並非服務器中所支持的格式，所以請求被拒絕。）拋出的異常。

11.15  UnsupportedMediaTypeStatusException

　　發生response status 415（Unsupported Media Type，對於當前請求的方法和所請求的資源，請求中提交的實體並非服務器中所支持的格式，所以請求被拒絕。）拋出的異常。

 

web/server/adapter

11.16  AbstractReactiveWebInitializer

　　繼承自AbstractReactiveWebInitializer的類，能夠在servlet容器中安裝一個Spring Reactive Web Application。它經過將ServletHttpHandlerAdapter實例做爲一個servlet安裝到servler容器中。

11.17  DefaultServerWebExchange

　　ServerWebExchange接口的默認實現類。

11.18  ForwardedHeaderTransformer

　　處理HTTP頭部，包括提取和移除某些頭部鍵值對，或者只移除。

11.19  HttpWebHandlerAdapter

　　WebHandler的適配器。默認狀況下建立和配置一個DefaultServerWebExchange，而後調用目標WebHandler。

11.20  WebHttpHandlerBuilder

　　此構建器有兩個用途：

　　一是用來組裝由目標WebHandler組成的處理鏈，使用一系列的WebFilters來裝飾，更進一步的裝飾使用一系列的WebExceptionHandlers。

　　二是藉助HttpWebHandlerAdapter適配器使生成的處理器鏈適配一個HTTPHandler。

 

web/server/handler

11.21  DefaultWebFilterChain

　　WebFilterChain接口的默認實現，該類的每個實例都表示鏈中的一個對象，構造器DefaultWebFilterChain(WebHandler, List)初始化了整個鏈，並執行鏈中第一個對象。

11.22  ExceptionHandlingWebHandler

　　WebHandler裝飾器，調用一個或者多個WebExceptionHandlers。

11.23  FilteringWebHandler

　　經過WebFilter進行過濾處理的類，相似於Servlet中的Filter。

11.24  ResponseStatusExceptionHandler

　　經過設置響應的狀態碼來處理ResponseStatusException類型的異常。

11.25  WebHandlerDecorator

　　WebHandler的裝飾器，利用裝飾模式實現相關功能的擴展。

 

web/server/i18n

11.26  LocaleContextResolver

　　springMVC給咱們提供了國際化支持，簡單來講就是設置整個系統的運行語言，而後根據系統的運行語言來展現對應語言的頁面，通常咱們稱之爲多語言。springMVC國際化機制就是能夠設置整個系統的運行語言。

　　LocaleContext該接口決定當前真正的Locale。

　　LocaleContextResolver：該接口用於解析基於web的local contex，容許經過request決定這個local context或者經過HTTP exchange來修改這個local contex。

11.27  AcceptHeaderLocaleContextResolver

　　LocaleContextResolver接口的實現類，解析器檢查HTTP request中攜帶的"Accept-Language" 請求頭，一般該請求頭字段中包含了客戶端地區信息。（這個地區信息由客戶端瀏覽器發送，在客戶端的操做系統中體系）。該解析器不支持設置LocalContext，

11.28  FixedLocaleContextResolver

　　LocaleContextResolver接口的實現類，一直使用固定的Local，不支持改變Local。默認的爲JVM的默認local。

 

web/server/session

11.29  WebSessionIdResolver

　　WebSessionIdResolver定義了session id解析策略的契約。容許經過請求解析session id，並經過響應來發送session id或者終止會話。包含三個方法：

　　resolveSessionIds(ServerWebExchange exchange)：解析與當前請求相關聯的sessionId。sessionId可能來自Cookie或請求頭。

　　setSessionId(ServerWebExchange exchange, String sessionId)：將給定的sessionId發送給客戶端。這個方法是在建立一個新session時被調用，並告知客戶端新sessionId是什麼。

　　expireSession(ServerWebExchange exchange)：指示客戶端結束當前session。當session無效時調用此方法，並應通知客戶端sessionId再也不有效。好比，它可能刪除一個包含sessionId的Cookie，或者設置一個HTTP響應頭，其值爲空就表示客戶端再也不提交sessionId。

11.30  CookieWebSessionIdResolver

　　基於Cookie的WebSessionIdResolver。

11.31  HeaderWebSessionIdResolver

　　WebSessionIdResolver接口的實現類，經過從請求頭header中解析出sessionId。

11.32  WebSessionManager

　　WebSession管理器，爲HTTP request提供了訪問WebSession的方法。該接口定義了一個方法getSession()，爲一個給定的ServerWebExchange返回WebSession。

11.33  DefaultWebSessionManager

　　實現了WebSessionManager接口，主要定義了session的建立，啓動，暫停與cookie的關聯的定義。

11.34  WebSessionStore

　　會話存儲接口，爲WebSession持久化保存的策略接口。包含4個函數：

　　一、createWebSession()建立一個新的WebSession，該函數僅是建立一個會話實例，會話的啓動經過WebSession#start()函數，持久化經過WebSession#save()函數。

　　二、retrieveSession(String sessionId)；根據給定的sessionId返回相應的WebSession。

　　三、removeSession(String sessionId)；刪除指定sessionId的WebSession。

　　四、updateLastAccessTime(WebSession webSession)：更新webSession的時間戳爲當前時間。

11.35  InMemoryWebSessionStore

　　WebSessionStore接口的默認實現，採用map集合的方式來存儲WebSession實例。

 

12、web/util

12.1  ContentCachingRequestWrapper

　　把請求內容緩存起來的代理類。servlet的request body一旦流被讀取了，就沒法再次消費了，經過這個類可以解決HttpServletRequest inputStream只能讀取一次的問題（request.getInputStream()）。它使用一個字段：cachedContent來緩存body體裏面的內容。

12.2  ContentCachingResponseWrapper

　　把響應內容緩存起來的代理類。緩存全部要寫入getOutputStream()和getWriter()中的內容，容許該內容經過函數getContentAsByteArray()得到。

12.3  HtmlCharacterEntityDecoder

　　幫助類，經過使用實體字符（the referred character）來替換字符實體編碼（character entity references）進行HTML字符串的解碼操做。

12.4  HtmlCharacterEntityReferences

　　表示在HTML4.0標準中定義的一系列字符實體編碼。完整的描述在https://www.w3.org/TR/html4/charset.html中。

 

12.5  HtmlUtils

　　不少時候，因爲特殊字符的緣由，會形成用戶輸入的信息反饋到頁面上時會顯示成亂碼，形成頁面排版混亂；另外，黑客常常利用特殊字符對網站進行xss跨站攻擊，因此咱們須要對頁面上提交的特殊字符進行html轉碼。

　　轉換爲HTML轉義字符表示、轉換爲數據轉義表示、轉換爲十六進制數據轉義表示。

12.6  JavaScriptUtils

　　基於JavaScript 1.5 recommendation對JavaScript進行轉義。

12.7  WebUtils

　　WebUtils：該工具類主要用於Web應用程序，供各類框架使用。主要方法以下：

　　一、setWebAppRootSystemProperty：表示保存系統根路徑的key-value

　　二、removeWebAppRootSystemProperty：表示移除系統根路徑的key-value。

　　三、getDefaultHtmlEscape：看web.xml中的defaultHtmlEscape的值是否設置爲true。

　　四、getTempDir：返回由當前servlet容器提供的 當前Web應用程序的臨時目錄。

　　五、getRealPath：返回由servlet容器提供的，Web應用程序中給定路徑的實際路徑。

　　六、getSessionId：返回指定的request的session id。

　　七、get/setSessionAttribute：根據當前的request和session attributes的name獲得/設置session attributes的值。

　　八、getNativeRequest：返回指定類型的合適的請求對象，若是可用，會unwrapping給定的request請求。

　　九、getNativeResponse：返回指定類型的response對象。

　　十、isIncludeRequest：判斷請求是不是一個包含(Include)請求，即不是從外部進入的頂級Http請求。

　　十一、getCookie：獲取制定名字的cookie。

　　十二、getParametersStartingWith：返回包含具備給定前綴的全部參數的map。將單個值映射爲String，多個值映射到String數組。

12.8  ServletContextPropertyUtils

　　用來解析文本中的佔位符，常在文件路徑中使用。

12.9  TagUtils

　　jsp標籤的工具支持類。

12.10  UriUtils

　　處理uri裏特殊字符的編碼。

 

12.11  HttpSessionMutexListener

　　HttpSessionListener接口實現類，該Servlet HTTP 會話監聽器會在一個Http會話建立的時候暴露會話的互斥鎖。該監聽器在web.xml中註冊。

12.12  IntrospectorCleanupListener

　　一、此監聽器主要用於解決java.beans.Introspector致使的內存泄漏的問題。

　　二、此監聽器應該配置在web.xml中與Spring相關監聽器中的第一個位置（也要在ContextLoaderListener的前面）。

　　三、JDK中的java.beans.Introspector類的用途是發現Java類是否符合JavaBean規範，若是有的框架或程序用到了Introspector類，那麼就會啓用一個系統級別的緩存，此緩存會存放一些曾加載並分析過的JavaBean的引用。當Web服務器關閉時，因爲此緩存中存放着這些JavaBean的引用，因此垃圾回收器沒法回收Web容器中的JavaBean對象，最後致使 內存變大。

　　而org.springframework.web.util.IntrospectorCleanupListener就是專門用來處理Introspector內存泄漏問題的輔助類。IntrospectorCleanupListener會在Web服務器中止時清理Introspector緩存，使那些Javabean能被垃圾回收器正確回收。Spring自身不會出現這種問題，由於Spring在加載並分析完一個類以後會立刻刷新JavaBeans Introspector緩存，這就保證Spring中不會出現這種內存泄漏的問題。但有些程序和框架在使用了JavaBeans Introspector以後，沒有進行清理工做(如 Quartz，Struts)，最後致使內存泄漏。

12.13  WebAppRootListener

　　這個listener的做用就是監聽web.xml中的配置param-name爲webAppRootKey的值：

　　<context-param>

      　　  <param-name>webAppRootKey</param-name>

        　　<param-value>myroot</param-value>

　　</context-param>

　　而後配置這個監聽器：

　　<listener>

    　　<listener-class>org.springframework.web.util.WebAppRootListener</listener-class>

　　</listener>

　　做用：它會在ServletContext上下文初始化的時候，首先獲取根傳遞進來的servletContext獲得物理路徑，String path=servletContext.getRealPath(""/"");而後找到context-param的webAooRootKey對應的param-value，把param-value的值做爲key，上面配置的是""myroot""。

　　接着執行System.setProperty(""myroot"",path)。這樣在web中任意地方就能夠使用System.getProperty(""myroot"")來獲取系統的絕對路徑。

 

12.14  UriBuilder

　　URIBuilder主要用於構造URI，URI(Uniform Resource Identifier)即通一資源標誌符，表示的是web上每一種可用的資源，如 HTML文檔、圖像、視頻片斷、程序等都由一個URI進行定位的。URL是URI的一個子集，它是Uniform Resource Locator的縮寫，譯爲"統一資源定位符"。

12.15  UriBuilderFactory

　　用來建立UriBuilder實例。

12.16  DefaultUriBuilderFactory

　　UriBuilderFactory接口的實現類。依靠UriComponentsBuilder來實際建立一個URI。

12.17  UriComponents

　　表示一系列的不可改變的URI組件，將組件類型映射到字符串值。包含了全部組件的getters方法。實際上，同java.net.URI相似，不過擁有更強的編碼選擇，支持URI template變量。

12.18  OpaqueUriComponents

　　拓展自UriComponents，支持opaque URIs。

12.19  HierarchicalUriComponents

　　拓展自UriComponents，支持hierarchical URIs。

12.20  UriComponentsBuilder

　　Spring MVC 提供了一種機制，能夠構造和編碼URI – 使用UriComponentsBuilder和UriComponents。這樣咱們再也不本身去拼接了，提升了正確性。它能夠細粒度的控制URI的各個要素，如構建、擴展模板變量以及編碼。

12.21  UriTemplate

　　用於處理格式化Uri模板。

12.22  UriTemplateHandler

　　定義了用來拓展URI模板類的方法。

12.23  AbstractUriTemplateHandler

　　UriTemplateHandler接口實現類的抽象基類。提供了setBaseUrl和setDefaultUriVariables方法，在子類中無論是URI模板的拓展仍是編碼機制都是密切相關的。

12.24  DefaultUriTemplateHandler

　　UriTemplateHandler接口的默認實現，使用UriComponentsBuilder來擴展和編碼uri的。

12.25  UrlPathHelper

　　Spring用來處理URL的工具類，位於包org.springframework.web.util內。它幫助Spring MVC處理URL相關的各類難題。

 

12.26  CookieGenerator

　　生成Cookie。通常在CAS單點登陸裏用得較多。如今都用JWT了，就用得較少了。CAS (Central Authentication Server) 是 Yale 大學發起的一個開源項目，旨在爲 Web 應用系統提供一種可靠的單點登陸方法。

　　Json web token (JWT)，是爲了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標準。該token被設計爲緊湊且安全的，特別適用於分佈式站點的單點登陸（SSO）場景。

12.27  NestedServletException

　　繼承自ServletException，從message和stacktrace角度來講，是在root處引起的異常，就像NestedChecked/RuntimeException。

 

web/util/pattern

12.28  SubSequence

　　用來返回一個數組的一個部分，當要把一個數據的子集傳給另一個函數可是不但願建立一個新的字符串對象時有用。

12.29  PathPattern

　　表示一個解析過的路徑模式。包含一系列的路徑元素用來快速匹配。

12.30  PathPatternRouteMatcher

　　RouteMatcher接口實現類，屬性中包含了一個PathPatternParser對象，該類使用PathContainer和PathContainer表示route和patterns。

12.31  PathPatternParser

　　解析URI path patterns產生PathPattern實例對象，從而匹配request請求。

12.32  InternalPathPatternParser

　　解析URI template patterns。它把path pattern分解成許多PathElements，這些PathElements以鏈表形式組織。這些實例可重複使用，可是是非線程安全的。

12.33  PatternParseException

　　解析pattern時發生問題時拋出的異常。

12.34  PathElement

　　由抽象語法樹節點建立，用來表示一個路徑模式的通用超類。

12.35  LiteralPathElement

　　一個文字的路徑元素。在'/foo/bar/goo'模式中，有三個文件的路徑元素：'foo', 'bar'和 'goo'。

12.36  RegexPathElement

　　正則表達式的路徑元素。用來表示複雜的路徑元素。好比在'/foo/*_*/*_{foobar}' 中， *_* 和*_{foobar}都是正則表達式的路徑元素。

12.37  SeparatorPathElement

　　路徑分隔符元素，在模式'/foo/bar'總，兩次出現的'/'能夠使用SeparatorPathElement類進行表示（若是默認的分隔符是'/'）。

12.38  CaptureVariablePathElement

　　路徑中某一塊是個變量，那麼這個變量元素能夠使用CaptureVariablePathElement表示。好比在'/foo/{bar}/goo' 中，{bar}就能夠用該類表示。

12.39  WildcardPathElement

　　通配符路徑元素。在'/foo/*/goo'中，這個*就能夠用WildcardPathElement來表示。在整個路徑上（如上例），至少要匹配一個字符，可是在一個路徑的的末尾（如linux*），能夠匹配0個字符。

12.40  SingleCharWildcardedPathElement

　　一個文字路徑元素，該元素包括一個或多個通配符'?'（一個？通配符代替一個字符）。

12.41  CaptureTheRestPathElement

　　一個路徑元素，表示捕獲路徑的其他部分，在'/foo/{*foobar}' 中/{*foobar}就能夠用CaptureTheRestPathElement表示。

12.42  WildcardTheRestPathElement

　　一個路徑元素，表示通配路徑的其他部分。在'/foo/**'中/**就能夠用WildcardTheRestPathElement來表示。

 

本文參考了博客園、CSDN部分文獻。

拓展閱讀：

Spring框架之beans源碼徹底解析（https://www.cnblogs.com/xxkj/p/13929565.html）

Spring框架之AOP源碼徹底解析（https://www.cnblogs.com/xxkj/p/14094203.html）

Spring框架之jms源碼徹底解析（http://www.javashuo.com/article/p-zjzamwxy-nz.html）

Spring框架之spring-web http源碼徹底解析（http://www.javashuo.com/article/p-sdqjxofn-nz.html）

 

 

博衆家之所長，集羣英之薈萃。遴選各IT領域精品雄文！

歡迎關注「IT架構精選」