`defaultProperties` property source is not propagated to the new context created in the LegacyContextRefresher for refreshing properties

[mzeijen]

Bug introduced with Spring Cloud Context version: 3.0.0

When the LegacyContextRefresher is used to refresh the Spring environment properties, the temporary context created by the LegacyContextRefresher, does no longer get the defaultProperties property source propagated from the original environment.

The reason for this is because the properties method of the SpringApplicationBuilder is now used to provide the spring.cloud.bootstrap.enabled=true property to the builder. This results in the defaultProperties property source from the copied environment to be overwritten by a new property map containing only the spring.cloud.bootstrap.enabled property.

To put this in sequence (with line references to the code):

• LegacyContextRefresher#updateEnvironment get called to update the environment
• It calls the addConfigFilesToEnvironment method
• The copyEnvironment is used to copy the defaultProperties and commandLineArgs property sources from the environment of the real context
• A SpringApplicationBuilder is created and it gets that copied environment but also the spring.cloud.bootstrap.enabled=true property via the properties build method.
• The builder.run() is called to build the temporary context and in this method:
  • the environment is prepared where it configures the property sources
  • here it is checked if the SpringApplicationBuilder has any properties
  • because the spring.cloud.bootstrap.enabled=true property is set on the SpringApplicationBuilder it will create a new DefaultPropertiesPropertySource and overwrite the one from the copied environment. Thus the original default properties are lost.

The solution would be to provide the spring.cloud.bootstrap.enabled=true via other means, for instance by adding it to the default properties of the copied environment, instead of using the properties method of the SpringApplicationBuilder.

[slyoldfox]

Also spend 3 hours to find this same case. I am not sure if this is a spring-cloud bug or also a spring-boot bug. Seems to me that DefaultPropertiesPropertySource might want to merge if another DefaultPropertiesPropertySource exists?

Could this be confirmed or am I doing something wrong, any workarounds? @philwebb

[philwebb]

@slyoldfox I think that makes sense. I don't think we ever considered the scenario before. I've raised spring-projects/spring-boot#25408