ConfigFileApplicationListener filtering fails when the defaultPropertySource is a composite

[ryanjbaxter]

Prior to Boot 2.2.0 if you used spring-cloud-starter and within your bootstrap.yml set spring.config.name Boot would correctly load the property file specified in the property. Starting with Boot 2.2.0 this no longer works.

I have traced the breaking change down to this line added in commit d92c2f7

In the situation I described above defaultProperties is actually an instance of ExtendedDefaultPropertySource defined here.

The sources property, which is a composite, contains the value of spring.config.name in this case. However in ConfigFileApplicationListener.replaceDefaultPropertySourceIfNecessary the code just calls .getSource to construct the new defaultProperties so we loose the properties in the composite and therefore the spring.config.name property is never retrieved.

For a sample that reproduces the problem you can look at this test.

[philwebb]

See #15445

[ryanjbaxter]

@philwebb I read the issue, but that is all about profiles, this problem has nothing to do with profiles.

To add to this, I also think these changes broke this functionality as well, which does have to do with profiles.

[wilkinsona]

@ryanjbaxter The commit that you referenced fixed the issue that Phil referenced.

[philwebb]

@ryanjbaxter I just added a link to the issue referenced in commit d92c2f7

[ryanjbaxter]

@wilkinsona @philwebb sorry I misinterpreted what you were saying ;)

[philwebb]

@ryanjbaxter I tried to run BootstrapClientApplicationTests but the test passed for me so I'm not sure what I'm doing wrong. Any hints?

For BootstrapConfigurationTests it appears that the bootstrap local.properties are defining a spring.profiles.active key which we are now actively filtering out. I'm not really sure how we can fix this one and also fix #15445. They seem to be at odds with each other. Is there any reason that the bootstrap context needs to use a property source named defaultProperties? If it does, perhaps we need to offer a way to switch off the filtering just for that bootstrap context.

[ryanjbaxter]

@philwebb did you remove the @Ignore on the test in BootstrapClientApplicationTests?

Is there any reason that the bootstrap context needs to use a property source named defaultProperties?

@spencergibb @dsyer do you know? I am a little unsure.

[spencergibb]

I'm not sure either.

[philwebb]

@Ignore on the test

Doh! 🤦‍♂

[philwebb]

Actually, even with the @Ignore removed it appears to work

[ryanjbaxter]

Weird not sure, it is failing for me on my machine

[mbhave]

I'm able to reproduce this. As @ryanjbaxter mentioned, it's because we use defaultProperties.getSource() here. The ExtendedDefaultPropertySource used by Spring Cloud has the property sources wrapped inside a CompositePropertySource and defaultProperties.getSource() just returns an empty map. We could change the filtering logic so that it only applies to Spring Boot's default property source or only if the default property source is a MapPropertySource.

[philwebb]

@ryanjbaxter I've implemented the fix suggested by @mbhave, both Spring Cloud tests referenced in this issue work for me locally now.

[ryanjbaxter]

@philwebb I removed the @Ignore in BootstrapConfurationTests but the build still fails using Snapshots (I am going to add it back so we have a green build for now).
https://jenkins.spring.io/job/spring-cloud-commons-master-ci/8853/testReport/org.springframework.cloud.bootstrap.config/BootstrapConfigurationTests/includeProfileFromBootstrapProperties/

[wilkinsona]

FWIW, it also fails for me when built locally with ./mvnw -U clean verify.

[mbhave]

Looks like I was wrong about the same fix being able to fix both tests. I share what @philwebb said here:

I'm not really sure how we can fix this one and also fix 15445.

I don't think a solution where the filtering only applies for Boot's defaultProperties will work either. The ExtendedDefaultPropertySource wraps Boot's defaultProperties, so it would need to apply to that to be consistent.

[philwebb]

I swear it worked in my IDE :/

I've opened #17141 to look at the failing test. It feels like a different issue and the composite property source problem has been fixed so let's keep this issue just for that one.