The order of the Tomcat load classes

The order of the Tomcat load classes
List of priorities for Tomcat class loading
1. The first is the jar file under $java_home/jre/lib/ext/.
2. jar and class files in the environment variable CLASSPATH.
3. The class file under the $CATALINA _home/common/classes.
4. $CATALINA the jar file under _home/commons/endorsed.
5. $CATALINA the jar file under _home/commons/i18n.
6. $CATALINA the jar file under _home/common/lib.
A jar file such as a JDBC driver can be placed here so that you can avoid the server.xml of the JDBC driver when you configure the data source. ）
7. The class file under the $CATALINA _home/server/classes.
8. $CATALINA the jar file under _home/server/lib/.
9. The class file under the $CATALINA _base/shared/classes.
$CATALINA the jar file under _base/shared/lib.
11. The class file under each specific webapp/web-inf/classes.
12. The jar files under each specific webapp/web-inf/lib.

As shown in the following illustration:



Bootstrap:uses JVM classes & looks in $JAVA _home/jre/lib/ext
1. |
2. System:uses $CATALINA _home/bin/bootstrap.jar and $JAVA _home/lib/tools.jar
3. |
4. |
5. Common:uses $CATALINA _home/common/lib
6.//And $CATALINA _home/common/classes
7.//And $CATALINA _home/common/endorsed
8.//>> JSP and servlet API jars are here
9./+-----------------------------------------------------------------+
10./|
Catalina:uses $CATALINA _home/server/lib |
$CATALINA _home/server/classes |
>> Catalina.jar are here |
Shared:uses $CATALINA _base/shared/lib
$CATALINA _base/shared/class Es
16.//
17.//
Webapp1 Webapp2 ... <--**gr eedy**
Classloaders
20.


/bin: Store script files to start and close Tomcat;
/conf: A variety of configuration files for Tomcat, such as: Server.xml
/server/lib: The various jar files needed to store the Tomcat server (jar files can only be accessed by Tomcat server)
/server/webapps: Two Web applications with Tomcat: Admin application and manager application.
/common/lib: A jar folder where the Tomcat server and all Web applications can be accessed (the jar is accessible to both Web and tomcat servers)
/shared/lib: Store jar files that are accessible to the Web. (can be accessed by all web, but not by Tomcat)
/logs: Log files for Tomcat
/webapps: When publishing a Web application, the Web application file is placed in this directory by default
/work:tomcat put the JSP-generated servlet in this directory
Another: In WEB applications, in the Web-inf directory, you can also create Lib subdirectories, where you can store various jar files that can only be accessed by the current WEB application. Among them, in the Web-inf directory of Lib and classes directory, Tomcat class loader first load the class under the classes directory, and then load the class under the Lib directory. Classes is preferred because the class has the same name.

where JSP runtime, find the Order of class is: Project folder (web-inf/lib) = = = "Container folder (tomcat/common/lib) = =" jdk folder (Jdk/jre/lib/ext)



The search order for class is as follows
-------------
/web-inf/classes of your WEB application
/web-inf/lib/*.jar of your WEB application
$CATALINA _home/common/classes
$CATALINA _home/common/endorsed/*.jar
$CATALINA _home/common/i18n/*.jar
$CATALINA _home/common/lib/*.jar
$CATALINA _base/shared/classes
$CATALINA _base/shared/lib/*.jar
--------------
Therefore, the class files placed in different webapp are loaded into different instances by ClassLoader.
For example, suppose the following two different classes of content. Placed in a different WebApp class directory.
Package Com.lizongbo;
public class TestClass {
Private String name= "Lizongbo";
}

Package Com.lizongbo;
public class TestClass {
Private String name= "Li_zongbo";
}

The Com.lizongbo.NAME results obtained in different webapp are different and do not affect each other.
Note, however, that the class exception begins with the following package name:
javax.*
org.xml.sax.*
org.w3c.dom.*
org.apache.xerces.*
org.apache.xalan.*

PS, note. The/meta-inf/mainfest in each jar. The Class-path key value pairs in the MF file also provide the load precedence of the jar.
For example, the MAINFEST.MF contents of a jar are as follows:
manifest-version:1.0
Created-by:lizongbo
Class-path:commons-beanutils.jar
Class-path:commons-collections.jar
Class-path:commons-dbcp.jar
Class-path:commons-digester.jar
Class-path:commons-logging.jar
Class-path:commons-pool.jar
Class-path:commons-services.jar
Class-path:commons-validator.jar
Class-path:jakarta-oro.jar
Main-class:com.lizongbo.mytestclass


Then, when loading this jar, it will first load the Commons-beanutils.jar,commons-collections.jar in the directory where the jar is located ... Wait for the jar file.

Placing jars and classes in different places can have unintended consequences, especially for different versions of JAR files, so be especially careful when deploying Web applications in real-world applications.

For example, use a common error message with JavaMail:
Javax.mail.NoSuchProviderException:No Provider for SMTP
The real reason is likely to be as follows:
Different versions of the Mail.jar are placed under different loading jars, such as a javamail1.3.1 Mail.jar
Under D:/jakarta-tomcat-5.5.8/common/lib, while the other one is javamail1.3.2 's Mail.jar in
Under D:/jakarta-tomcat-5.5.8/webapps/lizongbo/web-inf/lib,
The no provider for SMTP error occurs when Lizongbo in this webapp is used to send mail to JavaMail.