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):
- service-name-profile.yml from consul config/ directory
- service-name.yml from consul config/ directory
- resources/config/application.yml from the service classpath
- 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