一、            Web.xml詳解：

(一)  web.xml加載過程（步驟）

首先簡單說一下，web.xml的加載過程。

當我們去啟動一個WEB項目時，容器包括（JBoss、Tomcat等）首先會讀取項目web.xml配置文件里的配置，當這一步驟沒有出錯并且完成之后，項目才能正常地被啟動起來。

• ?  啟動WEB項目的時候，容器首先會去它的配置文件web.xml讀取兩個節點: 

• ?  緊接著，容器創建一個ServletContext（application），這個WEB項目所有部分都將共享這個上下文。
• ?  容器以<context-param></context-param>的name作為鍵，value作為值，將其轉化為鍵值對，存入ServletContext。
• ?  容器創建<listener></listener>中的類實例，根據配置的class類路徑<listener-class>來創建監聽，在監聽中會有contextInitialized(ServletContextEvent args)初始化方法，啟動Web應用時，系統調用Listener的該方法，在這個方法中獲得：

得到這個context-param的值之后，你就可以做一些操作了。

• ?   舉例：你可能想在項目啟動之前就打開數據庫，那么這里就可以在<context-param>中設置數據庫的連接方式（驅動、url、user、password），在監聽類中初始化數據庫的連接。這個監聽是自己寫的一個類，除了初始化方法，它還有銷毀方法，用于關閉應用前釋放資源。比如:說數據庫連接的關閉，此時，調用contextDestroyed(ServletContextEvent args)，關閉Web應用時，系統調用Listener的該方法。
• ?  接著，容器會讀取<filter></filter>，根據指定的類路徑來實例化過濾器。
• ?  以上都是在WEB項目還沒有完全啟動起來的時候就已經完成了的工作。如果系統中有Servlet，則Servlet是在第一次發起請求的時候被實例化的，而且一般不會被容器銷毀，它可以服務于多個用戶的請求。所以，Servlet的初始化都要比上面提到的那幾個要遲。

總的來說，web.xml的加載順序是: <context-param>-> <listener> -> <filter> -> <servlet>。其中，如果web.xml中出現了相同的元素，則按照在配置文件中出現的先后順序來加載。

對于某類元素而言，與它們出現的順序是有關的。以<filter>為例，web.xml中當然可以定義多個<filter>，與<filter>相關的一個元素是<filter-mapping>，注意，對于擁有相同<filter-name>的<filter>和<filter-mapping>元素而言，<filter-mapping>必須出現在<filter>之后，否則當解析到<filter-mapping>時，它所對應的<filter-name>還未定義。web容器啟動初始化每個<filter>時，按照<filter>出現的順序來初始化的，當請求資源匹配多個<filter-mapping>時，<filter>攔截資源是按照<filter-mapping>元素出現的順序來依次調用doFilter()方法的。<servlet>同<filter>類似，此處不再贅述。

(二)    web.xml標簽詳解

1.XML文檔有效性檢查

這段代碼指定文件類型定義(DTD)，可以通過它檢查XML文檔的有效性。下面顯示的<!DOCTYPE>元素有幾個特性，這些特性告訴我們關于DTD的信息： 

2.web-app定義該文檔(部署描述符，不是DTD文件)的根元素 

?PUBLIC意味著DTD文件可以被公開使用 

?"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"意味著DTD由Sun Microsystems, Inc.維護。該信息也表示它描述的文檔類型是DTD Web Application 2.3，而且DTD是用英文書寫的。 

?URL"http://java.sun.com/dtd/web-app_2_3.dtd"表示D文件的位置。

部署描述符的根元素是<web-app>。DTD文件規定<web-app>元素的子元素的語法如下： 

    正如您所看到的，這個元素含有23個子元素，而且子元素都是可選的。問號(？)表示子元素是可選的，而且只能出現一次。星號(*)表示子元素可在部署描述符中出現零次或多次。有些子元素還可以有它們自己的子元素。web.xml文件中<web-app>元素聲明的是下面每個子元素的聲明。下面講述部署描述符中可能包含的所有子元素。

