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

31,058

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.

Share:
31,058
user1408140
Author by

user1408140

Updated on July 09, 2022

Comments

  • user1408140
    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 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.