引用：
2.0 Tomcat的啓動流程 這篇文章是講tomcat怎麼啓動的，既然我們大體上了解了TOMCAT的框架結構了， 那麼我們可以望文生意地就猜到tomcat的啓動， 會先啓動父容器，然後逐個啓動裏面的子容器。 啓動每一個容器的時候， 都會啓動安插在他身上的組件。 當所有的組件啓動完畢， 所有的容器啓動完畢的時候， tomcat本身也就啓動完畢了。 順理成章地， 我們同樣可以猜到， tomcat的啓動會分成兩大部分， 第一步是裝配工作。 第二步是啓動工作。 裝配工作就是爲父容器裝上子容器， 爲各個容器安插進組件的工作。 這個地方我們會用到digester模式， 至於digester模式什麼， 有什麼用， 怎麼工作的. 請參考 http://software.ccidnet.com/pub/article/c322_a31671_p2.html 啓動工作是在裝配工作之後， 一旦裝配成功了， 我們就只需要點燃最上面的一根導線， 整個tomcat就會被激活起來。 這就好比我們要開一輛已經裝配好了的汽車的時候一樣，我們只要把鑰匙插進鑰匙孔，一擰，汽車的引擎就會發動起來，空調就會開起來， 安全裝置就會生效， 如此一來，汽車整個就發動起來了。（這個過程確實和TOMCAT的啓動過程不謀而和， 讓我們不得不懷疑 TOMCAT的設計者是在GE做JAVA開發的）。
2.1 一些有意思的名稱： Catalina Tomcat Bootstrap Engin Host Context 他們的意思很有意思： Catalina: 遠程轟炸機 Tomcat: 熊貓轟炸機 -- 轟炸機的一種（這讓我想起了讓國人引以爲豪的熊貓手機，是不是英文可以叫做tomcat??? ， 又讓我想起了另一則廣告： 波導-手機中的戰鬥機、波音-客機中的戰鬥機 ） Bootstap: 引導 Engin: 發動機 Host: 主機，領土 Context: 內容， 目標， 上下文 ... 在許多許多年後， 現代人類已經滅絕。 後現代生物發現了這些單詞零落零落在一塊。 一個自以爲聰明的傢伙把這些東西翻譯出來了： 在地勤人員的引導(bootstrap)下， 一架轟炸架(catalina)騰空躍起， 遠看是熊貓轟炸機(tomcat)， 近看還是熊貓轟炸機！ 憑藉着優秀的發動機技術(engin)， 這架熊貓轟炸機飛臨了敵國的領土上空(host)， 對準目標(context)投下了毀天滅地的核彈頭，波~ 現代生物就這麼隔屁了~ 綜上所述， 這又不得不讓人聯想到GE是不是也參與了軍事設備的生產呢？ 反對美帝國主義！ 反對美霸權主義！ 和平萬歲！ 自由萬歲！
2.2 歷史就是那麼驚人的相似！tomcat的啓動就是從org.apache.catalina.startup.Bootstrap這個類悍然啓動的！ 在Bootstrap裏做了兩件事：一. 指定了3種類型classloader: commonLoader: common/classes、common/lib、common/endorsed catalinaLoader: server/classes、server/lib、commonLoader sharedLoader： shared/classes、shared/lib、commonLoader 二. 引導Catalina的啓動。 用Reflection技術調用org.apache.catalina.startup.Catalina的process方法， 並傳遞參數過去。
2.3 Catalina.java Catalina完成了幾個重要的任務： 1. 使用Digester技術裝配tomcat各個容器與組件。 2. 爲top level 的server 做初始化工作。 實際上就是做通常會配置給service的兩條connector.(http, ajp) 3. 從server這個容器開始啓動， 點燃整個tomcat. 4. 爲server做一個hook程序， 檢測當server shutdown的時候， 關閉tomcat的各個容器用。 5. 監聽8005端口， 如果發送"SHUTDOWN"（默認培植下字符串）過來， 關閉8005serverSocket。
2.4 啓動各個容器 1. Server 觸發Server容器啓動前(before_start)， 啓動中(start)， 啓動後(after_start)3個事件， 並運行相應的事件處理器。 啓動Server的子容器：Servcie. 2. Service 啓動Service的子容器：Engin 啓動Connector
3.0 Engin 到了Engin這個層次，以及以下級別的容器， Tomcat就使用了比較一致的啓動方式了。 首先， 運行各個容器自己特有一些任務 隨後， 觸發啓動前事件 立即， 設置標籤，就表示該容器已經啓動 接着， 啓動容器中的各個組件： loader, logger, manager等等 再接着，啓動mapping組件。（注1） 緊跟着，啓動子容器。 接下來，啓動該容器的管道(pipline) 然後， 觸發啓動中事件 最後， 觸發啓動後事件。 Engin大致會這麼做， Host大致也會這麼做， Context大致還是會這麼做。 那麼很顯然地， 我們需要在這裏使用到代碼複用的技術。 tomcat在處理這個問題的時候， 漂亮地使用了抽象類來處理。 ContainerBase. 最後使得這部分完成複雜功能的代碼顯得乾淨利落， 幹練爽快， 實在是令人覺得歎爲觀止， 細細品來， 直覺如享佳珍， 另人齒頰留香， 留戀往返啊！ Engin的觸發啓動前事件裏， 會激活綁定在Engin上的唯一一個Listener：EnginConfig。 這個EnginConfig類基本上沒有做什麼事情， 就是把EnginConfig的調試級別設置爲和Engin相當。 另外就是輸出幾行文本， 表示Engin已經配置完畢， 並沒有做什麼實質性的工作。 注1: mapping組件的用處是， 當一個需求將要從父容器傳遞到子容器的時候， 而父容器又有多個子容器的話， 那麼應該選擇哪個子容器來處理需求呢？ 這個由mapping 組件來定奪。
4.0 Host 同Engin一樣， 也是調用ContainerBase裏面的start()方法， 不過之前做了些自個兒的任務,就是往Host這個容器的通道（pipline）裏面， 安裝了一個叫做 “org.apache.catalina.valves.ErrorReportValve”的閥門。 這個閥門的用處是這樣的： 需求在被Engin傳遞給Host後， 會繼續傳遞給Context做具體的處理。 這裏需求其實就是作爲參數傳遞的Request, Response。 所以在context把需求處理完後， 通常會改動response。 而這個org.apache.catalina.valves.ErrorReportValve的作用就是檢察response是否包含錯誤， 如果有就做相應的處理。 5. Context 到了這裏， 就終於輪到了tomcat啓動中真正的重頭戲，啓動Context了。
5.0 StandardContext.start() 這個啓動Context容器的方法被StandardHost調用.
5.1 webappResources 該context所指向的具體目錄
5.2 安裝defaultContex, DefaultContext 就是默認Context。 如果我們在一個Host下面安裝了DefaultContext，而且defaultContext裏面又安裝了一個數據庫連接池資源的話。 那麼其他所有的在該Host下的Context, 都可以直接使用這個數據庫連接池， 而不用格外做配置了。
5.3 指定Loader. 通常用默認的org.apache.catalina.loader.WebappLoader這個類。 Loader就是用來指定這個context會用到哪些類啊， 哪些jar包啊這些什麼的。
5.4 指定 Manager. 通常使用默認的org.apache.catalina.session. StandardManager 。 Manager是用來管理session的。 其實session的管理也很好實現。 以一種簡單的session管理爲例。 當需求傳遞過來的時候， 在Request對象裏面有一個sessionId 屬性。 OK， 得到這個sessionId後， 我們就可以把它作爲map的key，而value我們可以放置一個HashMap. HashMap裏邊兒， 再放我們想放的東西。
5.5 postWorkDirectory (). Tomcat下面有一個work目錄。 我們把臨時文件都扔在那兒去。 這個步驟就是在那裏創建一個目錄。 一般說來會在%CATALINA_HOME%/work/Standalone/localhost/ 這個地方生成一個目錄。
5.6 Binding thread。到了這裏， 就應該發生 class Loader 互換了。 之前是看得見tomcat下面所有的class和lib. 接下來需要看得見當前context下的class。 所以要設置contextClassLoader, 同時還要把舊的ClassLoader記錄下來，因爲以後還要用的。
5.7 啓動 Loader. 指定這個Context具體要使用哪些classes， 用到哪些jar文件。 如果reloadable設置成了true, 就會啓動一個線程來監視classes的變化， 如果有變化就重新啓動Context。
5.8 啓動logger
5.9 觸發安裝在它身上的一個監聽器。 lifecycle.fireLifecycleEvent(START_EVENT, null); 作爲監聽器之一，ContextConfig會被啓動. ContextConfig就是用來配置web.xml的。 比如這個Context有多少Servlet， 又有多少Filter， 就是在這裏給Context裝上去的。
5.9.1 defaultConfig. 每個context都得配置 tomcat/conf/web.xml 這個文件。
5.9.2 applicationConfig 配置自己的 WEB-INF/web.xml 文件
5.9.3 validateSecurityRoles 權限驗證。 通常我們在訪問/admin 或者/manager的時候，需要用戶要麼是admin的要麼是manager的， 才能訪問。 而且我們還可以限制那些資源可以訪問， 而哪些不能。 都是在這裏實現的。
5.9.4 tldScan: 掃描一下， 需要用到哪些標籤(tag lab)
5.10 啓動 manager
5.11 postWelcomeFiles() 我們通常會用到的3個啓動文件的名稱： index.html、index.htm、index.jsp 就被默認地綁在了這個context上
5.12 listenerStart 配置listener
5.13 filterStart 配置 filter
5.14 啓動帶有1的Servlet. 順序是從小到大： 1,2,3… 最後是0 默認情況下， 至少會啓動如下3個的Servlet: org.apache.catalina.servlets.DefaultServlet 處理靜態資源的Servlet. 什麼圖片啊， html啊， css啊， js啊都找他 org.apache.catalina.servlets.InvokerServlet 處理沒有做Servlet Mapping的那些Servlet. org.apache.jasper.servlet.JspServlet 處理JSP文件的.
5.15 標識context已經啓動完畢。走了多少個步驟啊， Context總算是啓動完畢嘍。
2.0 Tomcat的啓動流程 這篇文章是講tomcat怎麼啓動的，既然我們大體上了解了TOMCAT的框架結構了， 那麼我們可以望文生意地就猜到tomcat的啓動， 會先啓動父容器，然後逐個啓動裏面的子容器。 啓動每一個容器的時候， 都會啓動安插在他身上的組件。 當所有的組件啓動完畢， 所有的容器啓動完畢的時候， tomcat本身也就啓動完畢了。 順理成章地， 我們同樣可以猜到， tomcat的啓動會分成兩大部分， 第一步是裝配工作。 第二步是啓動工作。 裝配工作就是爲父容器裝上子容器， 爲各個容器安插進組件的工作。 這個地方我們會用到digester模式， 至於digester模式什麼， 有什麼用， 怎麼工作的. 請參考 http://software.ccidnet.com/pub/article/c322_a31671_p2.html 啓動工作是在裝配工作之後， 一旦裝配成功了， 我們就只需要點燃最上面的一根導線， 整個tomcat就會被激活起來。 這就好比我們要開一輛已經裝配好了的汽車的時候一樣，我們只要把鑰匙插進鑰匙孔，一擰，汽車的引擎就會發動起來，空調就會開起來， 安全裝置就會生效， 如此一來，汽車整個就發動起來了。（這個過程確實和TOMCAT的啓動過程不謀而和， 讓我們不得不懷疑 TOMCAT的設計者是在GE做JAVA開發的）。
2.1 一些有意思的名稱： Catalina Tomcat Bootstrap Engin Host Context 他們的意思很有意思： Catalina: 遠程轟炸機 Tomcat: 熊貓轟炸機 -- 轟炸機的一種（這讓我想起了讓國人引以爲豪的熊貓手機，是不是英文可以叫做tomcat??? ， 又讓我想起了另一則廣告： 波導-手機中的戰鬥機、波音-客機中的戰鬥機 ） Bootstap: 引導 Engin: 發動機 Host: 主機，領土 Context: 內容， 目標， 上下文 ... 在許多許多年後， 現代人類已經滅絕。 後現代生物發現了這些單詞零落零落在一塊。 一個自以爲聰明的傢伙把這些東西翻譯出來了： 在地勤人員的引導(bootstrap)下， 一架轟炸架(catalina)騰空躍起， 遠看是熊貓轟炸機(tomcat)， 近看還是熊貓轟炸機！ 憑藉着優秀的發動機技術(engin)， 這架熊貓轟炸機飛臨了敵國的領土上空(host)， 對準目標(context)投下了毀天滅地的核彈頭，波~ 現代生物就這麼隔屁了~ 綜上所述， 這又不得不讓人聯想到GE是不是也參與了軍事設備的生產呢？ 反對美帝國主義！ 反對美霸權主義！ 和平萬歲！ 自由萬歲！
2.2 歷史就是那麼驚人的相似！tomcat的啓動就是從org.apache.catalina.startup.Bootstrap這個類悍然啓動的！ 在Bootstrap裏做了兩件事：一. 指定了3種類型classloader: commonLoader: common/classes、common/lib、common/endorsed catalinaLoader: server/classes、server/lib、commonLoader sharedLoader： shared/classes、shared/lib、commonLoader 二. 引導Catalina的啓動。 用Reflection技術調用org.apache.catalina.startup.Catalina的process方法， 並傳遞參數過去。
2.3 Catalina.java Catalina完成了幾個重要的任務： 1. 使用Digester技術裝配tomcat各個容器與組件。 2. 爲top level 的server 做初始化工作。 實際上就是做通常會配置給service的兩條connector.(http, ajp) 3. 從server這個容器開始啓動， 點燃整個tomcat. 4. 爲server做一個hook程序， 檢測當server shutdown的時候， 關閉tomcat的各個容器用。 5. 監聽8005端口， 如果發送"SHUTDOWN"（默認培植下字符串）過來， 關閉8005serverSocket。
2.4 啓動各個容器 1. Server 觸發Server容器啓動前(before_start)， 啓動中(start)， 啓動後(after_start)3個事件， 並運行相應的事件處理器。 啓動Server的子容器：Servcie. 2. Service 啓動Service的子容器：Engin 啓動Connector
3.0 Engin 到了Engin這個層次，以及以下級別的容器， Tomcat就使用了比較一致的啓動方式了。 首先， 運行各個容器自己特有一些任務 隨後， 觸發啓動前事件 立即， 設置標籤，就表示該容器已經啓動 接着， 啓動容器中的各個組件： loader, logger, manager等等 再接着，啓動mapping組件。（注1） 緊跟着，啓動子容器。 接下來，啓動該容器的管道(pipline) 然後， 觸發啓動中事件 最後， 觸發啓動後事件。 Engin大致會這麼做， Host大致也會這麼做， Context大致還是會這麼做。 那麼很顯然地， 我們需要在這裏使用到代碼複用的技術。 tomcat在處理這個問題的時候， 漂亮地使用了抽象類來處理。 ContainerBase. 最後使得這部分完成複雜功能的代碼顯得乾淨利落， 幹練爽快， 實在是令人覺得歎爲觀止， 細細品來， 直覺如享佳珍， 另人齒頰留香， 留戀往返啊！ Engin的觸發啓動前事件裏， 會激活綁定在Engin上的唯一一個Listener：EnginConfig。 這個EnginConfig類基本上沒有做什麼事情， 就是把EnginConfig的調試級別設置爲和Engin相當。 另外就是輸出幾行文本， 表示Engin已經配置完畢， 並沒有做什麼實質性的工作。 注1: mapping組件的用處是， 當一個需求將要從父容器傳遞到子容器的時候， 而父容器又有多個子容器的話， 那麼應該選擇哪個子容器來處理需求呢？ 這個由mapping 組件來定奪。
4.0 Host 同Engin一樣， 也是調用ContainerBase裏面的start()方法， 不過之前做了些自個兒的任務,就是往Host這個容器的通道（pipline）裏面， 安裝了一個叫做 “org.apache.catalina.valves.ErrorReportValve”的閥門。 這個閥門的用處是這樣的： 需求在被Engin傳遞給Host後， 會繼續傳遞給Context做具體的處理。 這裏需求其實就是作爲參數傳遞的Request, Response。 所以在context把需求處理完後， 通常會改動response。 而這個org.apache.catalina.valves.ErrorReportValve的作用就是檢察response是否包含錯誤， 如果有就做相應的處理。 5. Context 到了這裏， 就終於輪到了tomcat啓動中真正的重頭戲，啓動Context了。
5.0 StandardContext.start() 這個啓動Context容器的方法被StandardHost調用.
5.1 webappResources 該context所指向的具體目錄
5.2 安裝defaultContex, DefaultContext 就是默認Context。 如果我們在一個Host下面安裝了DefaultContext，而且defaultContext裏面又安裝了一個數據庫連接池資源的話。 那麼其他所有的在該Host下的Context, 都可以直接使用這個數據庫連接池， 而不用格外做配置了。
5.3 指定Loader. 通常用默認的org.apache.catalina.loader.WebappLoader這個類。 Loader就是用來指定這個context會用到哪些類啊， 哪些jar包啊這些什麼的。
5.4 指定 Manager. 通常使用默認的org.apache.catalina.session. StandardManager 。 Manager是用來管理session的。 其實session的管理也很好實現。 以一種簡單的session管理爲例。 當需求傳遞過來的時候， 在Request對象裏面有一個sessionId 屬性。 OK， 得到這個sessionId後， 我們就可以把它作爲map的key，而value我們可以放置一個HashMap. HashMap裏邊兒， 再放我們想放的東西。
5.5 postWorkDirectory (). Tomcat下面有一個work目錄。 我們把臨時文件都扔在那兒去。 這個步驟就是在那裏創建一個目錄。 一般說來會在%CATALINA_HOME%/work/Standalone/localhost/ 這個地方生成一個目錄。
5.6 Binding thread。到了這裏， 就應該發生 class Loader 互換了。 之前是看得見tomcat下面所有的class和lib. 接下來需要看得見當前context下的class。 所以要設置contextClassLoader, 同時還要把舊的ClassLoader記錄下來，因爲以後還要用的。
5.7 啓動 Loader. 指定這個Context具體要使用哪些classes， 用到哪些jar文件。 如果reloadable設置成了true, 就會啓動一個線程來監視classes的變化， 如果有變化就重新啓動Context。
5.8 啓動logger
5.9 觸發安裝在它身上的一個監聽器。 lifecycle.fireLifecycleEvent(START_EVENT, null); 作爲監聽器之一，ContextConfig會被啓動. ContextConfig就是用來配置web.xml的。 比如這個Context有多少Servlet， 又有多少Filter， 就是在這裏給Context裝上去的。
5.9.1 defaultConfig. 每個context都得配置 tomcat/conf/web.xml 這個文件。
5.9.2 applicationConfig 配置自己的 WEB-INF/web.xml 文件
5.9.3 validateSecurityRoles 權限驗證。 通常我們在訪問/admin 或者/manager的時候，需要用戶要麼是admin的要麼是manager的， 才能訪問。 而且我們還可以限制那些資源可以訪問， 而哪些不能。 都是在這裏實現的。
5.9.4 tldScan: 掃描一下， 需要用到哪些標籤(tag lab)
5.10 啓動 manager
5.11 postWelcomeFiles() 我們通常會用到的3個啓動文件的名稱： index.html、index.htm、index.jsp 就被默認地綁在了這個context上
5.12 listenerStart 配置listener
5.13 filterStart 配置 filter
5.14 啓動帶有1的Servlet. 順序是從小到大： 1,2,3… 最後是0 默認情況下， 至少會啓動如下3個的Servlet: org.apache.catalina.servlets.DefaultServlet 處理靜態資源的Servlet. 什麼圖片啊， html啊， css啊， js啊都找他 org.apache.catalina.servlets.InvokerServlet 處理沒有做Servlet Mapping的那些Servlet. org.apache.jasper.servlet.JspServlet 處理JSP文件的.
5.15 標識context已經啓動完畢。走了多少個步驟啊， Context總算是啓動完畢嘍。
