Hello,

We have recently upgraded to Spring Boot 2.4 and spring cloud config 3.x and have encountered a possible regression, or at least a modification that is not documented.

A normal application in our project usually has 3 property sources: - from a configuration server, retrieved with a specific profile; - from an application.yml in a library imported by every applications. This yaml describes several default properties that are used in each application; - from a config/application.yml inside the application. We put it in the config folder so that it does not prevent the library's application.yml to be loaded.

Previously the order of precedence (as seen in the env actuator endpoint) was: 1. from configuration server; 2. from config/application.yml; 3. from the library's application.yml.

However after upgrading the order has changed: 1. from config/application.yml (previously 2nd); 2. from configuration server (previously 1st); 3. from the library's application.yml.

I am not sure whether this is a problem in Spring Cloud or Spring Boot, or whether it is simply an undocumented change, but I think this modification could warrant a warning in the documentation.

I can try to reproduce the issue with a small project if necessary.

Thank you for your time.

Comment From: celcius112

Ok found it. It is caused by spring.config.import=configerserver... property being set in the base application.yml, and as such the configuration from the server is bound to the classpath resource ./ and will be prioritized only against this. We removed the bootstrap way during the upgrade.

Do you think it could warrant a warning in the documentation ? It is a well hidden difference and I think it is a strong argument between using the bootstrap vs the spring.config.import property at the moment.

Comment From: celcius112

I have created this small project to reproduce the regression when using bootstrap vs Spring Boot 2.4's configuration: https://github.com/celcius112/spring-cloud-config-client-regression

Comment From: spencergibb

This is a side effect of the spring boot import and currently out of the control of spring cloud.

See https://github.com/spring-cloud/spring-cloud-consul/issues/702#issuecomment-776872839 for ways to alter the behavior if you are affected.

We will document this behavior.

Comment From: celcius112

Hello @spencergibb and thank you for your answer. And thank you for the documentation.

Out of curiosity, could we expect some changes in Spring Boot about this issue in the long-term ? The solutions you propose are fine but sound a bit too hacky in the long-run.

Comment From: spencergibb

That will be up to the boot team. @philwebb is aware.

Comment From: spencergibb

See https://github.com/spring-projects/spring-boot/issues/25766

Comment From: danparisi

Hi @celcius112, it seems I'm having the same issue you faced. I'm expecting my services to load the configuration in this order (higher on top in the following list):

  1. service-name-profile.yml from consul config/ directory
  2. service-name.yml from consul config/ directory
  3. resources/config/application.yml from the service classpath
  4. resources/application.yml from the a common library classpath

In common-library/resources/application.yml I've:

spring:
  profiles:
    active: profile
  config:
    import: optional:consul:consul:8500/

But it seems that 2. is not working, same as it was for you as far as I understood. How did you fix that? I'd like consul property files to always have the higher precedence.

Comment From: spencergibb

You might be seeing something similar, but in consul. See the issue here https://github.com/spring-cloud/spring-cloud-consul/issues/706

If you are using 2020.0.3 please open a new issue in spring-cloud-consul with a sample