-
Notifications
You must be signed in to change notification settings - Fork 38.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix PathMatchingResourcePatternResolver
manifest classpath discovery
#33705
Conversation
Update `PathMatchingResourcePatternResolver` so that in addition to searching the `java.class.path` system property for classpath enties, it also searches the `MANIFEST.MF` files from within those jars. Prior to this commit, the `addClassPathManifestEntries()` method expected that the JVM had added `Class-Path` manifest entries to the `java.class.path` system property, however, this did not always happen. The updated code now performs a deep search by loading `MANIFEST.MF` files from jars discovered from the system property. To deal with potential performance issue, loaded results are also now cached. The updated code has been tested with Spring Boot 3.3 jars extracted using `java -Djarmode=tools`. See spring-projectsgh-33705
110fee4
to
5e5d11b
Compare
|
Digesting this PR and reviewing occurrences of the problem elsewhere, the topic seems rather involved. For example, classgraph/classgraph#20 (comment) claims that such manifest entries are actually meant to be URLs, not file paths. The approach taken there seems similar to ours in terms of manifest parsing, so I suppose we can proceed with this PR but we should review our assumptions in terms of file path parsing, accepting URLs as well? Overall, @philwebb - is there a particular driver for submitting this PR for the 6.1.x branch? Such a signifcant refactoring in such a subtle core area seems better off in 6.2 for me, fixing the problem for Boot 3.4 rather than 3.3.x. If that's acceptable, could you please review the definition of manifest entries (URLs vs file paths) from your perspective and revisit the PR accordingly - and while in the process of this, rebase it onto |
Nothing other than I considered it a bug so I thought an earlier branch might be better. I'll rebase it onto
I think this code is the current source of truth and it does look a little more involved than my PR. I will try to align our logic with theirs. |
5e5d11b
to
c78a213
Compare
Update `PathMatchingResourcePatternResolver` so that in addition to searching the `java.class.path` system property for classpath enties, it also searches the `MANIFEST.MF` files from within those jars. Prior to this commit, the `addClassPathManifestEntries()` method expected that the JVM had added `Class-Path` manifest entries to the `java.class.path` system property, however, this did not always happen. The updated code now performs a deep search by loading `MANIFEST.MF` files from jars discovered from the system property. To deal with potential performance issue, loaded results are also now cached. The updated code has been tested with Spring Boot 3.3 jars extracted using `java -Djarmode=tools`. See spring-projectsgh-33705
@jhoeller Rebased to |
StringTokenizer tokenizer = new StringTokenizer(classPath); | ||
while (tokenizer.hasMoreTokens()) { | ||
String path = tokenizer.nextToken(); | ||
System.out.println("Hello "+path); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this System.out
was an early debug line? (I'm just pointing it out in case it should be removed before the merge).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@philwebb did you mean to have a debug log statement there? Or do you prefer to simply drop this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry! This stuff is hard to debug because breakpoints don't work. It was an accident. Will fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to replace it with an actual debug log or simply drop it, as you see fit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dropped it and force pushed
Update `PathMatchingResourcePatternResolver` so that in addition to searching the `java.class.path` system property for classpath enties, it also searches the `MANIFEST.MF` files from within those jars. Prior to this commit, the `addClassPathManifestEntries()` method expected that the JVM had added `Class-Path` manifest entries to the `java.class.path` system property, however, this did not always happen. The updated code now performs a deep search by loading `MANIFEST.MF` files from jars discovered from the system property. To deal with potential performance issue, loaded results are also now cached. The updated code has been tested with Spring Boot 3.3 jars extracted using `java -Djarmode=tools`. See spring-projectsgh-33705
c78a213
to
fe3c1b9
Compare
@jhoeller Will this be backported to 6.1.x line? Thanks in advance |
@juliojgd I don't think there are plans to backport due to the risk. See #33705 (comment) |
Update
PathMatchingResourcePatternResolver
so that in addition to searching thejava.class.path
system property for classpath enties, it also searches theMANIFEST.MF
files from within those jars.Prior to this commit, the
addClassPathManifestEntries()
method expected that the JVM had addedClass-Path
manifest entries to thejava.class.path
system property, however, this did not always happen.The updated code now performs a deep search by loading
MANIFEST.MF
files from jars discovered from the system property. To deal with potential performance issue, loaded results are also now cached.The updated code has been tested with Spring Boot 3.3 jars extracted using
java -Djarmode=tools
.