Tomcat6类加载器定义(class类加载顺序)

官网地址：https://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html#Class_Loader_Definitions

Class Loader Definitions

As indicated in the diagram above, Tomcat 6 creates the following
class loaders as it is initialized:

（译：就像上面图表说明的那样子，Tomcat6 在初始化的时候，按照以下顺序创建类加载器：）

Bootstrap — This class loader contains the basic runtime classes provided by the Java Virtual Machine, plus any classes from JAR files present in the System Extensions directory ($J***A_HOME/jre/lib/ext). Note: some JVMs may implement this as more than one
class loader, or it may not be visible (as a class loader) at all.



（译：Bootstrap —这个类加载器包含了Java虚拟机提供的基本运行时类，还有系统扩展类目录($J***A_HOME/jre/lib/ext)下的所有类。 注意：一些Java虚拟机可能不止一次地实现了该类加载器或者别的类加载器，否则可能根本就不可见(作为一个类加载器不可见)。）

System — This class loader is normally initialized from the contents of the CLASSPATH environment variable. All such classes are visible to both Tomcat internal classes, and to web applications. However, the standard Tomcat startup scripts ($CATALINA_HOME/bin/catalina.sh
or %CATALINA_HOME%\bin\catalina.bat) totally ignore the contents of the CLASSPATH environment variable itself, and instead build the System class loader from the following repositories:



（译：System —这个类加载器通常初始化环境变量CLASSPATH中的内容。 所有的这些类不管对Tomcat的内部类还是对web程序都是可见的。然而,标准的Tomcat启动脚本($CATALINA_HOME/bin/catalina.sh or %CATALINA_HOME%\bin\catalina.bat)完全忽略CLASSPATH环境变量参数本身，取而代之，它从下列库中构建System类加载器 ：）

$CATALINA_HOME/bin/bootstrap.jar — Contains the main() method that is used to initialize the Tomcat server, and the class loader implementation classes it depends on.

（译：$CATALINA_HOME/bin/bootstrap.jar —包含用于初始化Tomcat服务器的 main()方法，而且这个类加载器实现了它依赖的那些类。 ）

$CATALINA_BASE/bin/tomcat-juli.jar and $CATALINA_HOME/bin/tomcat-juli.jar — Logging implementation classes. These include enhancement classes to java.util.logging API, known as Tomcat JULI, and a package-renamed copy of Apache Commons Logging library used internally
by Tomcat. See logging documentation for more details.

（译：$CATALINA_BASE/bin/tomcat-juli.jar and $CATALINA_HOME/bin/tomcat-juli.jar —日志实现类。 它们包含 java.util.logging API的加强类，即 Tomcat JULI，和一个修改了包名的复制了Tomcat内部使用的库 Apache Commons Logging 的库。详细信息可以查看logging日志说明文档。）

$CATALINA_HOME/bin/commons-daemon.jar — The classes from Apache Commons Daemon project.

（译：$CATALINA_HOME/bin/commons-daemon.jar — 这些类来自Apache Commons Daemon 【译者注：Commons Daemon 可以帮你实现将一个普通的 Java 应用变成系统的一个后台服务。例如 Tomcat 就是利用这个项目来实现作为 Linux 和 Windows 的服务启动和停止的】项目。）

The tomcat-juli.jar and commons-daemon.jar JARs in $CATALINA_HOME/bin are not present in the CLASSPATH built by catalina.bat|.sh scripts, but are referenced from the manifest file of bootstrap.jar.

（译：tomcat-juli.jar and commons-daemon.jar 这两个在$CATALINA_HOME/bin 路径中的jar包 并没有在由 catalina.bat|.sh 脚本构建的CLASSPATH 中出现， 但是却被 bootstrap.jar 的 manifest 文件引用。）

如图所示：



