Tomcat loading class order

Tomcat loading class order
Overview of Tomcat class loading priorities
1. The first is the JAR file under $ java_home/JRE/lib/EXT.
2. jar and class files in the environment variable classpath.
3. $ catalina_home/common/classes Class file.
4. $ catalina_home/commons/endorsed JAR file.
5. $ catalina_home/commons/i18n.
6. $ catalina_home/common/lib.
(Jar files such as the JDBC driver can be placed here, so that the JDBC driver cannot be found after the data source is configured in server. xml .)
7. $ catalina_home/Server/classes Class file.
8. $ catalina_home/Server/lib.
9. $ catalina_base/shared/classes Class file.
10. $ catalina_base/shared/lib.
11. Their specific webapp/WEB-INF/classes under the class file.
12. Their specific webapp/WEB-INF/lib jar files.

As shown in:

 

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./|
11. Catalina: uses $ catalina_home/Server/lib |
12. and $ catalina_home/Server/classes |
13.> Catalina. jar is here |
14. Shared: uses $ catalina_base/shared/lib
15. And $ catalina_base/shared/classes
16 .//
17 .//
18. webapp1 webapp2... <-- ** greedy **
19. classloaders
20.
 

/Bin: stores script files for starting and disabling tomcat;
/Conf: stores various tomcat configuration files, such as server. xml.
/Server/lib: stores various jar files required by the Tomcat server (jar files can only be accessed by the Tomcat server)
/Server/webapps: stores two built-in Tomcat web applications: the admin application and the Manager application.
/Common/lib: stores jar folders accessible to Tomcat servers and all web applications (both web and tomcat servers can access this jar)
/Shared/lib: stores jar files accessible to the Web. (It can be accessed by all web sites, but cannot be accessed by Tomcat)
/Logs: stores Tomcat log files
/Webapps: When a web application is published, the Web application files are stored in this directory by default.
/Work: Tomcat stores the servlet generated by JSP in this directory.
In addition, you can create lib sub-directories under the web-INF directory for Web applications. Various jar files can be stored in these sub-directories. These jar files can only be accessed by the current web application. In the lib and classes directories under the web-INF directory, the Tomcat Class Loader first loads the classes under the classes directory and then the classes under the lib directory. Because the classes takes precedence over the same name.

When JSP is running, the order of the Search Class is: project folder (WEB-INF/LIB) ===" container folder (tomcat/common/LIB) = JDK folder (JDK/JRE/lib/EXT)

 

The search sequence of the 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, class files placed in different webapps are loaded into different instances by classloader.
For example, assume that the following two classes have different contents. Put them in the class directories of different webapps.
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 webapps are different and do not affect each other.
However, note that the following class exceptions start with the package name:
Javax .*
Org. xml. Sax .*
Org. W3C. Dom .*
Org. Apache. xerces .*
Org. Apache. xalan .*

PS, note. The class-path key-value pairs in the/META-INF/mainfest. MF file in each jar will also provide the jar loading priority.
For example, the mainfest. MF content of a jar is 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, first load the commons-beanutils.jar, commons-collections.jar first under the directory where the jar is located... And other jar files.

Placing jar and class in different places may have unexpected consequences, especially for different versions of jar files. Therefore, pay special attention to the actual application deployment of Web applications.

For example, a common error message of javamail is used:
Javax. Mail. nosuchproviderexception: no provider for SMTP
The real reasons are as follows:
Different Versions of mail. jar are placed in different directories for jar loading, such as a mail. jar file of javamail1.3.1.
In D:/jakarta-tomcat-5.5.8/common/lib, and the other is javamail1.3.2 mail. jar in
D:/jakarta-tomcat-5.5.8/webapps/lizongbo/WEB-INF/lib,
When javamail is used in the lizongbo webapp to send emails, the no provider for SMTP error will occur.