AbstractFileResolvingResource.exists incorrectly reports result for resources inside of spring-boot executable jar

[betalb]

Starting from spring-core 6.2.5 AbstractFileResolvingResource.exists will return true for non existing resources within spring boot executable jar. Earlier versions reported correct value.

This seems to be a regression, introduced as a fix of #34607.

For us, it is causing problems with ReloadableResourceBundleMessageSource, which takes base names + locale and tries to load base properties file + 2 versions of locale aware files. In our case only base properties file exists and 2 others fail to load. ReloadableResourceBundleMessageSource relies on exists check to filter out non existing resources before trying to open stream and read them. But in spring 6.2.5 non existing resources are not filtered and it tries to load them, causing warning to be logged. Those messages spam a lot in logs.

Attaching example app with reproduction jar-loader.zip. Root pom file contains property spring-core.version which can be used to switch between 6.2.4 and 6.2.5

[jhoeller]

#34764 is probably also a consequence of the same AbstractFileResolvingResource.exists revision, even if the actual fix happened in PathMatchingResourcePatternResolver there. So it looks like we need to revise AbstractFileResolvingResource.exists itself as well.

[jhoeller]

A fix for this (which makes your repro project log the correct existence flags) is available in the latest 6.2.7 snapshot now. Please give it an early try in your actual scenario as well...

[jhoeller]

A revised check for this is coming to the next 6.2.7 snapshot, improving the consistency between jar root checks and jar entry checks.

[betalb]

I've checked, using snapshot version spring-core-6.2.7-20250423.083751-6.jar and it works as expected, thank you.

[jhoeller]

Good to hear! Thanks for the immediate feedback.