Upgrade from Tomcat 8.0.39 to 8.0.41 results in 'failed to scan' errors
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 through sudo 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.10 lib directory copied into Tomcat's lib 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... and jaxb-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 as config.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 in context.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.
Answer
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.