Describe the bug I have a project that uses bootstrapping. Since spring-cloud-config 3.0.5, property files defined outside of the deliverable (jar or war) are no longer added as a property source. In spring-cloud-config 3.0.4, this was still working.

Sample See next comment

It was introduced by #1904.

I debugged the differences, and the problem occurs in the clean() method in NativeEnvironmentRepository. This method calls a new private method called matchesLocations. This method loops over some configuration patterns, but in the final if in this loop, there is always a return statement, which means that if the property source could not be found in the first pattern (classpath:/ in my case), false is returned, instead of the loop continuing to the next pattern, where a match still could be found.

Instead of always returning here, we should only return if the result of the pipeline is true.

Comment From: thundur

cloud-config-bug.zip I made a small Spring Boot program that demonstrates the bug.

If you run the program and visit http://localhost:8080/, you will see that the URL returns 'classpath', which is the property value as defined in a property file in the class path.

If you run the program with -Dspring.config.additional-location=file:///C:/temp/ (or any other folder) as a command line parameter and if you have put the properties file from the zip below in that folder before running, the URL still returns 'classpath'. application-demo.zip

If you either downgrade spring-cloud.version to 2020.0.3 or define 3.0.4 as the version of spring-cloud-config-server, the URL will return 'external', as is the expected behavior.

Also note that if you downgraded either version, you see these log lines:

2021-10-08 14:50:42.010  INFO 24352 --- [           main] o.s.c.c.s.e.NativeEnvironmentRepository  : Adding property source: Config resource 'file [C:\temp\application-demo.properties]' via location 'file:///C:/temp/'
2021-10-08 14:50:42.011  INFO 24352 --- [           main] o.s.c.c.s.e.NativeEnvironmentRepository  : Adding property source: Config resource 'class path resource [application-demo.properties]' via location 'classpath:/'

If you run the program without downgrading any version, only the second log line is printed.

Comment From: Maarten-Damen

@spencergibb, @philwebb is there any update possible conserning this issue or should we look for a way to work around this?

Comment From: nickcaballero

Running into the same issue. We use spring.config.import to incorporate shared property files. However, the imported files fail the matchesLocation test and are ignored. As @thundur pointed out, it's because matchesLocations exits early instead of testing all possible location patterns.

Comment From: thundur

@ryanjbaxter, @spencergibb, @philwebb this issue is ignored since I created it. What is required for me to do so you would take a look?

Comment From: ryanjbaxter

Sorry for the delay here. I am still on vacation but I believe the code causing the problem was changed (fixed?) here https://github.com/spring-cloud/spring-cloud-config/commit/4636ddb3b5aaf15a843581844bd6bf709c7fa3ee#diff-6e42942d6c70c5ad5dbf7bf796155f22e6dd24a953694cf090fcf087051add1e

Have you tried 3.0.6?

Comment From: spring-cloud-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Comment From: thundur

Sorry for the delay. I can confirm that this issue does not occur with spring-cloud-config 3.0.6 and 3.1.0.