CSDN博客

img lucianliu

The Tomcat 4 Servlet/JSP Container下怎样装载类

发表于2003/5/26 11:36:00  579人阅读

以下的规则覆盖了大约95%的内容,关于开发者和配置者必须要做的工作,关于在什么地方放置类文件和资源文件来使他们变得有效。

对于那些特定某个web应用的类和资源文件,没有打包的类和资源文件放置在你的web应用路径的/WEB-INF/classe下,或者放置包含那些类和资源文件的JAR文件在/WEB-INF/lib

对于那些为所有的WEB应用所共享的WEB应用类和资源文件,没有打包的类和资源文件放置在$CATALINA_HOME/shared/classes下,或者放置那些包含类和资源文件JAR包在$CATALINA_HOME/shared/lib的下面。

序言

就像一些服务应用一样,tomcat4安装一个多样性的class loaders(就是执行java.lang.ClassLoader)类来允许容器的不同部分和网站应用运行在这个容器中,允许存取不同的类和资源的仓库。

Java 2 (that is, JDK 1.2 or later)环境中,class loaders被安排在一个父子树中。当一个class loader被要求装载一个类和资源的时候,他首先指定这个需求到一个父类中,然后寻找自己的需求在这个父类中,如果找不到再接着向下寻找。对于WEB应用的class loader也许或有细微的差别,但是主要的机制都是一样的。

When Tomcat 4 is started, it creates a set of class loaders that are organized into the following parent-child relationships, where the parent class loader is above the child class loader:

TOMCAT4启动的时候,他创建了一套以下父子关系的class loader,并且父类在子类的上面。

  

       Bootstrap

          |

       System

          |

       Common

      /      /

 Catalina   Shared

             /   /

        Webapp1  Webapp2 ...

 

 

这些class loaders的每一个特征(包括类和资源的源文件)在以下的章节中说明。

Class Loader 定义

就像以上的图表所显示的一样,TOMCAT4在初始化的时候创建以下的class loader

Bootstrap –这个class loader包含了JAVA虚拟机提供的基本运行时的环境类,还有任何当前系统扩展路径($JAVA_HOME/jre/lib/ext)下的JAR文件。注意-一些JAVA虚拟机也许需要多个class loader,或者也许不可见。

System –这个class loader通常从CLASSPATH环境变量的内容中初始化。所有这些类对于TOMCAT内部类和WEB应用都是可见的。但是TOMCAT4标准开始脚本($CATALINA_HOME/bin/catalina.sh 或者 %CATALINA_HOME%/bin/catalina.bat)完全忽略了他自己的CLASSPATH环境变量的内容,取而代之的是从以下的仓库中建立系统class loader

$CATALINA_HOME/bin/bootstrap.jar -包含了初始化TOMCAT4服务的主要方法,和他所依赖的class loader执行类。

$JAVA_HOME/lib/tools.jar -包含了JAVAC编译器,用于把JSP编译成SEVLET

 

Common -这个class loader包含了对于TOMCAT4和所有的WEN应用都可见的额外的类。通常,应用类不应该放置到这里。通过这类的装载,所有在$CATALINA_HOME/common/classes下的未打包的类和资源文件和在$CATALINA_HOME/commons/endorsed $CATALINA_HOME/common/lib directories下的打包的JAR文件都可以变得可见。在缺省的情况下主要包含了以下的包:

jndi.jar - JAVA命名和路径接口API类(只装载在JDK1.2系统中,因为在以后的JDK1.3版本中会被自动包含)。

naming-common.jar -TOMCAT4使用来说明存储器命名关联的JNDI实现

naming-resources.jar - 用来描述一个WEB应用的静态在院的专门的JNDI命名关联实现

servlet.jar - Servlet JSP API

xerces.jar -在缺省的情况下对于TOMCAT内部类和WEB应用可见的XML解析器。对于一个特殊的应用,我们可以在/WEB-INF/lib下包含我们自己的解析器来忽略这个解析器

Catalina -用来实现TOMCAT4初始化的时候包含他自己所有需要的类和资源。这些类和资源对于整个WEB应用是不可见的。所有的未打包的类和资源在$CATALINA_HOME/server/classes下,打包的JAR文件在$CATALINA_HOME/server/lib

 

因此,从这个WEB应用的观点可以看出,类或者资源装载在以下的仓库中,就是以下的顺序:

/WEB-INF/classes 你的WEB应用

/WEB-INF/lib/*.jar 你的WEB应用

你的JVM Bootstrap

系统class loader类(以上说明的)

$CATALINA_HOME/common/classes

$CATALINA_HOME/common/endorsed/*.jar

$CATALINA_HOME/common/lib/*.jar

$CATALINA_HOME/shared/classes

$CATALINA_HOME/shared/lib/*.jar

 

J2SE类和扩展

除了先前的规则,Web应用class loader将拒绝从JAVA语言核心包中装载("java.*" packages).

XML 解析器 JDK 1.4

就象一些其它的改变,JDK1.4发布了JAXP APIS包和Xerces的一个版本。这会影响那些希望使用他们自己的XML解析器。

在先前的TOMCAT4的版本,你可以简单的在$CATALINA_HOME/common/lib下覆盖XML解析器来改变所有的WEB应用的解析器。但是,当我们运行在JDK1.4的时候这个技巧不是很有效的,因为通常class loader委托过程总是选择JDK内部的实现。

JDK1.4通过调用"Endorsed Standards Override Mechanism" 来支持创建JCP(i.e. DOM and SAX from W3C)外部的机制。他也别用来更新XML解析实现。

TOMCAT在命令行开始一个容器的时候,通过包含系统恰当的设置-Djava.endorsed.dirs=$CATALINA_HOME/common/endorsed来调用系统的正确设置。因此,你可以取代安装在这个路径下的解析器,他甚至在JDK1.4种也会得到应用。

0 0

相关博文

我的热门文章

img
取 消
img