Tomcat8源码笔记(九)组件StandardContext启动流程--未完待续

StandardContext代表的是webapps下项目，一个项目就是一个StandardContext，作为Tomcat组件的一部分，就会实现Lifecycle接口，被Tomcat管理着生命周期，本文从StandardContext的启动记录。

StandardContext从被创建起，就是直接进入start方法，Tomcat中组件的start会检测是否初始化过，没有初始化不好意思回去初始化再来启动.  StandardContext有着两个监听器，分别是ContextConfig以及MemoryLeakTracingListener，第一个是辅助监听器，第二个是出现内存泄露辅助监听器.

按照上面的ContextConfig可能针对的事件，StandardContext先初始化initInternal方法，然后是ContextConfig#init.  StandardContext#initInternal，重要的是初始化了自身的线程池，以及JMX注册.   接下来查看ContextConfig#init.

ContextConfig#init：首先获取Digester类，之前在解析conf/server.xml时也是在Digester中处理的，所以这里下意识以为又要解析什么xml！contextConfig就是具体配置并开始解析的方法，解析的xml就是catalina-home/conf/content.xml，以前很少了解这个文件是干嘛的，下面有介绍这个文件conf/content.xml，解析完成conf/content.xml之后，实例化了webXmlParser为了解析web.xml文件！

catalina-home/conf/content.xml如下:   上面contentConfig方法就是用来解析该文件，有兴趣的可以再研究下，可以将断点打在Deigester的startElement、characters、endElement上；直接说结论，解析完之后StandardContext的watchResource就多了两个字符串的值，WEB-INF/web.xml，以及catalina-home/conf/web.xml，这个两个文件作用很明显项目部署就会根据这两个文件.

之后就到了StandardContext#start阶段，首先按照ContextConfig图分析的，会先执行ContextConfig#beforeStart.  分两步走，fixDocBase，antiLocking.

beforeStart第一步：代码片段位于ContextConfig#fixDocBase.  该方法是决定部署项目时候使用哪个项目，会根据server.xml中Host的unpackWars布尔值， 默认是true，比如webapps下存在ProjectA  以及ProjectA.war，那unpackWars为true就会动态的扩展该ProjectA，比较ProjectA和ProjectA.war的区别，具体实现是ExpandWar.expand.

beforeStart第二步，antiLocking，由于antiResourceLocking默认为false，所以相当于不作处理； antiResourceLocking如果是true，代表项目资源私有，他会悄悄在Tomcat catalina-home/temp目录下将你的项目复制一份，这样Tomcat运行时期你如果对原有项目修改不会生效，这样可能是为了防止热部署？

下一步到了StandardContext#startInternal，在这个方法中就部署了项目，代码量不包括方法调用就有了300+行；

Step1. postWorkDirectory()介绍

postWorkDirectory首先给每个StandardContext设置工作目录，比如ProjectA的工作目录就是catalina-home/work/Catalina/localhost/ProjectA，一个项目一个工作目录部署到catalina-home/work/Catalina/localhost下；  另外初始化了每个项目对应的ServletContext，采用ServletContext的实现ApplicationContext（和Spring的ApplicationContext重名），ApplicationContext相当于每个项目应用上下文吧（个人理解);

Step2.实例化WebResourceRoot实现类StandardRoot，并将StandardRoot和StandardContext关联起来（StandardContext的resource引用指向StandardRoot）, StandardRoot#start ,

StandardRoot#startInternal就会处理/WEB-INF/lib下jar包等；

Step3.WebappLoader

实例化一个WebappLoader，单独用来加载每一个项目，将webappLoader和StandardContext关联起来(StandardContext的loader指向webappLoader). WebappLoader#start，初始化每一个项目的AppLoader，具体类型是WebappClassLoader； 并且获取到每个项目的classPath;  之后将WebappClassLoader绑定到Thread.currentThread上；

Step4. ContextConfig#configureStart

代码手动触发ContextConfig的configureStart方法，该方法就可以看成Web项目的入口， 其中webConfig方法介绍下，该方法解析了Web.xml，并且调用processServletContainerInitializers()来解析实现了ServletContainerInitializer的类（Servlet3.0之后的特性）；webConfig方法并且将每个JSP实例化成StandardWrapper加入到StandardContext中，由于代码量太大 并且不是专门研究JSP，所以ContextConfig关于configureStart的研究告一段落;

Tomcat StandardContext启动中有太多值得思量的地方，jar包的加载、类加载器的设置、资源lib/classes的处理，这些暂时还没有能力分析有些遗憾，以后有机会再钻研!

这里梳理下一些常见的组件的启动流程，从StandardService开始，第一步是StandardEngine#start,  StandardEngine#start又调用StandardHost#start, StandardHost启动成功之前，调用HostConfig#start,负责部署解析webapps下的项目；  之后StandardHost启动成功，StandardEngine也启动成功，然后就可使StandardService的另一个模板的启动,Connector!