I have the configserver in my setup with native as source for configs.
The corresponding config in the application.yaml of the config server:
spring:
application:
name: confighub
profiles:
active: native
cloud:
config:
server:
health.enabled: false
native:
searchLocations: classpath:/configs
Before the upgrade to spring boot 2.4 I used bootstrap.yaml with 2.3.x and older, then I had no ptoblem to have globally shared configs in the application.yaml, which resides in .../resources/configs.
But now the values are missing from the file. According to the documentation, the configserver config files are omitted (which is good):
“With the “native” profile (a local file system backend) , you should use an explicit search location that is not part of the server’s own configuration. Otherwise, the application* resources in the default search locations get removed because they are part of the server.”
But the application.yaml in the configs directory is not part of the configservers configuration file, the basename is just the same.
I just did a quick check in the configserver source, but it seems like the org.springframework.cloud.config.server.environment.NativeEnvironmentRepository#clean method may clean the application.yaml even when it resides in a different directory, which is wrong from my point of view.
Did I understand something wrong or is there a bug?
Comment From: pcornelissen
I did more digging and stepped through configserver:
When I request a config, in the mentioned cleanup method, the property source for the caml file located in configs/application.yaml is Config resource 'class path resource [configs/application.yaml]' via location 'classpath:/configs/' (Which is a weird name to begin with)
After the String replace actions afterwards you end up with class path resource [configs/application.yaml as value for the name variable.
And it's no surprise that this doesn't match any pattern which is fetched via getLocations(result.getName(), profile, result.getLabel()).getLocations()
The closes match in the patterns list is classpath:/configs/
So I assume that a change in spring 2.4 config loading broke this functionality.
Just compared that with the value of the propert source name from spring boot 2.3.7, there it is applicationConfig: [classpath:/configs/application.yaml] which prsed with replaces to classpath:/configs/application.yaml and there the pattern matches. So it is a bug introduced presumably by the 2.4.x config file handling
Comment From: spencergibb
Yeah, we moved to use ConfigDataEnvironmentPostProcessor rather than SpringApplication. Hopefully, in the near future, that cleanup method won't have to rely on names and patterns.
Comment From: spencergibb
It worked with boot 2.4.0, but not 2.4.1
Comment From: spencergibb
@dsyer I had to make a slight change to https://github.com/spring-cloud/spring-cloud-config/commit/8b48ed36c608dcd64c92b37673b359231997ccc0#diff-6e42942d6c70c5ad5dbf7bf796155f22e6dd24a953694cf090fcf087051add1eR234
here https://github.com/spring-cloud/spring-cloud-config/commit/a2087e05fb1e000cd34dac9ee006aa4cf059c429#diff-6e42942d6c70c5ad5dbf7bf796155f22e6dd24a953694cf090fcf087051add1eR236