Analysis and solution of abnormal problem of loading jar in tomcat

Description of the phenomenon:

The project uses springboot to start a web project. During the startup phase, an exception appeared in the console: "1.10.3-1.4.3\hdf5.jar The system cannot find the specified file." Although these exceptions do not affect the normal operation of the project, as a rigorous technician, seeing these exceptions is like seeing an enemy, and they must be eliminated as soon as possible.

java.io.FileNotFoundException: D:\.m2\repository\org\bytedeco\javacpp-presets\hdf5-platform\1.10.3-1.4.3\hdf5.jar (The system cannot find the file specified.)
 at java.util.zip.ZipFile.open(Native Method)
 at java.util.zip.ZipFile.<init>(ZipFile.java:225)
 at java.util.zip.ZipFile.<init>(ZipFile.java:155)
 at java.util.jar.JarFile.<init>(JarFile.java:166)
 at java.util.jar.JarFile.<init>(JarFile.java:130)
 at org.apache.tomcat.util.compat.JreCompat.jarFileNewInstance(JreCompat.java:188)
 at org.apache.tomcat.util.scan.JarFileUrlJar.<init>(JarFileUrlJar.java:65)
 at org.apache.tomcat.util.scan.JarFactory.newInstance(JarFactory.java:49)
 at org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:374)
 at org.apache.tomcat.util.scan.StandardJarScanner.processURLs(StandardJarScanner.java:309)
 at org.apache.tomcat.util.scan.StandardJarScanner.doScanClassPath(StandardJarScanner.java:266)
 at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:229)
 at org.apache.jasper.servlet.TldScanner.scanJars(TldScanner.java:262)
 at org.apache.jasper.servlet.TldScanner.scan(TldScanner.java:104)
 at org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:101)
 at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5204)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1421)
 at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1411)
 at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
 at java.util.concurrent.FutureTask.run(FutureTask.java)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at java.lang.Thread.run(Thread.java:748)

2019-03-29 18:09:08.303 WARN 16940 --- [ost-startStop-1] oatomcat.util.scan.StandardJarScanner : Failed to scan [file:/D:/.m2/repository/org/bytedeco/javacpp-presets/hdf5-platform/1.10.3-1.4.3/hdf5-linux-x86.jar] from classloader hierarchy

java.io.FileNotFoundException: D:\.m2\repository\org\bytedeco\javacpp-presets\hdf5-platform\1.10.3-1.4.3\hdf5-linux-x86.jar (The system cannot find the file specified.)
......
2019-03-29 18:09:08.578 WARN 16940 --- [ost-startStop-1] oatomcat.util.scan.StandardJarScanner : Failed to scan [file:/D:/.m2/repository/org/bytedeco/javacpp-presets/hdf5-platform/1.10.3-1.4.3/hdf5-linux-x86_64.jar] from classloader hierarchy

java.io.FileNotFoundException: D:\.m2\repository\org\bytedeco\javacpp-presets\hdf5-platform\1.10.3-1.4.3\hdf5-linux-x86_64.jar (The system cannot find the file specified.)

Project environment description

• tomcat: Use springboot built-in version 8.5.29
• Dependency Management with Maven
• Spring boot version is 2.0.1
• Spring framework version is 5.0.5
• The project references Deep Learn 4 Java (a great Java machine learning library)

 <dependency>
 <groupId>org.deeplearning4j</groupId>
 <artifactId>deeplearning4j-core</artifactId>
 <version>1.0.0-beta3</version>
 </dependency>

Problematic jar dependencies

Tracking Analysis

Since the error is reported during the startup phase, find the startup class and add a breakpoint, track step by step which stage the error is reported, and then analyze the cause of the error. I traced and debugged the springboot code and found the loading location of the jar. The main classes and methods are as follows:

Tracking class org.apache.tomcat.util.scan.StandardJarScanner

Method doScanClassPath(...)

This method will traverse all classloaders and load the jar package in each classloader.

The red part of the above icon is the key code, where the variable classPathUrlsToProcess stores all the jar information to be loaded, mainly the jar package path information. We can see that it is the same as the jar package we saw in Maven.

• Method processURLs(...)

This method will perform a stack operation on all jars of the current classloader, that is, classPathUrlsToProcess, and then process each jar package. The key codes are as follows.

• Method process()

This method will load and analyze each jar, focusing on

processManifest(jar, isWebapp, classPathUrlsToProcess) 

• Method processManifest

This method processes the Manifest file in the jar, separates the Class-Path in the Manifest file, and inserts the content into classPathUrlsToProcess as a new dependent jar (the processURLs method loads the jar in the stack result)

Cause Analysis

In fact, the problem lies in the classpath in the manifest file. By analyzing the code, we know that in addition to loading the jar package managed by our maven, tomcat will also analyze the manifest file in the jar. If there is a classpath in it, it will also add the content in it to the jar package dependency and load these jar packages.

We open the manifest file of hdf5-1.10.3-1.4.3.jar as an example to see where the error occurs.

Have you noticed that the jar package here has no path or version number, which causes tomcat to load it according to the path of hdf5-1.10.3-1.4.3.jar.

However, these jars do not exist in the corresponding locations in our project, which leads to the exception that the jars cannot be found. We actually have these jars in our project, but the paths and names are different. On the left side of the picture above, you can see that these jars are already available in Maven, but the version numbers are added after the names, and the paths are in their respective Maven repositories.

At this point we have figured out the cause of the problem, and now let's consider how to solve it.

Solution

Option 1:

Delete the classpath in the Manifest or delete the Manifest file to avoid loading non-existent jar packages. However, every time Maven is updated, your changes may be overwritten, causing the exception to occur again.

Option 2:

According to the path prompted by the load, copy the corresponding jar package and rename it to remove the version number, but this will cause jar redundancy, and the same jar will be loaded twice.

Option 3:

Downgrade the Tomcat version to 8.5.0 or earlier. In version 8.5.0, the manifest will not be analyzed and loaded, so our exception will not occur.

Option 4

Add code settings to not scan Manifest files.

 @Bean
 public TomcatServletWebServerFactory tomcatFactory() {
  return new TomcatServletWebServerFactory() {
   @Override
   protected void postProcessContext(Context context) {
    ((StandardJarScanner) context.getJarScanner()).setScanManifest(false);
   }
  };
 } 

Summarize:

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM.