Do not place third-party jar packages in the container's lib, package third-party jars that are not provided by the container into the project, and container-supplied jars are not packaged in the jar package. When the project runs, it detects the jar package that the project itself enters, and then goes to the container's lib to look for the jar package.
Why not put a third-party jar package in a container?
Because the package like Common\lib is relatively general and stable package, if you put a few of these projects shared several identical packages in, a certain time seems to be a lot less documents, but the future demand changes, there may be some projects need to compare the new version of the Lib package, and some projects do not need or upgrade requirements, Also just want the old version of the Lib package, while the new version of the Lib package and rely on some other packages, and to delete some if put in will produce the wrong package. Return is the dependency of the package is more troublesome. You may only consider one project, and the other will be in trouble when the project is not considered.
Also, different middleware, classloader loading order is not the same
There may be some differences in tomcat,jetty,jboss,websphere,weblogic, so projects that can be deployed to Tomcat do not necessarily put the entire war package under JBoss to run normally (although JBoss is based on Tomcat).
Like Tomcat
A list of the precedence orders for Tomcat class loading
1. First is the jar file under $java_home/jre/lib/ext/.
2. The Jar and class files in the environment variable CLASSPATH.
3. $CATALINA the class file under _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 the JDBC driver, can be placed here so that you can avoid a situation where the JDBC driver is not found in Server.xml configuration of the data source.) )
7. $CATALINA the class file under _home/server/classes.
8. $CATALINA the jar file under _home/server/lib/.
9. $CATALINA the class file under _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 file under the respective specific webapp/web-inf/lib.
The search order for class is as follows:
-------------
Bootstrap classes of your JVM
System class loader classses (described above)
/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
The ClassLoader in WebLogic has 5 levels, from high to low rows:
A. JDK
B. JDK Ext
C. System Classpath
D. (App-inf/classes and App-inf/lib)
E. (Web-inf/classes and Web-inf/lib)
Tomcat is the opposite of WebLogic in some places: for Web applications running in Java EE containers, the ClassLoader is implemented differently than a typical Java application. Different WEB containers are implemented differently. As with Apache Tomcat, each WEB application has a corresponding ClassLoader instance. The ClassLoader also uses the proxy mode, and the difference is that it is the first attempt to load a class if it cannot find a proxy to the parent class loader. This is contrary to the order of the generic ClassLoader. This is the recommended practice in the Java Servlet specification, which is designed to give the Web application its own class precedence over those provided by the Web container. One exception to this proxy pattern is that the class of the Java core library is not within the scope of the lookup. This is also to ensure the type safety of the Java Core library.
Reference article:
Deploy the multi-project jar under Tomcat
WebLogic and Java class loader principle test analysis
Storm/java Web project referenced by the jar that put the container under Lib?