org.apache.catalina.startup.Bootstrap
第一步自然从main函数开始,我们可以从中看出bootstrap的初始化过程
main函数
首先是调用init方法 ,然后根据main的参数,比如start、startd、stop、stopd等等,启动或停止服务器
ps:start和startd的区别,感觉像是前者用于重新启动
init方法
设置系统属性:setCatalinaHome和setCatalinaBase,都是利用System.setProperty方法来实现。user.dir属性指向一个目录,catalina.home属性指向user.dir目录下的bootstrap.jar文件,该文件不存在则指向user.dir本身。catalina.base和catalina.home一样
初始化classloader
创建了三个classloader:common,server,shared ,以server为例,创建过程是:
查找server.loader系统变量,其中包含了以”,“分隔的文件路径(可能是URL、JAR、目录),称为repository。对repository做一些处理后(主要是替换其中的其他环境变量名,以得到完整的绝对路径),利用同一个包里面的另一个类ClassLoaderFactory,来真正产生classloader 。最后将生成的classloader作为mbean保存
Thread.currentThread().setContextClassLoader(catalinaLoader) 把生成的catalinaLoader作为当前线程上下文的classloader
利用反射机制,正式载入org.apache.catalina.startup.Catalina类,创建类的实例,并调用该类的setParentClassLoader方法。最后,将该实例赋值给Bootstrap类的catalinaDaemon对象(这个对象类型是Object),完成初始化
回到main函数
假设命令参数为start,则依次调用bootstrap的setAwait、load、start方法,这三个方法原理都一样,都是通过反射,实际调用刚才初始化生成的catalinaDaemon的同名方法
例:start方法中的反射代码
Method method = catalinaDaemon.getClass().getMethod("start", (Class [] )null);
method.invoke(catalinaDaemon, (Object [])null);
Bootstrap类剩下的几个方法:stop、stopServer,都是和start、load一样,通过反射调用catalinaDaemon的同名方法(其实就是org.apache.catalina.startup.Catalina类)
总结:
1.反射的大量使用
无论是classloader,还是具体的某个类,都是通过反射实现初始化和方法调用的。思路是:配置文件->系统属性->解析属性字符串->得到类路径->反射,得到类->方法调用
这样可以使服务器的实现类很容易被替换,降低耦合性,减少将来代码的改动,的确是一种优秀的设计模式思想
启动类的配置文件比较简单,都是简单的“键-值”,所以直接用了StringToken解析字符串。后面的代码牵涉到xml配置文件时,必定会换成xml解析器。但总体思路应该类似
2.JMX的使用
Bootstrap的JMX用得很少,仅仅对类装载器进行mbean注册,相信后面会有更多JMX的身影
org.apache.catalina.startup.ClassLoaderFactory
顾名思义,是tomcat专门用来产生classloader的工厂类
包括三个重载方法createClassLoader,内容都大同小异,无非是根据传入的类路径参数,产生一个相应的类装载器
tomcat的类路径分为:包含class文件的目录、jar文件、包含jar的目录和URL
以Bootstrap类用到的createClassLoader方法为例
参数为:(String locations[],Integer types[], ClassLoader parent)
locations即为类路径的字符串表示,types为对应的类路径的类型,这两个数组的长度肯定是相同的,parant即为父classloader
方法的处理逻辑很简单,即根据每个location的类型,对location字符串做处理,如取得绝对路径、遍历目录、判断是不是jar文件等等
从代码可以看到,ClassLoaderFactory产生的classloader其实都是org.apache.catalina.loader.StandardClassLoader,这个类装载器留待以后研究
org.apache.catalina.startup.Catalina
Bootstrap中,是通过start方法启动Catalina的
Catalina中包含一个server实例,对应server.xml中的server元素。如果server实现了Lifecycle,start首先将server实例作为生命周期对象进行启动。然后,在JDK的Runtime中注册一个Shutdownhook。最后,如果指定了await参数,则让Catalina停止
start方法代码如下:
public void start() {
if (server == null) {
load();
}
long t1 = System.nanoTime();
// Start the new server
if (server instanceof Lifecycle) {
try {
((Lifecycle) server).start();
} catch (LifecycleException e) {
log.error("Catalina.start: ", e);
}
}
long t2 = System.nanoTime();
if(log.isInfoEnabled())
log.info("Server startup in " + ((t2 - t1) / 1000000) + " ms");
try {
// Register shutdown hook
if (useShutdownHook) {
if (shutdownHook == null) {
shutdownHook = new CatalinaShutdownHook();
}
Runtime.getRuntime().addShutdownHook(shutdownHook);
}
} catch (Throwable t) {
// This will fail on JDK 1.2. Ignoring, as Tomcat can run
// fine without the shutdown hook.
}
if (await) {
await();
stop();
}
}
Shutdownhook是一个Thread对象,用于给JVM在收到停止命令时(例如Ctrl C),运行这些Thread执行收尾工作,具体用法可以参考JAVA文档
CatalinaShutdownHook在这里就是执行Catalina.stop方法,所以在Catalina.stop方法里面,会手动删除Runtime中的CatalinaShutdownHook,以防止调用两次stop,如下:
// Remove the ShutdownHook first so that server.stop()
// doesn't get invoked twice
if (useShutdownHook) {
Runtime.getRuntime().removeShutdownHook(shutdownHook);
}
Catalina也有个main函数,不过里头调用的方法都是已废弃的,估计是遗留代码
main函数主要是对命令行参数进行解析,比如可以取代默认的server.xml路径,其余工作主要交给load和start方法
load方法
按以下顺序读取配置文件server.xml,通过Digester类进行解析
1.configFile字段指明的配置文件“conf/server.xml”
2.Catalina的类装载器的getResource方法(具体原理不清楚,似乎很神奇。和装载类的机制一样,propagate方式,父装载器优先)
3.最后是从内置的catalina.jar的server-embed.xml读入配置
一旦读取成功,则后面的不读取,优先级依次降低
load方法最后进行配置和server的初始化,调用server.initialize方法
其中,Digester类似乎很神奇很强大,可以根据一定的规则,对一个xml源文件进行解析,然后执行相应的动作,留待以后研究。这里有一篇文章可以参考
http://software.ccidnet.com/pub/article/c322_a31671_p2.html
stop方法
// Shut down the server
if (server instanceof Lifecycle) {
try {
((Lifecycle) server).stop();
} catch (LifecycleException e) {
log.error("Catalina.stop", e);
}
}
stopserver方法
比起stop方法要复杂得多,不是简单地调用server.stop,而是通过创建一个Digester,根据配置文件的定义进行动作;然后,以非常“原始”的方法:建立到server的socket连接,以字节流的方式,一个个字符地发送tomcat的“SHUTDOWN”指令,如下:
// Stop the existing server
try {
String hostAddress = InetAddress.getByName("localhost").getHostAddress();
Socket socket = new Socket(hostAddress, server.getPort());
OutputStream stream = socket.getOutputStream();
String shutdown = server.getShutdown();
for (int i = 0; i < shutdown.length(); i++)
stream.write(shutdown.charAt(i));
stream.flush();
stream.close();
socket.close();
} catch (IOException e) {
log.error("Catalina.stop: ", e);
System.exit(1);
}
补充
在看完StandardServer后,回到Catalina,现在对于Catalina的stop和stopServer方法的区别又多了一些理解。
关于StandardServer的笔记:
Catalina的stop方法,其实是调用StandardServer.stop,进而停止StandardServer内部的各个Service,是名副其实的真正“停止”服务器
而stopServer方法,其实是构造一个socket连接到StandardServer的await方法打开的端口上,并发送SHUTDOWN命令。如前面所述,await只是起到阻塞作用,接受到SHUTDOWN命令后则await结束阻塞,并返回。具体要做哪些操作,还得由调用await的代码来决定。
现在先姑且认为,Catalina的stop方法是单纯的、Catalinal自己定义的一个停止服务器的函数,里面的实现都是封装在Catalina内部的,完成的工作就是停止服务器的socket和相关的Service服务,外人无法改动。
假如有第三方希望在停止server之前做点别的事情(比如释放特定的资源、或者通知其他组件),那么可以利用stopServer方法,待到await返回后,先完成自己要做的事情,最后再回头调用Catalina.stop(),完成最终的“停止” 。
通过这样的设计,tomcat给了外部代码,或者说基于tomcat的二次开发人员很大的灵活性,不必拘泥于tomcat本身的实现,也有利于tomcat自身的功能扩展。