Tomcat正统的类加载器架构

来源:互联网 发布:女人出轨 知乎 编辑:程序博客网 时间:2024/06/08 07:14

  一个功能健全的Web服务器,要解决如下几个问题:

  1)部署在同一个服务器上的两个Web应用程序所使用的Java类库可以实现相互隔离。

  2)部署在同一个服务器上的两个Web应用程序所使用的Java类库可以相互共享。

  3)服务器需要尽可能地保证自身的安全不受部署的Web应用程序影响。

  4)支持JSP应用的Web服务器,大多数都需要支持HotSwap功能。“主流”的Web服务器都会支持JSP生成类的热替换,当然也有“非主流”的,运行在生产模式(Production Mode)下的WebLogic服务器默认就不会处理JSP文件的变化。

  在Tomcat目录结构中,有3组目录(“/common/*”,“/server/*”,“/shared/*”)可以存放Java类库,另外还可以加上Web应用程序自身的目录“/WEB-INF/*”:

  1)放置在/common目录中:类库可被Tomcat和所有的Web应用程序共同使用。

  2)放置在/server目录中:类库可被Tomcat使用,对所有的Web应用程序都不可见。

  3)放置在/shared目录中:类库可被所有的Web应用程序共同使用,但对Tomcat自己不可见。

  4)放置在/WebApp/WEB-INF目录中:类库仅仅可以被此Web应用程序使用,对Tomcat和其它Web应用程序都不可见。

Tomcat服务器的类加载架构:


其中WebApp类加载器和Jsp类加载器通常会存在多个实例,每一个Web应用程序对应一个WebApp类加载器,每一个JSP文件对应一个Jsp类加载器。

从上图可以看出:CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用,而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。WebAppClassLoader可以使用SharedClassLoader加载到的类,但各个WebAppClassLoader实例直接相互隔离。而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个Class,它出现的目的就是为了被丢弃:当服务器检测到JSP文件被修改时,会替换掉目前的JasperLoader的实例,并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。

  对于Tomcat的6.x版本,只有指定了Tomcat/conf/catalina.properties配置文件的server.loader和share.loader项后才会真正建立CatalinaClassLoader和SharedClassLoader的实例,否则会用到这两个类加载器的地方都会用CommonClassLoader的实例代替,而默认的配置文件中没有设置这两个loader项,所以Tomcat6.x顺理成章地把/common、/server和/shared三个目录默认合并到一起变成一个/lib目录,这个目录里的类库相当于以前/common目录中类库的作用。

0 0
原创粉丝点击