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!