Fix Spring Boot WARN: Missing JAR Errors Caused by Tomcat’s Manifest Scanning

Background

Developers often treat exceptions as enemies: either fix them or hide them. A recent Spring Boot startup produced a flood of WARN messages about missing JAR files, which prompted a deep investigation.

Observed WARN Messages

2020-10-27 19:20:33.706  WARN 13099 --- [           main] o.a.tomcat.util.scan.StandardJarScanner  : Failed to scan [file:/Users/zzs/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1/jaxb-api.jar] from classloader hierarchy
java.io.FileNotFoundException: /Users/zzs/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1/jaxb-api.jar (No such file or directory)
...
2020-10-27 19:20:33.708  WARN 13099 --- [           main] o.a.tomcat.util.scan.StandardJarScanner  : Failed to scan [file:/Users/zzs/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1/activation.jar] from classloader hierarchy
java.io.FileNotFoundException: /Users/zzs/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1/activation.jar (No such file or directory)

These WARNs are noisy even though they do not stop the application.

Root Cause Analysis

Debugging the StandardJarScanner#doScanClassPath method revealed that Tomcat fails while loading JAR files because it cannot locate the files referenced in a JAR’s

META-INF/MANIFEST.MF

Class-Path

attribute.

Key steps observed during debugging:

In StandardJarScanner#doScanClassPath, addAll adds discovered URLs to a Deque<URL>. processURLs iterates over the queue, moving each URL to a processedURLs set.

When a URL ends with .jar, JarFactory creates a Jar object; the original WARNs stem from the failure to create this object because the referenced JAR does not exist.

The real problem occurs inside processManifest, which reads the JAR’s MANIFEST.MF, extracts the Class-Path entries, and concatenates them with the current JAR’s directory.

For the problematic dependency com/sun/xml/bind/jaxb-impl, the manifest lists a path like jaxb-api.jar without the version segment, resulting in an incorrect final path such as com/sun/xml/bind/jaxb-impl/xx/jaxb-api.jar where xx should be the version number. Consequently, Tomcat cannot find the file.

Solution Options

Delete the erroneous entries from MANIFEST.MF. This is not feasible when the JAR is provided by a third‑party library (e.g., Alibaba Cloud).

Place the missing JAR at the exact path expected by the manifest. This can cause duplicate JARs and increase artifact size, leading to potential conflicts.

Downgrade Tomcat to version 8.5.0 or lower, where the bug does not manifest.

Disable manifest scanning in Spring Boot by customizing the embedded Tomcat factory:

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

This prevents Tomcat from processing Class-Path entries in manifests, but it may hide legitimate dependencies if the manifest entries are actually needed.

Ignore the WARN messages entirely if they do not affect functionality (the least recommended approach).

Conclusion

Through systematic debugging, the article identifies that Tomcat’s manifest scanning builds incorrect class‑path entries, leading to WARN‑level FileNotFoundException s. The provided solutions range from editing manifests to disabling scanning altogether, giving developers practical ways to eliminate the noisy warnings.