Created attachment 34041 [details] Modifies ClassPathEntry inner class in StandardJarScanner.java to use name of last JAR specified by path of given URL. StandardJarScanner.java does not match nested JARs (jars within jars) to patterns defined by the system property tomcat.util.scan.StandardJarScanFilter.jarsToSkip. The proposed change will allow nested JARs to be matched and should not modify filtering of non-nested JARs.
Hi, Thanks for the report and the patch. This has been fixed in - 9.0.x for 9.0.0.M10 onwards, - 8.5.x for 8.5.5 onwards and - 8.0.x for 8.0.37 onwards Regards, Violeta
Hi, I was too fast in applying the patch. Can you provide a simple example that demonstrates the issue? Thanks, Violeta
Created attachment 34049 [details] Jar scanner issue demonstration project. To demonstrate the issue, build, change to the target directory and execute the resulting jar: java -jar jar-scanner-bugzilla-59862-1.0.0.jar To capture the output in a file: java -jar jar-scanner-bugzilla-59862-1.0.0.jar > tomcat.log 2>&1 To test the patch, uncomment line 68 and rebuild. Thanks. -Terence
Why is this necessary? J2EE doesn't support jars-within-jars, does it? Scanning jars-within-jars would be non-spec-compliant.
Does J2EE specifically prohibit scanning nested JARs? If not, then there would be nothing "non-spec-compliant" about doing so. Tomcat already scans nested JARS. The proposed modification allows users to limit which nested JARS are scanned using the existing Tomcat "jarsToSkip" feature. IMHO, this is the expected behavior of that feature. Nested JARs are used extensively (e.g. Spring Boot). The proposed modification allows for faster startup in that type of environment by changing one line in an existing Tomcat class that supports an existing Tomcat feature.
It was me that voiced concerns over this that led to the original commits being reverted. I've now found the time to come back to this. As far as the Servlet spec is concerned, JARs are located in WEB-INF/lib and those JARs are not checked to see if they contain nested JARs. However, the container is free to provide any mechanism it sees fit to augment the web application's class-path. Tomcat does this in a variety of ways but many of them boil down to providing a URL to a JAR to add to the class path. That URL can point to a JAR file within another JAR if you take advantage of the JarWarResourceSet (the outer JAR is treated as a WAR). Having had a chance to work through the implications of the proposed patch I'm happy that there are no issues. I'll get it re-applied.
Fix restored for: - 9.0.x for 9.0.0.M10 onwards, - 8.5.x for 8.5.5 onwards and - 8.0.x for 8.0.37 onwards
Thanks for looking into this, Mark. I appreciate your diligence and objectivity.