前言
context容器是一個web項目的代表，主要管理servlet執行個體，在tomcat中servlet執行個體是以wrapper出現的，現在問題是如何才能通過context容器找到具體的servlet呢？在解決這個問題之前，context容器需要先啟動，啟動的過程就是加載個類資源檔案以及打開子容器以及pipeline管道的過程。啟動context容器後，就可以處理具體的請求了，具體是通過request對象，從代碼清單4-3的<code>wrapper wrapper = request.getwrapper()</code>就可以看出來。
那麼context調用invoke方法後又發生什麼了呢？具體執行的是org.apache.catalina.core.standardcontextvalve的invoke方法。相當于進入了context管道中，要開始通過管道中一個個閘門了。
standardcontext的處理流程可以用下面的圖簡化：
代碼清單4-3：
禁止直接通路web-inf或者meta-inf目錄下的資源
選擇具體的wrapper處理請求
傳回一個确認響應
調用wrapper容器的invoke方法，把處理請求交給standardwrappervalve處理
wrapper容器
wrapper容器負責管理一個servlet，包括servlet的裝載、初始化、資源回收。wrapper是最底層的容器，其不能在添加子容器了。wrapper是一個接口，其标準實作類是standardwrapper，下面是這兩個類的結構：
上面的圖都隻是類的一部分，由于wrapper與servlet息息相關，其中的loadservlet方法負責裝載servlet，其源碼如下：
代碼清單4-4：
該類主要負責初始化一個servlet執行個體，并調用該執行個體的init方法，然後通知感興趣的事件監聽程式。代碼清單4-3中調用了wrapper的invoke方法，這個方法完成什麼呢？
代碼清單4-5：
初始化一些本地變量
判斷目前應用是否可用，就是判斷是否确實有這個項目
配置設定一個servlet執行個體
為請求建立一個過濾器鍊
過濾器過濾請求
關閉過濾器
重新委派原來委派的servlet執行個體
釋放資源
這個方法與上面的loadservlet關系如下：
可以看出在調用loadservlet的allocate方法的時候調用了standardwrappervalve的invoke方法，在wrapper容器獲得請求後，通過allocate方法從執行個體池棧中彈出一個servlet執行個體來處理這個請求，servlet執行個體被封裝成filterchain對象，緊接着通過一系列的過濾器過濾到達servlet.service()方法。這個過程可以如下：