注意：

在Servlet 2.3中，子元素必須按照DTD文件語法描述中指定的順序出現。比如：如果部署描述符中的<web-app>元素有<servlet>和<servlet-mapping>兩個子元素，則<servlet>子元素必須出現在<servlet-mapping>子元素之前。在Servlet2.4中，順序并不重要。

3. <display-name></display-name>

<display-name>test-hwp-web-application</display-name>定義了web應用的名稱，可以在

http://localhost:8080/manager/html中顯示。如下所示：

4.<distributable/>

<distributable/>可以使用distributable元素來告訴servlet/JSP容器，Web容器中部署的應用程序適合在分布式環境下運行。

5.<context-param></context-param>

 ?<context-param>解釋：

<context-param>元素含有一對參數名和參數值，用作應用的Servlet上下文初始化參數，參數名在整個Web應用中必須是惟一的，在web應用的整個生命周期中上下文初始化參數都存在，任意的Servlet和jsp都可以隨時隨地訪問它。<param-name>子元素包含有參數名，而<param-value>子元素包含的是參數值。作為選擇，可用<description>子元素來描述參數。

?什么情況下使用，為什么使用<context-param>：

比如：定義一個管理員email地址用來從程序發送錯誤，或者與你整個應用程序有關的其他設置。使用自己定義的設置文件需要額外的代碼和管理；直接在你的程序中使用硬編碼（Hard-coding）參數值會給你之后修改程序帶來麻煩，更困難的是，要根據不同的部署使用不同的設置；通過這種辦法，可以讓其他開發人員更容易找到相關的參數，因為它是一個用于設置這種參數的標準位置。

?Spring配置文件：

配置Spring，必須需要<listener>，而<context-param>可有可無，如果在web.xml中不寫<context-param>配置信息，默認的路徑是/WEB-INF/applicationContext.xml，在WEB-INF目錄下創建的xml文件的名稱必須是applicationContext.xml。如果是要自定義文件名可以在web.xml里加入contextConfigLocation這個context參數：在<param-value>里指定相應的xml文件名，如果有多個xml文件，可以寫在一起并以“,”號分隔，比如在business-client工程中，我們采用了自定義配置方式，<context-param>配置如下：

對應工程目錄結構如下所示：

?webAppRootKey配置：

部署在同一容器中的多個Web項目，要配置不同的webAppRootKey，web.xml文件中最好定義webAppRootKey參數，如果不定義，將會缺省為“webapp.root”，如下：

當然也不能重復，否則報類似下面的錯誤：

Web app root system property already set to different value: 'webapp.root' = [/home/user/tomcat/webapps/project1/] instead of [/home/user/tomcat/webapps/project2/] - Choose unique values for the 'webAppRootKey' context-param in your web.xml files!  

意思是“webapp.root”這個key已經指向了項目1，不可以再指向項目2。多個項目要對webAppRootKey進行配置，我們工程主要是讓log4j能將日志寫到對應項目根目錄下，比如：我們的項目的webAppRootKey為

  這樣就不會出現沖突了。就可以在運行時動態地找到項目路徑，在log4j.properties配置文件中可以按下面的方式使用${webapp.root}：

 就可以在運行時動態地找出項目的路徑。

?多個配置文件交叉引用處理：

如果web.xml中有contextConfigLocation參數指定的Spring配置文件，則會去加載相應的配置文件，而不會去加載/WEB-INF/下的applicationContext.xml。但是如果沒有指定的話，默認會去/WEB-INF/下加載applicationContext.xml。
在一個團隊使用Spring的實際項目中，應該需要多個Spring的配置文件，如何使用和交叉引用的問題：

多個配置文件可以在web.xml里用空格分隔寫入，如：

多個配置文件里的交叉引用可以用ref的external或bean解決，例如：

applicationContext.xml

