Bug 59862 - Allow Nested Jar Scanning to be Filtered with System Property
Summary: Allow Nested Jar Scanning to be Filtered with System Property
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 8
Classification: Unclassified
Component: Util (show other bugs)
Version: 8.0.36
Hardware: All All
: P2 normal (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-15 07:53 UTC by Terence Bandoian
Modified: 2016-08-13 19:59 UTC (History)
0 users



Attachments
Modifies ClassPathEntry inner class in StandardJarScanner.java to use name of last JAR specified by path of given URL. (526 bytes, patch)
2016-07-15 07:53 UTC, Terence Bandoian
Details | Diff
Jar scanner issue demonstration project. (9.12 KB, application/x-zip-compressed)
2016-07-17 22:31 UTC, Terence Bandoian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Terence Bandoian 2016-07-15 07:53:10 UTC
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.
Comment 1 Violeta Georgieva 2016-07-17 15:16:57 UTC
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
Comment 2 Violeta Georgieva 2016-07-17 16:42:33 UTC
Hi,

I was too fast in applying the patch.
Can you provide a simple example that demonstrates the issue?

Thanks,
Violeta
Comment 3 Terence Bandoian 2016-07-17 22:31:53 UTC
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
Comment 4 Christopher Schultz 2016-07-18 16:56:54 UTC
Why is this necessary? J2EE doesn't support jars-within-jars, does it? Scanning jars-within-jars would be non-spec-compliant.
Comment 5 Terence Bandoian 2016-07-18 18:03:38 UTC
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.
Comment 6 Mark Thomas 2016-08-11 21:37:22 UTC
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.
Comment 7 Mark Thomas 2016-08-11 21:47:36 UTC
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
Comment 8 Terence Bandoian 2016-08-13 19:59:05 UTC
Thanks for looking into this, Mark. I appreciate your diligence and objectivity.