今天2010-3-11日，上班無事，想來將web.xml項目描述文件的加載過程做個總結貼在這里，以備忘：
web.xml加載過程（步驟）：
1.啟動WEB項目的時候,容器(如:Tomcat)會去讀它的配置文件web.xml.讀兩個節點:
<listener></listener> 和 <context-param></context-param>
2.緊接着,容器創建一個ServletContext(上下文),這個WEB項目所有部分都將共享這個上下文.
3.容器將<context-param></context-param>轉化為鍵值對,並交給ServletContext.
4.容器創建<listener></listener>中的類實例,即創建監聽.
5.在監聽中會有contextInitialized(ServletContextEvent args)初始化方法,在這個方法中獲得：
- ServletContext = ServletContextEvent.getServletContext();
- context-param的值 = ServletContext.getInitParameter("context-param的鍵");
6.得到這個context-param的值之后,你就可以做一些操作了.注意,這個時候你的WEB項目還沒有完全啟動完成.這個動作 會比所有的Servlet都要早. 換句話說,這個時候,你對<context-param>中的鍵值做的操作,將在你的WEB項目完全啟動之前被執行.
7.舉例.你可能想在項目啟動之前就打開數據庫. 那么這里就可以在<context-param>中設置數據庫的連接方式,在監聽類中初始化數據庫的連接.
8.這個監聽是自己寫的一個類,除了初始化方法,它還有銷毀方法.用於關閉應用前釋放資源.比如說數據庫連接的關閉.
web.xml節點加載順序：
可以肯定的是，節點的加載順序與它們在 web.xml 文件中的先后順序無關。即不會因為 filter 寫在 listener 的前面而會先加載 filter。最終得出的結論是：listener -> filter -> servlet
同時還存在着這樣一種配置節點：context-param，它用於向 ServletContext 提供鍵值對，即應用程序上下文信息。我們的 listener, filter 等在初始化時會用到這些上下文中的信息，那么 context-param 配置節是不是應該寫在 listener 配置節前呢？實際上 context-param 配置節可寫在任意位置，因此真正的加載順序為：
context-param -> listener -> filter -> servlet
對於某類配置節而言，與它們出現的順序是有關的。以 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 類似，此處不再贅述。
【加載Spring】
比如filter 需要用到 bean ，但加載順序是： 先加載filter 后加載spring，則filter中初始化操作中的bean為null；
所以，如果過濾器中要使用到 bean，可以將spring 的加載 改成 Listener的方式 :
- <listener>
- <listener-class>
- org.springframework.web.context.ContextLoaderListener
- </listener-class>
- </listener>
最終結論：
web.xml 的加載順序是：[context-param -> listener -> filter -> servlet -> spring] ，而同類型節點之間的實際程序調用的時候的順序是根據對應的 mapping 的順序進行調用的。