dbBean在applicationContext-database.xml中。

?在不同環境下如何獲取：

范例:

此所設定的參數，在JSP網頁中可以使用下列方法來取得：

若在Servlet可以使用下列方法來獲得：

Servlet的ServletConfig對象擁有該Servlet的ServletContext的一個引用，所以可這樣取得上下文初始化參數：getServletConfig().getServletContext().getInitParameter()也可以在Servlet中直接調用getServletContext().getInitParameter()，兩者是等價的。

6.<session-config></session-config>

<session-config> 用于設置容器的session參數，比如：<session-timeout>用于指定http session的失效時間。默認時間設置在<jakarta>/conf/web.xml (30 minutes)。<session-timeout>用來指定默認的會話超時時間間隔，以分鐘為單位。該元素值必須為整數。如果 session-timeout元素的值為零或負數，則表示會話將永遠不會超時。

7.<listener></listener>

1.         Listener介紹：

<listener>為web應用程序定義監聽器，監聽器用來監聽各種事件，比如：application和session事件，所有的監聽器按照相同的方式定義，功能取決去它們各自實現的接口，常用的Web事件接口有如下幾個：

?ServletContextListener：用于監聽Web應用的啟動和關閉；

?ServletContextAttributeListener：用于監聽ServletContext范圍（application）內屬性的改變；

?ServletRequestListener：用于監聽用戶的請求；

?ServletRequestAttributeListener：用于監聽ServletRequest范圍（request）內屬性的改變；

?HttpSessionListener：用于監聽用戶session的開始和結束；

?HttpSessionAttributeListener：用于監聽HttpSession范圍（session）內屬性的改變。

<listener>主要用于監聽Web應用事件，其中有兩個比較重要的WEB應用事件：應用的啟動和停止（starting up or shutting down）和Session的創建和失效（created or destroyed）。應用啟動事件發生在應用第一次被Servlet容器裝載和啟動的時候；停止事件發生在Web應用停止的時候。Session創建事件發生在每次一個新的session創建的時候，類似地Session失效事件發生在每次一個Session失效的時候。為了使用這些Web應用事件做些有用的事情，我們必須創建和使用一些特殊的“監聽類”。它們是實現了以下兩個接口中任何一個接口的簡單java類：javax.servlet.ServletContextListener或javax.servlet.http.HttpSessionListener，如果想讓你的類監聽應用的啟動和停止事件，你就得實現ServletContextListener接口；想讓你的類去監聽Session的創建和失效事件，那你就得實現HttpSessionListener接口。

2.     Listener配置：

配置Listener只要向Web應用注冊Listener實現類即可，無序配置參數之類的東西，因為Listener獲取的是Web應用ServletContext（application）的配置參數。為Web應用配置Listener的兩種方式：

• ?  使用@WebListener修飾Listener實現類即可。
• ?  在web.xml文檔中使用<listener>進行配置。

我們選擇web.xml這種配置方式，只有一個元素<listener-class>指定Listener的實現類，如下所示：

這里的<listener>用于Spring的加載，Spring加載可以利用ServletContextListener實現，也可以采用load-on-startup Servlet 實現，但是當<filter>需要用到bean時，但加載順序是：先加載<filter>后加載<servlet>，則<filter>中初始化操作中的bean為null；所以，如果過濾器中要使用到bean，此時就可以根據加載順序<listener> -> <filter> -> <servlet>，將spring的加載改成Listener的方式。

1)     利用ServletContextListener實現：

2)     采用load-on-startup Servlet 實現：

我們選擇了第二種方式，在J2EE工程中web服務器啟動的時候最先調用web.xml，上面這段配置的意思是加載spring的監聽器，其中ContextLoaderListener的作用就是啟動Web容器時，自動裝配applicationContext.xml的配置信息，執行它所實現的方法。

8.<filter></filter>

1.      Filter介紹：

