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".
Created attachment 35897 [details] Proposed patch Ran tests and validated that the initial issue with JRebel was resolved.
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