TOMCAT源码调试入口是Bootstrap类的main方法,我的启动参数VM:

-Dcatalina.home=E:/Tomcat_Source_Code/apache-tomcat-8.0.53-src/catalina-home
-Dcatalina.base=E:/Tomcat_Source_Code/apache-tomcat-8.0.53-src/catalina-home
-Djava.endorsed.dirs=E:/Tomcat_Source_Code/apache-tomcat-8.0.53-src/catalina-home/endorsed
-Djava.io.tmpdir=E:/Tomcat_Source_Code/apache-tomcat-8.0.53-src/catalina-home/temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=E:/Tomcat_Source_Code/apache-tomcat-8.0.53-src/catalina-home/conf/logging.properties

Bootstrap执行main方法之前,先来看下static静态代码块做了哪些:

从当前系统变量、VM参数中获取 catalina.home作为 Bootstrap的 catalinaHomeFile,从系统变量、VM参数中获取catalina.base作为Bootstrap的catalinaBaseFile , 一般catalina.home和catalina.base 都指向同一个目录

main方法作为Bootstrap的入口,做了以下几个操作:实例化一个Bootstrap,并且调用Bootstrap的init,将Bootstrap实例赋给daemon属性;Bootstrap实例分别调用setAwait(true)、load、start方法;

Bootstrap实例初始化

简单描述下Boostrap初始化完成工作: 初始化类加载器、实例化Catalina、反射调用Catalina实例setParentClassLoader、Bootstrap持有Catalina实例。

一.初始化类加载器

这是Tomcat8.0官网中对ClassLoader的描述 Tomcat ClassLoader官网 ,Common就是此处的commonLoader, 至于下面还有两个 catalinaLoader 以及sharedLoader,为什么在8.0的源码中还存在呢?历史遗留问题,在Tomcat6.0以前的版本,类加载器结构是这样的 Tomcat5.5官网 。 所以在Tomcat6.0后仍然保留catalinaLoader、sharedLoader,只不过会发现他们指向commonLoader而已。

创建commonLoader类加载器

CatalinaProperties类静态代码块按照一下顺序尝试加载properties文件:从环境变量中读取catalina.config 、 或者catalina-home/conf/catalina.properties、或包org/apache/catalina/startup下catalina.properties,读取key-value并且通过System.setProperty保存在内存中,默认catalina-home/conf/catalina.properties文件中common.loader内容如下

common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar"

使用replace方法将${catalina.base}替换成之前系统变量、VM参数中读取的catalina.base,将${catalina.home}替换成读取到的catalina.home;

getPaths方法再讲上面拆分成字符数组,catalina.home/lib  、catalina.home/lib/*.jar ,因为catalina.home和catalina.base是一样的;

将上面得到路径实例化成Repository,仓库的意思,比如catalina.home/lib 就是RepositoryType.DIR目录类型仓库,catalina.home/lib/*.jar就是RepositoryType.GLOB全局类型仓库,

利用仓库实例化URLClassLoader,比如DIR目录类型的仓库,校验catalina.home/lib是否存在、是否可读、是不是目录,之后通过file://路径构件URL统一资源定位符;比如GLOB类型仓库,遍历

catalina.home/lib下所有jar,每一个jar文件构造一个URL,最后得到new URLClassLoader(URL[] urls).

总结commonLoader:就是加载catalina.home下lib包中所有jar文件,而catalinaLoader、sharedLoader在Tomca6.0就都指向commonLoader了!

二.Catalina实例化

setSecurityProtection方法给Catalina的package.definition以及package.access属性赋值,这两个包定义、包访问属性来自于catalina.home/conf/catalina.propreties

实例化完成之后,通过反射调用Catalina的setParentClassLoader方法,参数为sharedLoader,沿用了Tomcat6.0之前,但是Tomcat6之后取消了sharedLoader以及catalinaLoader, 都是CommonLoader.  接着让Bootstrap关联Catalina实例,放在Bootstrap实例daemon的catalinaDaemon属性里。

Bootstrap加载、启动

Bootstrap实例加载之前,会调用setAwait方法, 上面Boostrap实例daemon持有catalinaDaemon,这里通过反射调用catalinaDaemon的setAwait为true,目的是为了让Tomcat程序处于运行状态,接收HTTP请求,一旦设置为false,Tomcat容器只是启动运行一遍就停止,所以说这一步不得不设置标志位!

Bootstrap加载load

bootstrap实例daemon只是作为一个辅助启动类,load方法也是如此,通过反射调用catalinaDaemon的load方法。Catalina实例的load篇幅比较长,下一篇博文记录。

Bootstrap启动start

Bootstrap作为辅助类,可以说相当尽心尽力了,启动Tomcat也是通过反射交给Catalina实例的start方法来完成。

总结

Tomcat的加载配置文件、启动过程都不是在Bootstrap中完成,都是通过Bootstrap反射调用Catalina实例的load、start方法,来完成Tomcat容器的启动。

而我觉得Bootstrap到这一步最大的作用,在于实例化commonLoader,通过加载catalina.properties文件中的的common.loader;创建了一个CommonLoader,赋给Catalina作为parentClassLoader。