Filter可認為是Servle的一種“加強版”，主要用于對用戶請求request進行預處理，也可以對Response進行后處理，是個典型的處理鏈。使用Filter的完整流程是：Filter對用戶請求進行預處理，接著將請求HttpServletRequest交給Servlet進行處理并生成響應，最后Filter再對服務器響應HttpServletResponse進行后處理。Filter與Servlet具有完全相同的生命周期，且Filter也可以通過<init-param>來配置初始化參數，獲取Filter的初始化參數則使用FilterConfig的getInitParameter()。
換種說法，Servlet里有request和response兩個對象，Filter能夠在一個request到達Servlet之前預處理request，也可以在離開Servlet時處理response，Filter其實是一個Servlet鏈。以下是Filter的一些常見應用場合，

(1)認證Filter

(2)日志和審核Filter

(3)圖片轉換Filter

(4)數據壓縮Filter

(5)密碼Filter

(6)令牌Filter

(7)觸發資源訪問事件的Filter

(8)XSLT Filter

(9)媒體類型鏈Filter

Filter可負責攔截多個請求或響應；一個請求或響應也可被多個Filter攔截。創建一個Filter只需兩步：

?創建Filter處理類

?Web.xml文件中配置Filter

Filter必須實現javax.servlet.Filter接口，在該接口中定義了三個方法：

?void init(FilterConfig config)：用于完成Filter的初始化。FilteConfig用于訪問Filter的配置信息。

?void destroy()：用于Filter銷毀前，完成某些資源的回收。

?void doFilter(ServletRequest request,ServletResponse response,FilterChain chain)：實現過濾功能的核心方法，該方法就是對每個請求及響應增加額外的處理。該方法實現對用戶請求request進行預處理，也可以實現對服務器響應response進行后處理---它們的分界線為是否調用了chain.doFilter(request，response)，執行該方法之前，即對用戶請求request進行預處理，執行該方法之后，即對服務器響應response進行后處理。

2.      Filter配置：

Filter可認為是Servlet的“增強版”，因此Filter配置與Servlet的配置非常相似，需要配置兩部分：配置Filter名稱和Filter攔截器URL模式。區別在于Servlet通常只配置一個URL，而Filter可以同時配置多個請求的URL。配置Filter有兩種方式：

?  在Filter類中通過Annotation進行配置。

?  在web.xml文件中通過配置文件進行配置。

我們使用的是web.xml這種配置方式，下面重點介紹<filter>內包含的一些元素。

• <filter>用于指定Web容器中的過濾器，可包含<filter-name>、<filter-class>、<init-param>、<icon>、<display-name>、<description>。
• ?  <filter-name>用來定義過濾器的名稱，該名稱在整個程序中都必須唯一。
• ?  <filter-class>元素指定過濾器類的完全限定的名稱，即Filter的實現類。
• ?  <init-param>為Filter配置參數，與<context-param>具有相同的元素描述符<param-name>和<param-value>。
• ?  <filter-mapping>元素用來聲明Web應用中的過濾器映射，過濾器被映射到一個servlet或一個URL 模式。這個過濾器的<filter>和<filter-mapping>必須具有相同的<filter-name>，指定該Filter所攔截的URL。過濾是按照部署描述符的<filter-mapping>出現的順序執行的。

1)  字符集過濾器

登錄認證，未登錄用戶導向CAS Server進行認證。

4)  單點登出

CAS Server通知CAS Client，刪除session，注銷登錄信息。

)  封裝request

封裝request, 支持getUserPrincipal等方法。

6)  存放Assertion到ThreadLocal中

7)  禁用瀏覽器緩存

8)  CAS Client向CAS Server進行ticket驗證

 9.<servlet></servlet>

1.Servlet介紹：