If $CATALINA_BASE and $CATALINA_HOME do differ and $CATALINA_BASE/bin/tomcat-juli.jar does exist, the startup scripts will add it to CLASSPATH before bootstrap.jar, so that Java will look into $CATALINA_BASE/bin/tomcat-juli.jar for classes before it will look
into $CATALINA_HOME/bin/tomcat-juli.jar referenced by bootstrap.jar. It should work in most cases but, if you are using such configuration, it might be recommended to remove tomcat-juli.jar from $CATALINA_HOME/bin so that only one copy of the file is present
on the classpath. The next version of Tomcat, Tomcat 7, takes different approach here.

（译：如果 $CATALINA_BASE and $CATALINA_HOME 不一样并且 $CATALINA_BASE/bin/tomcat-juli.jar 不存在，那么启动脚本会在 bootstrap.jar 加载之前把它添加到 CLASSPATH，这样 Java 将在 引用了 $CATALINA_HOME/bin/tomcat-juli.jar 的 bootstrap.jar 中加载类之前去加载 $CATALINA_BASE/bin/tomcat-juli.jar 中的类。它在大多数情况下是可以正常运行的，如果你使用了这些配置，推荐移除
$CATALINA_HOME/bin 目录下的 tomcat-juli.jar，这样在classpath中就只有一个此文件的拷贝了。在Tomcat的下一个版本 Tomcat 7 中， 在此使用了不同的方法。）

Common — This class loader contains additional classes that are made visible to both Tomcat internal classes and to all web applications.

（译：Common — 这个类加载器包含了对Tomcat内部类和所有的Web程序都可见的其他的类。 ）

Normally, application classes should NOT be placed here. The locations searched by this class loader are defined by the common.loader property in $CATALINA_BASE/conf/catalina.properties. The default setting will search the following locations in the order they
are listed:

（译：通常，应用程序的类不应该放在这里。这个类加载器会搜索定义在 $CATALINA_BASE/conf/catalina.properties 文件中 common.loader 属性里写的位置。默认设置会搜索列在下面的位置：）

unpacked classes and resources in $CATALINA_BASE/lib

JAR files in $CATALINA_BASE/lib

unpacked classes and resources in $CATALINA_HOME/lib

JAR files in $CATALINA_HOME/lib

By default, this includes the following:

（译：默认地，包含了下列文件）

annotations-api.jar — JavaEE annotations classes.

catalina.jar — Implementation of the Catalina servlet container portion of Tomcat.

catalina-ant.jar — Tomcat Catalina Ant tasks.

catalina-ha.jar — High availability package.

catalina-tribes.jar — Group communication package.

ecj-*.jar — Eclipse JDT Java compiler.

el-api.jar — EL 2.1 API.

jasper.jar — Tomcat Jasper JSP Compiler and Runtime.

jasper-el.jar — Tomcat Jasper EL implementation.

jsp-api.jar — JSP 2.1 API.

servlet-api.jar — Servlet 2.5 API.

tomcat-coyote.jar — Tomcat connectors and utility classes.

tomcat-dbcp.jar — Database connection pool implementation based on package-renamed copy of Apache Commons Pool and Apache Commons DBCP.

tomcat-i18n-**.jar — Optional JARs containing resource bundles for other languages. As default bundles are also included in each individual JAR, they can be safely removed if no internationalization of messages is needed.

WebappX — A class loader is created for each web application that is deployed in a single Tomcat instance. All unpacked classes and resources in the /WEB-INF/classes directory of your web application, plus classes and resources in JAR files under the /WEB-INF/lib
directory of your web application, are made visible to this web application, but not to other ones.

As mentioned above, the web application class loader diverges from the default Java 2 delegation model (in accordance with the recommendations in the Servlet Specification, version 2.4, section 9.7.2 Web Application Classloader). When a request to load a class
from the web application's WebappX class loader is processed, this class loader will look in the local repositories first, instead of delegating before looking. There are exceptions. Classes which are part of the JRE base classes cannot be overriden. For some
classes (such as the XML parser components in J2SE 1.4+), the J2SE 1.4 endorsed feature can be used. Last, any JAR file that contains Servlet API classes will be explicitly ignored by the classloader — Do not include such JARs in your web application. All
other class loaders in Tomcat 6 follow the usual delegation pattern.

