Resolution of server JAR package conflicts

it is normal to develop tests, and once deployed to a formal server, if the following types of exceptions occur, there is probably a jar package conflict:
1, Java class could not find Java.lang.ClassNotFoundException
2, method does not exist Java.lang.NoSuchMethodError
3, field does not exist Java.lang.NoSuchFieldError
4, class error Java.lang.LinkageErrorThe jar package in the war package conflicts with the jar package on the server, and because the server is now more powerful, the jar introduced is increasing.
The likelihood of conflicts is growing, and the formal environment is complex, and it is not easy to modify server-related configuration,
To solve the problem of jar package conflict is difficult, if to solve these problems, it is quite frustrating, the following is a summary of some methods.

Causes of conflict:
The root cause of this type of conflict is that there are multiple jar packages or classpath in the same Java class, most of which are caused by the use of different jar package versions.

Workaround:

1, case law
Use a jar package that already has an application on the server (provided that the server has already deployed other applications) and has used this method to resolve the conflict

2, minimization method
Formal environment there are many restrictions, upload, deploy, start and stop, test these processes the simpler the better, the last time the war package in 137jar deleted only 14 jar package,
The entire test verification cycle is greatly shortened

3, Source Law
If you can know which jar the class is loaded in, it is easier to solve it, and there will be the full class name of the error class in the exception.
If you can get this class loaded in that jar package, you can confirm the conflicting jar package,
How to know the class loaded in that jar package, yesterday brainwave thought of a method, in fact, is very simple, the code is as follows:

　　

4, Server Analysis method
Understanding the class loading mechanism of various application servers can determine what causes the conflict, which can be resolved by adjusting the class loading order.
A jar package conflict on the last was server was resolved on this method.

Refer to 4 ways to resolve server jar package conflicts

Tomcat Class Load Order
Files directory under Tomcat
/bin: A script file that holds Tomcat started and closed;
/conf: A variety of configuration files for Tomcat, such as: Server.xml
/server/lib: Various jar files required to store the Tomcat server (jar files can only be accessed by the Tomcat server)
/server/webapps: Two Web Apps from Tomcat: admin app and manager app.
/common/lib: A jar folder that can be accessed by the Tomcat server and all Web applications (this jar is accessible to both Web and tomcat servers)
/shared/lib: A jar file that is accessible to the Web. (can be accessed by all web, but not by Tomcat)
/logs: Log file that holds Tomcat
/webapps: When publishing a web app, the Web App file is placed in this directory by default
/work:tomcat put the servlet generated by the JSP in this directory

Another: In the WEB application, the Web-inf directory, you can also create a Lib subdirectory, in this subdirectory can hold a variety of jar files, these jar files are only accessible by the current WEB application. In the Web-inf directory, the Lib and classes directories, the Tomcat class loader first loads the classes under the Classes directory, and then loads the classes under the Lib directory. Classes takes precedence because the class has the same name.

Where the JSP runs, the order of the lookup class is: Project folder (web-inf\lib), container folder (tomcat\common\lib)->jdk folder (Jdk\jre\lib\ext)
Tomcat is an upward-looking hierarchy, either downward or configurable.

Learn More

A complete jar package conflict resolution process

Troubleshooting Jar Pack Conflict Issues Summary

Analysis and solving process techniques of jar packet dependency conflict in interface test

Resolution of server JAR package conflicts