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 ($JAVA_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虛擬機器提供的基本執行時類，還有系統擴充套件類目錄($JAVA_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=$JAVA_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=$JAVA_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.

（當執行在一個允許類載入位置的安全管理器也取決於你的策略檔案內容。進一步的資訊,請參閱安全性管理器指南。）