PathMatchingResourcePatternResolver regression for jar root scanning in 6.2.4

[kristofdepypere]

Hi,

We are heavily relying on the ResourceLoader and more specifically the org.springframework.core.io.support.PathMatchingResourcePatternResolver. In a legacy codebase that we own, we are using this call very often: applicationContext.getResources("classpath*:**/some-file-pattern.xml") or any other type of pattern.

Since version 6.2.4 we clearly see a difference in behavior here. Compared to version 6.2.3 we observe that now nothing is returned while it was returning the expected resources in the previous version.

We also see a difference in behavior when running locally from IntelliJ compared to running the final WAR. Running locally in IntelliJ (which is obviously more 'File based' scanning than 'Jar based' scanning) everything works. Running in the final WAR, everything fails.
As it only occurs in the final runtime, it is very difficult to analyze the Spring code to pinpoint where the difference in behavior is caused. We do see changes in org.springframework.core.io.support.PathMatchingResourcePatternResolver as of 6.2.x and a small Exception change in 6.2.4, but we couldn't point to that 100% as being the root cause.

Can you help us out here? What could have caused this difference in behavior ?

[sdeleuze]

Could you please provide a minimal reproducer as an attached project or a link to a repository allowing to see change of behavior?

[kristofdepypere]

That's hard. As mentioned, locally running the project will not give any insights, it only happens when running the real deal and connecting through remote debugging. The code will simply be the line shown above, the setup is highly manual anyway.

[jhoeller]

Could you try to debug through PathMatchingResourcePatternResolver.findPathMatchingResources a bit and see what happens (that is, whether it backs out of certain root paths to analyze or the like)?

Between 6.2.3 and 6.2.4, we only had one defensive change in terms of jar entries caching (#34446) which I don't see as immediately related. Maybe that specific part if worth debugging though, just in case we were missing a side effect there: see PathMatchingResourcePatternResolver.doFindPathMatchingJarResources (line 810 ff).

To be clear, PathMatchingResourcePatternResolver got quite heavily revised in 6.2 for internal jar caching. A general side effect from that effort could still be lurking here, in particular since you only experience it for war/jar scenarios, and I'd be happy to fix that for 6.2.5 based on your analysis.

[kristofdepypere]

I'll try, I already did, but I'll try more. A lot is happening there and indeed, caching is probably impacting behavior, so I only get to dive in once per application restart.

[jhoeller]

If that is easier to do for a start, let's double-check the behavioral difference between 6.2.3 and 6.2.4: There is just that one change in PathMatchingResourcePatternResolver mentioned above, and it'd be great to know whether that specifically causes the regression that you are experiencing, or whether the regression is somehow triggered by the general 6.2 revision before and not immediately related to that 6.2.4 change.

Aside from downgrading to 6.2.3, you could also manually patch PathMatchingResourcePatternResolver to undo that change but otherwise stay on spring-core in version 6.2.4 (since such specific patching would isolate the effect even better).