Skip to content
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

Merged
merged 1 commit into from
Oct 22, 2024

Conversation

philwebb
Copy link
Member

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.

philwebb added a commit to philwebb/spring-framework that referenced this pull request Oct 15, 2024
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
@philwebb
Copy link
Member Author

philwebb commented Oct 15, 2024

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Oct 15, 2024
@bclozel bclozel added the in: core Issues in core modules (aop, beans, core, context, expression) label Oct 15, 2024
@jhoeller jhoeller added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Oct 16, 2024
@jhoeller jhoeller self-assigned this Oct 16, 2024
@jhoeller jhoeller added this to the 6.1.15 milestone Oct 16, 2024
@jhoeller
Copy link
Contributor

jhoeller commented Oct 21, 2024

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 main? I can take over from there then, bringing it into 6.2 GA for November.

@philwebb
Copy link
Member Author

is there a particular driver for submitting this PR for the 6.1.x branch?

Nothing other than I considered it a bug so I thought an earlier branch might be better. I'll rebase it onto main.

manifest entries are actually meant to be URLs, not file paths

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.

philwebb added a commit to philwebb/spring-framework that referenced this pull request Oct 21, 2024
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
@philwebb
Copy link
Member Author

@jhoeller Rebased to main and forced pushed. I've aligned with the JDK code as best I can, but it's unfortunately pretty hard to test this stuff.

@philwebb philwebb changed the base branch from 6.1.x to main October 21, 2024 22:02
@jhoeller jhoeller modified the milestones: 6.1.15, 6.2.0 Oct 22, 2024
StringTokenizer tokenizer = new StringTokenizer(classPath);
while (tokenizer.hasMoreTokens()) {
String path = tokenizer.nextToken();
System.out.println("Hello "+path);
Copy link

@juliojgd juliojgd Oct 22, 2024

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).

Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member Author

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
@jhoeller jhoeller merged commit 1c69a3c into spring-projects:main Oct 22, 2024
2 checks passed
jhoeller added a commit that referenced this pull request Oct 22, 2024
Includes consistent clearCache() behavior for manifest entries.

Closes gh-33771
See gh-33705
@juliojgd
Copy link

@jhoeller Will this be backported to 6.1.x line?

Thanks in advance

@philwebb
Copy link
Member Author

@juliojgd I don't think there are plans to backport due to the risk. See #33705 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants