引用：
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总算是启动完毕喽。
