|Summary:||AbstractArchiveResourceSet#listWebAppPaths does not list directories if the zip central directory doesn't have them|
|Product:||Tomcat 9||Reporter:||Meelis Müür <meelis.myyr>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
Description Meelis Müür 2018-04-26 12:20:54 UTC
Consider a jar containing META-INF/resources/foo/bar.txt META-INF/resources/foo/baz.txt META-INF/resources/baz.txt The following are two examples of valid zip central directory listings for the above jar A: META-INF/ META-INF/resources/ META-INF/resources/foo/ META-INF/resources/foo/bar.txt META-INF/resources/foo/baz.txt META-INF/resources/baz.txt B: META-INF/resources/ META-INF/resources/foo/bar.txt META-INF/resources/foo/baz.txt META-INF/resources/baz.txt In A case AbstractArchiveResourceSet#listWebAppPaths("/") will return ["/foo/", "/baz.txt"] In B case AbstractArchiveResourceSet#listWebAppPaths("/") will return ["/baz.txt"] Considering the JavaDoc for WebResourceSet#listWebAppPaths states: Obtain the Set of the web applications pathnames of *all* of the files and *directories* located in the specified directory. This means the implementation is faulty in the B case. This bug caused an issue in JRebel when the following artifact was present: https://mvnrepository.com/artifact/org.webjars.bowergithub.vaadin/vaadin-button/2.0.0-beta3 Resulting in the lookup for "/webjars/vaadin-button/src/vaadin-button.html" to fail, as the central directory entry "/META-INF/resources/webjars/vaadin-button/src/" was missing and code eventually relied on listWebAppPaths to return the folder "src".
Comment 1 Meelis Müür 2018-04-27 08:38:40 UTC
Created attachment 35897 [details] Proposed patch Ran tests and validated that the initial issue with JRebel was resolved.
Comment 2 Mark Thomas 2018-04-27 10:03:41 UTC
Thanks for the report and the patch. It all looks good to me so the patch has been applied. Fixed in: - trunk for 9.0.8 onwards - 8.5.x for 8.5.31 onwards - 8.0.x for 8.0.52 onwards