Servlet通常稱為服務器端小程序，是運行在服務器端的程序，用于處理及響應客戶的請求。Servlet是個特殊的java類，繼承于HttpServlet。客戶端通常只有GET和POST兩種請求方式，Servlet為了響應則兩種請求，必須重寫doGet()和doPost()方法。大部分時候，Servlet對于所有的請求響應都是完全一樣的，此時只需要重寫service()方法即可響應客戶端的所有請求。

另外HttpServlet有兩個方法

?init(ServletConfig config)：創建Servlet實例時，調用該方法的初始化Servlet資源。

?destroy()：銷毀Servlet實例時，自動調用該方法的回收資源。

通常無需重寫init()和destroy()兩個方法，除非需要在初始化Servlet時，完成某些資源初始化的方法，才考慮重寫init()方法，如果重寫了init()方法，應在重寫該方法的第一行調用super.init(config)，該方法將調用HttpServlet的init()方法。如果需要在銷毀Servlet之前，先完成某些資源的回收，比如關閉數據庫連接，才需要重寫destory方法()。

Servlet的生命周期：

創建Servlet實例有兩個時機：

?客戶端第一次請求某個Servlet時，系統創建該Servlet的實例，大部分Servlet都是這種Servlet。

?Web應用啟動時立即創建Servlet實例，即load-on-start Servlet。

每個Servlet的運行都遵循如下生命周期：

1.創建Servlet實例。

2.Web容器調用Servlet的init()方法，對Servlet進行初始化。

3.Servlet初始化后，將一直存在于容器中，用于響應客戶端請求，如果客戶端發送GET請求，容器調用Servlet的doGet()方法處理并響應請求；如果客戶端發送POST請求，容器調用Servlet的doPost()方法處理并響應請求。或者統一使用service()方法處理來響應用戶請求。

4.Web容器決定銷毀Servlet時，先調用Servlet的destory()方法，通常在關閉Web應用時銷毀Servlet實例。

2.Servlet配置：

為了讓Servlet能響應用戶請求，還必須將Servlet配置在web應用中，配置Servlet需要修改web.xml文件。

從Servlet3.0開始，配置Servlet有兩種方式：

• ?在Servlet類中使用@WebServlet Annotation進行配置。
• ?在web.xml文件中進行配置。

我們用web.xml文件來配置Servlet，需要配置<servlet>和<servlet-mapping>。

<servlet>用來聲明一個Servlet。<icon>、<display-name>和<description>元素的用法和<filter>的用法相同。<init-param>元素與<context-param>元素具有相同的元素描述符，可以使用<init-param>子元素將初始化參數名和參數值傳遞給Servlet，訪問Servlet配置參數通過ServletConfig對象來完成，ServletConfig提供如下方法：

java.lang.String.getInitParameter(java.lang.String name)：用于獲取初始化參數

ServletConfig獲取配置參數的方法和ServletContext獲取配置參數的方法完全一樣，只是ServletConfig是取得當前Servlet的配置參數，而ServletContext是獲取整個Web應用的配置參數。

1.<description>、<display-name>和<icon>

?<description>：為Servlet指定一個文本描述。

?<display-name>：為Servlet提供一個簡短的名字被某些工具顯示。

?<icon>：為Servlet指定一個圖標，在圖形管理工具中表示該Servlet。

2.<servlet-name>、<servlet-class>和<jsp-file>元素

<servlet>必須含有<servlet-name>和<servlet-class>，或者<servlet-name>和<jsp-file>。 描述如下：

?<servlet-name>用來定義servlet的名稱，該名稱在整個應用中必須是惟一的

?<servlet-class>用來指定servlet的完全限定的名稱。

?<jsp-file>用來指定應用中JSP文件的完整路徑。這個完整路徑必須由/開始。

3.<load-on-startup>

如果load-on-startup元素存在，而且也指定了jsp-file元素，則JSP文件會被重新編譯成Servlet，同時產生的Servlet也被載入內存。<load-on-startup>的內容可以為空，或者是一個整數。這個值表示由Web容器載入內存的順序。

