ITPub博客

首页 > IT基础架构 > 网络安全 > The Tomcat 4 Servlet/JSP Container下怎样装载类 (转)

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

原创 网络安全 作者:gugu99 时间:2007-12-04 08:08:30 0 删除 编辑
The Tomcat 4 Servlet/JSP Container下怎样装载类 (转)[@more@]

以下的规则覆盖了大约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 ...

 XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />

 

这些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%bincatalina.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种也会得到应用。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10748419/viewspace-987765/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 递归与goto (转)
请登录后发表评论 登录
全部评论
  • 博文量
    3122
  • 访问量
    2245958