Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Upgrade from Tomcat 8.0.39 to 8.0.41 results in 'failed to scan' errors

Tags:

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.

like image 758
user1408140 Avatar asked Feb 19 '17 16:02

user1408140


People also ask

Is Tomcat 8 backwards compatible?

x noteable changes. The Tomcat developers aim for each patch release to be fully backwards compatible with the previous release.

What is TLD scanning in Tomcat?

On startup, Tomcat recursively scans the WEB-INF directories for TLD (Tag Library Descriptor) files. As a result, if a webapp has a lot of files under that directory, it slows down the startup process.


1 Answers

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.

like image 98
dur Avatar answered Nov 05 '22 20:11

dur