（译：综上所述，web程序类加载器是从默认的 java 2 委托模型中分离出来的(和Servlet 2.4 版本一致，Web 程序类加载器部分9.7.2)。当有从 WebApppx 下的类加载器发送的request请求过来时，这个类加载器将首先在本地库找，而不是委托前看。是有异常的。基于JRE部分的类是不能被重写的。对于一些类（像 J2SE1.4+ 中的 XML 解析组件），J2SE4.1 是支持的。最后，任何包含Servlet API类的JAR文件将被显式地忽略这样的类加载器——不包括在您的web应用程序JAR。所有其他类装入器在Tomcat
6遵循通常的委托模式。）【这一段不太理解，只是翻译了字面意思】

Therefore, from the perspective of a web application, class or resource loading looks in the following repositories, in this order:

（译：因此,从一个web应用程序的角度来看,类或资源在库中加载看起来是按此顺序:）

Bootstrap classes of your JVM

System class loader classes (described above)

/WEB-INF/classes of your web application

/WEB-INF/lib/*.jar of your web application

Common class loader classes (described above)

JVM 的 BootStrap -->> System 类加载器-->>
你的web程序中/WEB-INF/classes 目录下的类 -->>
你的程序中/WEB-INF/lib/*.jar-->> Common类加载器。

XML Parsers and Java

Starting with Java 1.4 a copy of JAXP APIs and an XML parser are packed inside the JRE. This has impacts on applications that wish to use their own XML parser.

（译：从java1.4版本开始， JAXP APIS 和 XML parser 的各一个拷贝被打包在了 JRE里。这对想要自己的XML 解析器的程序会有影响。）

In old versions of Tomcat, you could simply replace the XML parser in the Tomcat libraries directory to change the parser used by all web applications. However, this technique will not be effective when you are running modern versions of Java, because the usual
class loader delegation process will always choose the implementation inside the JDK in preference to this one.

（译：在旧版本的Tomcat中，您可以简单地替换Tomcat库目录中的XML解析器来改变所有web应用程序所使用的解析器。然后，等你运行现代版本的Java时，这样子将不会奏效，因为通常的类加载器委托过程将总是偏向于优先使用JDK中实现的类而不是用Tomcat中的类加载器。）

Java supports a mechanism called the "Endorsed Standards Override Mechanism" to allow replacement of APIs created outside of the JCP (i.e. DOM and SAX from W3C). It can also be used to update the XML parser implementation. For more information, see: http://docs.oracle.com/javase/1.5.0/docs/guide/standards/index.html.
（译：Java支持一种叫“支持标准重写机制”的机制来允许替换APIs去创建JCP之外（例如：来自W3C的DOM 、SAX ）。它也可以用来更新XML解析器实现。有关更多信息,请参见:http://docs.oracle.com/javase/1.5.0/docs/guide/standards/index.html。）

Tomcat utilizes this mechanism by including the system property setting -Djava.endorsed.dirs=$J***A_ENDORSED_DIRS in the command line that starts the container. The default value of this option is $CATALINA_HOME/endorsed. This endorsed directory is not created
by default.

（Tomcat通过在启动Web容器的命令行中设置 -Djava.endorsed.dirs=$J***A_ENDORSED_DIRS 来使用这个机制， 这个选项的默认值是：$CATALINA_HOME/endorsed。这个支持目录不是默认创建的。）

Running under a security manager

When running under a security manager the locations from which classes are permitted to be loaded will also depend on the contents of your policy file. See Security Manager HOW-TO for further information.

（当运行在一个允许类加载位置的安全管理器也取决于你的策略文件内容。进一步的信息,请参阅安全性管理器指南。）