Tomcat6 class Loader definition (class class load order)

Website address: 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:
As shown in the chart above, Tomcat6 creates the ClassLoader in the following order when initializing:

Bootstrap-this class loader contains the basic runtime classes provided by the Java Virtual Machine, plus any classes fr Om JAR files present in the System Extensions directory ($JAVA _home/jre/lib/ext). Note:some JVMs may implement the as more than one class loader, or it may is visible (as a class loader) at all.

Bootstrap-This class loader contains the basic Run-time classes provided by the JAVA virtual machine, as well as all classes under the System Extension class directory ($JAVA _home/jre/lib/ext). Note: Some Java virtual machines may implement the ClassLoader or other ClassLoader more than once, or they may not be visible at all (as a class loader is invisible). ）

System-this class loader is normally initialized from the contents of the CLASSPATH environment. 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, and itself build the System class instead from T He following repositories:

System-This class loader usually initializes the contents of the environment variable CLASSPATH. All of these classes are visible regardless of the internal class of Tomcat or the Web program. However, the standard Tomcat startup script ($CATALINA _home/bin/catalina.sh or%catalina_home%\bin\catalina.bat) completely ignores the CLASSPATH environment variable parameter itself, instead, It builds the System class loader from the following libraries:

$CATALINA _home/bin/bootstrap.jar-contains The Main () method, which is used to initialize the TOMCAT server, and th E class Loader Implementation classes it depends on.
: $CATALINA _home/bin/bootstrap.jar-contains the main () method used to initialize the Tomcat server, and the class loader implements the classes it relies on.  )

$CATALINA _base/bin/tomcat-juli.jar and $CATALINA _home/bin/tomcat-juli.jar-logging implementation Classes. These include the enhancement classes to java.util.logging API, known as Tomcat Juli, and a package-renamed copy of Apache Com Mons Logging Library used internally by Tomcat. Logging documentation for more details.
$CATALINA _base/bin/tomcat-juli.jar and $CATALINA _home/bin/tomcat-juli.jar-log implementation class. They contain the enhanced class of the Java.util.logging API, the Tomcat Juli, and a library that replicates the name of the library Apache Commons logging that was used internally by Tomcat. For more information, you can view the logging log documentation.

$CATALINA _home/bin/commons-daemon.jar-the classes from Apache Commons daemon project.

$CATALINA _home/bin/commons-daemon.jar-These classes come from the Apache Commons daemon "translator Note: Commons daemon can help you achieve a common Java Application into a backend service for the system. For example, Tomcat uses this project to implement a "project that starts and stops as a service for Linux and Windows." ）
The Tomcat-juli.jar and Commons-daemon.jar JARs in $CATALINA _home/bin are not present in the CLASSPATH built by catalina.b At|. SH scripts, but are referenced from the manifest file of Bootstrap.jar.

Tomcat-juli.jar and Commons-daemon.jar These two jar packages in the $catalina_home/bin path are not in the catalina.bat|. SH script is built in the classpath, but it is referenced by Bootstrap.jar manifest file. ）

As shown in the figure:

If $CATALINA _base and $CATALINA _home do differ and $CATALINA _base/bin/tomcat-juli.jar does exist, the startup scripts would Add it to CLASSPATH before Bootstrap.jar and so Java'll look in $CATALINA _base/bin/tomcat-juli.jar for classes Befo Re it'll look into the $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 is recommended to remove Tomcat-juli.jar F Rom $CATALINA _home/bin So, only one copy of the ' file is ' present on the classpath. The next version of Tomcat, Tomcat 7, takes different approach here.
If $CATALINA _base and $CATALINA _home is not the same and $CATALINA _base/bin/tomcat-juli.jar does not exist, the startup script adds it to the Bootstrap.jar before it is loaded CLASSPATH so that Java loads the $CATALINA before loading the class in the Bootstrap.jar that references the $CATALINA _home/bin/tomcat-juli.jar _base/bin/ The class in the Tomcat-juli.jar. It works in most cases, and if you use these configurations, it is recommended that you remove the Tomcat-juli.jar from the $CATALINA _home/bin directory so that there is only one copy of this file in Classpath. In the next version of Tomcat, Tomcat 7, different methods are used here. ）

