Upgrade from Tomcat 8.0.39 to 8.0.41 results in 'failed to scan' errors
There was a bug, that Tomcat 8 ignores the Class-Path
header in the MANIFEST.MF
file of a JAR, see Bug 59226:
Bug 59226 - StandardJarScanner ignores jars in manifest Class-path header
This bug was fixed with Tomcat 8.0.34, but it produced a lot of warnings for not required JARs, see Bug 59961:
Bug 59961 - Provide an option to disable processing of Class-Path entry in a jar's manifest file
Since Tomcat 8.0.38 you can disable the scan of the MANIFEST.MF
file, see The Jar Scanner Component:
scanManifest
If true, the Manifest files of any JARs found will be scanned for additional class path entires and those entries will be added to the URLs to scan. The default is true.
user1408140
Updated on July 09, 2022Comments
-
user1408140 almost 2 years
I have a Spring Boot WAR application perfectly working under Tomcat 8.0.39 on AWS. After issuing
sudo service tomcat8 stop
, upgrading to Tomcat 8.0.41 throughsudo yum update
, and rebooting the instance, the application does not start. In the catalina log file, I see a ton of exceptions of the type:19-Feb-2017 10:27:15.326 WARNING [localhost-startStop-1] org.apache.tomcat.util. scan.StandardJarScanner.scan Failed to scan [file:/usr/share/java/tomcat8/javax. annotation-api.jar] from classloader hierarchy java.io.FileNotFoundException: /usr/share/java/tomcat8/javax.annotation-api.jar (No such file or directory)
Here are the files Tomcat complains about:
javax.annotation-api.jar jsr181-api.jar jaxb-api.jar javax.xml.soap-api.jar FastInfoset.jar mimepull.jar saaj-impl.jar stax2-api.jar woodstox-core-asl.jar jaxb-core-2.2.10-b140802.1033.jar jaxb-api-2.2.12-b140109.1041.jar istack-commons-runtime-2.19.jar txw2-2.2.10-b140802.1033.jar hk2-core.jar class-model.jar config.jar auto-depends.jar javax.inject.jar hk2-api.jar osgi-resource-locator.jar tiger-types.jar bean-validator.jar jtype.jar
Any suggestions on how to fix this?
Update #1:
Some of the above files belong to
jaxws-ri
. It turned out that I had some (10), but not all (23), of the jars from JAX-WS RI 2.2.10lib
directory copied into Tomcat'slib
directory. After copying the missing 13 jars, the list of files Tomcat complains about in the catalina log file has shrunk to:jaxb-core-2.2.10-b140802.1033.jar jaxb-api-2.2.12-b140109.1041.jar istack-commons-runtime-2.19.jar txw2-2.2.10-b140802.1033.jar hk2-core.jar class-model.jar config.jar auto-depends.jar javax.inject.jar hk2-api.jar osgi-resource-locator.jar tiger-types.jar bean-validator.jar jtype.jar
(Exceptions for the above files are repeated several times in the log file. Looks like the scanner is invoked repeatedly at startup, perhaps scanning different class paths.)
This tells me that with the transition from 8.0.39 to 8.0.41, Tomcat suddenly became very picky about the presence of all referenced jars, even though the application works perfectly fine without many of them. In addition, Tomcat appears to be very particular about specific builds of some jars (e.g. see the
jaxb-core...
andjaxb-api...
jars above).Now, to fix this I could try to find all these missing jars and copy them to Tomcat's
lib
directory. However, I see no way of assuring the proper source for some of them due to generic names, such asconfig.jar
, or missing version numbers.So, is there a way to prevent Tomcat's
scan.StandardJarScanner.scan
from being so picky about all these jars?
Update #2:
It turns out that in Tomcat 8.0.38, a setting was added to control jar scanning, the value of which defaults to
true
. To turn scanning off, add the following line incontext.xml
:<Context> ... <JarScanner scanManifest="false"/> </Context>
For details, see Provide an option to disable processing of Class-Path entry in a jar's manifest file.