舉個例子：如果有兩個Servlet元素都含有<load-on-startup>子元素，則<load-on-startup>子元素值較小的Servlet將先被加載。如果<load-on-startup>子元素值為空或負值，則由Web容器決定什么時候加載Servlet。如果兩個Servlet的<load-on-startup>子元素值相同，則由Web容器決定先加載哪一個Servlet。

<load-on-startup>1</load-on-startup>表示啟動容器時，初始化Servlet。

4.<servlet-mapping>

<servlet-mapping>含有<servlet-name>和<url-pattern>

?<servlet-name>：Servlet的名字，唯一性和一致性，與<servlet>元素中聲明的名字一致。

?<url-pattern>：指定相對于Servlet的URL的路徑。該路徑相對于web應用程序上下文的根路徑。<servlet-mapping>將URL模式映射到某個Servlet，即該Servlet處理的URL。

5.加載Servlet的過程 

容器的Context對象對請求路徑(URL)做出處理，去掉請求URL的上下文路徑后，按路徑映射規則和Servlet映射路徑（<url- pattern>）做匹配，如果匹配成功，則調用這個Servlet處理請求。

3.DispatcherServlet在web.xml中的配置：

配置Spring MVC，指定處理請求的Servlet，有兩種方式：

• ?  默認查找MVC配置文件的地址是：/WEB-INF/${servletName}-servlet.xml
• ?  可以通過配置修改MVC配置文件的位置，需要在配置DispatcherServlet時指定MVC配置文件的位置。

    我們在平臺項目兩個工程中分別使用了不同的配置方式，介紹如下：

我們在business-client工程中按照默認方式查找MVC的配置文件，配置文件目錄為： /WEB-INF/business-servlet.xml。工程目錄結構如下所示：

我們在public-base-server工程中，通過第2種方式進行配置，把spring-servlet.xml放到src/main/resources/config/spring-servlet.xml，則需要在配置DispatcherServlet時指定<init-param>標簽。具體代碼如下：

工程目錄結構如下：

其中，classpath是web項目的類路徑，可以理解為classes下面。因為無論這些配置文件放在哪，編譯之后如果沒有特殊情況的話都直接在classes下面。jar包的話雖然放在lib文件夾里，但實際上那些類可以直接引用，比如：com.test.ABC，仿佛也在classes下面一樣。

在我們的工程里，經過驗證，maven工程這兩個

路徑經過編譯后生成的文件都位于classes目錄下，即這兩個路徑相當于類路徑，在下面創建config文件夾（folder），然后創建自定義的xml配置文件即可。

classpath和classpath*區別：

同名資源存在時，classpath只從第一個符合條件的classpath中加載資源，而classpath*會從所有的classpath中加載符合條件的資源。classpath*，需要遍歷所有的classpath，效率肯定比不上classpath，因此在項目設計的初期就盡量規劃好資源文件所在的路徑，避免使用classpath*來加載。

4.ContextLoaderListener和DispatcherServlet初始化上下文關系和區別：

從上圖可以看出，ContextLoaderListener初始化的上下文加載的Bean是對于整個應用程序共享的，一般如：DAO層、Service層Bean；DispatcherServlet初始化的上下文加載的Bean是只對Spring MVC有效的Bean，如：Controller、HandlerMapping、HandlerAdapter等，該初始化上下文只加載Web相關組件。

注意：用戶可以配置多個DispatcherServlet來分別處理不同的url請求，每個DispatcherServlet上下文都對應一個自己的子Spring容器，他們都擁有相同的父Spring容器（業務層，持久（dao）bean所在的容器）。

10.<welcome-file-list></welcome-file-list>

<welcome-file-list>包含一個子元素<welcome-file>，<welcome-file>用來指定首頁文件名稱。<welcome-file-list>元素可以包含一個或多個<welcome-file>子元素。如果在第一個<welcome-file>元素中沒有找到指定的文件，Web容器就會嘗試顯示第二個，以此類推。