Common-this class loader contains additional classes that are made the to visible Tomcat both internal and to all we b applications.

common-This class loader contains other classes that are visible to both the Tomcat inner class and all Web programs. ）
Normally, application classes should not being placed here. The locations searched by this class loader are defined by the Common.loader property in $CATALINA _base/conf/catalina.prop Erties. The default setting would search the following locations in the order they are listed:
Typically, the application's class should not be placed here. This class loader searches for the location defined in the Common.loader attribute in the $CATALINA _base/conf/catalina.properties file. The default setting searches for the location listed below:)

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:
(translation: By default, the following files are included)

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 the other languages. As default bundles are also included in all individual jars, they can be safely removed if no internationalization of mess Ages is needed.
Webappx-a class loader is created to each Web application this is deployed to A single Tomcat instance. All unpacked classes and the/web-inf/classes directory-your WEB application, plus classes and resources I n JAR files under The/web-inf/lib directory of your Web application, are made visible to this Web application, but 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 be processed, this class loader would look I n the local repositories, instead of delegating before looking. There are exceptions. Classes which are part of the JRE base Classes cannot is overriden. For some classes (such as the XML parser components in J2SE), the 1.4+ J2SE and 1.4 can be endorsed. Last, no JAR file that contains Servlet API classes'll be explicitly ignored by the classloader-do not include such J ARs in your Web application. All other class loaders in Tomcat 6 follow the usual delegation pattern.

In summary, the Web program ClassLoader is separated from the default Java 2 delegate model (consistent with the servlet 2.4 version, the Web program ClassLoader part 9.7.2). When there are request requests sent from the class loader under WEBAPPPX, the class loader will first look in the local library, not before the delegate. There is an anomaly. A class based on the JRE section cannot be overridden. For some classes (like the XML parsing component in j2se1.4+), j2se4.1 is supported. Finally, any jar file that contains the Servlet API class will be explicitly ignored by such classloader-not included in your Web application jar. All other class loader follows the usual delegate mode in Tomcat 6. "This paragraph does not quite understand, just translated the literal meaning"

Therefore, from the perspective of a Web application, class or resource loading looks in the following repositories, in th Is Order:
Therefore, from the perspective of a Web application, a class or resource loading in a library appears in this order:

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)

The JVM's BootStrap-->> System class loader-->> The classes in your WEB program/web-inf/classes directory-->> Your program/web-inf/lib/*.jar-- >> Common class loader.XML parsers and JavaStarting with Java 1.4 a copy of the JAXP APIs and a XML parser are packed inside the JRE. This has impacts in applications that wish to use their own XML parser.
A copy of the JAXP APIS and XML parser is packaged in the JRE, starting with the java1.4 version. This will have an effect on the program that wants to own the XML parser. ）

In old versions of Tomcat, your could simply replace the XML parser in the Tomcat libraries directory to change the parser Used by the all Web applications. However, this technique'll is effective when you are are running modern versions of Java, because the usual class loader Delegation process would always choose the implementation inside the JDK in preference to this one.
In older versions of Tomcat, you can simply replace the XML parser in the Tomcat Library directory to change the parser used by all Web applications. Then, when you run the modern version of Java, such a child will not work, because the usual ClassLoader delegate process will always prefer to prioritize the classes implemented in JDK rather than using the ClassLoader in 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 the consortium). 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 supports a mechanism called "support standard override mechanism" to allow alternate APIs to be created outside the JCP (for example, Dom, SAX from the consortium). It can also be used to update XML parser implementations. For more information, see: 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 isn't created by default.

(Tomcat uses this mechanism by setting the-djava.endorsed.dirs= $JAVA _endorsed_dirs on the command line that starts the Web container, the default value for this option is: $CATALINA _home/endorsed.) This support directory is not created by default. ）
Running under a security manager

When running under a security manager the locations from which classes are permitted to be loaded'll also depend on the Contents of your policy file. HOW-TO the security Manager is for further information.

(the security manager that runs in a permitted class loading location also depends on the content of your policy file.) For further information, see the Security Manager guide. ）