Align S3ConfigDataLocationResolver resolving behavior with Spring Boot resolvers

[MatejNedic]

📢 Type of change

• Bugfix
• New feature
• Enhancement
• Refactoring

📜 Description

Currently we are calling wrong method and not respecting profile (names) when looking for resources. We are not using profile name when finding the location to load which is intention of method, hence we should switch to resolve().

💚 How did you test it?

📝 Checklist

• I reviewed submitted code
• I added tests to verify changes
• I updated reference documentation to reflect the change
• All tests passing
• No breaking changes

🔮 Next steps

[maciejwalkowiak]

Is it just a refactoring or does it change anything in the behavior?

[MatejNedic]

It changes the behaviour. Since resolve is called before resolveProfileSpecific. Resolve is first scan that Spring Boot does, which means properties under file:/ and file:/config such as application-dev.properties won't impact the loading. With this we are now aligned by Spring Boots design in using ConfigDataLocationResolver. classpath:/ properties are not into account since their scan happens after.

Once if Spring Boot team decides to implement the following: spring-projects/spring-boot#43533 . We are gonna end with same thing since Binder itself will be the same one from resolve method, meaning it won't take into account previously loaded properties.

It is breaking change if you ask me since we are moving loading to happen before rather than after. We are slightly changing the behaviour itself.