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

时间:2023-12-26 20:04:34

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

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

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

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

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

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

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

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

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

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

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

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!