PathMatchingResourcePatternResolver provides duplicate resources with relative URL [SPR-14934] #19501
Comments
Stéphane Nicoll commented While working on this issue, we've discovered a Spring Boot issue as well, check #7449 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Stéphane Nicoll opened SPR-14934 and commented
This is a regression introduced by #18260
PathMatchingResourcePatternResolver#doFindAllClassPathResources
first gets the path returned by theLaunchedUrlClassLoader
which will add the URLs of all nested jar + the URL ofBOOT-INF-classes
, something likeURL [jar:file:/Users/snicoll/workspace/pivotal/spring-framework-issues/SPR-13685/target/SPR-13685-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes!/]
Because we need to get all XML files from the root (path is the empty string) we also invoke
addAllClassLoaderJarRoots
which works recursively as follow:LaunchedUrlClassLoader
classLoader.getSystemClassLoader()
addsURL [jar:file:/Users/snicoll/workspace/pivotal/spring-framework-issues/SPR-13685/target/SPR-13685-0.0.1-SNAPSHOT.jar!/]
AppClassLoader
) addsURL [jar:file:SPR-13685-0.0.1-SNAPSHOT.jar!/]
viaaddClassPathManifestEntries
. It also adds a bunch of entries from JDK jarsExtClassLoader
So we have the following entries for the candidate location:
So, for the same
a.xml
at the root of the classpath insrc/main/resources
we end up with the following candidates:At this point I can only guess that each entry match each candidate in the list above (in that order). it isn't obvious how the second one lead to a lookup in
BOOT-INF/classes
though but given that a!
is missing in the second case, it's an indication it may come from that faulty URL.A repro project is available
Affects: 4.3 GA
Issue Links:
The text was updated successfully, but these errors were encountered: