Describe the bug According to documentation we should be able to override remote properties with local property sources, but it doesn't work.
Sample Here's a demo project.
Comment From: SquirrelGrip
You missed the spring.cloud.config.overrideSystemProperties=false from the config/application.properties
However that all said, I ran the sample application and even with overrideSystemProperties it still does not override the properties.
I went back in time to use previous spring-boot (2.5.8) and spring-cloud (2020.0.5) and it didn't work at all.
Comment From: kis024
In my understanding of this statement: "and spring.cloud.config.overrideSystemProperties=false if only System properties and env vars should override the remote settings, but not the local config files" should make it even more restrictive, since only sys props and env vars values will override the remote values, those from local application.config will be ignored.
In my example I'm looking for using values from local application.config/yml
Comment From: SquirrelGrip
You are correct...I am facing the same issue and your example is a great starting point for me.
I have created a heap of tests, but I am also reading the documentation without having too many distractions around (working from home with new neighbours and their new baby screams all the time...sleeping now). It looks that the features that you are mentioning are from the previous version and that as of 3.1.0, these features no longer appear in the latest documentation.
Initial finding is that PropertySourceBootstrapProperties has its properties set, however the properties are never read during boot. The only place that they are referenced is in PropertySourceBootstrapConfiguration, however this class is never initialised when I believe it should be. I don't know how to force it to be initialised, but it seems that the class is completely ignored.
I will update my finding as I discover the changes, but as it to say the new way is not documented well and part reading code and deciphering the documentation, I believe that the changes are problematic.
Comment From: SquirrelGrip
Short Story... Add the following to the client application.properties... spring.config.use-legacy-processing=true
Longer Story... As you can probably gather from the name, this is the legacy way of handling overrides and there is a newer way to achieve local override. However the new way, since spring boot 2.4, is a little more complicated and I am yet to get it working. The documentation is not clear and there really needs a better example of how to achieve the same. Also I have tested this with profiles overriding and the results become less understandable and I am still trying to figure it out.
In the meantime, adding spring.config.use-legacy-processing=false should suffice, however it might be beneficial for the author of the latest changes to make it easier for a newbie to get their head around local overrides in the new system. There seems to be some inherent domain knowledge that needs sharing.
From my searching I found a number of examples just like the one @kis024 was using and they are giving a lot of false hope when using 3.1.0. It would be great if someone could give some insight into the inner working and how to implement local overrides so that we can do local development.
Comment From: christian-german
Since SB 2.4, it is no longer possible to override external properties sources
Add the following to the client application.properties... spring.config.use-legacy-processing=true
This works with 2.7 but will be removed with 3.0.0 (Next november). I've just checked against the 3.0.0-SNAPSHOT, indeed, it doesn't work anymore.
The Spring-Cloud documentation raises the spring.cloud.config.server.overrides property. But this is valid for global configuration. e.g. for all applications. Server's main application.properties => spring.cloud.config.server.overrides.hello=Hello! Client's application.properties => hello=Hi!
I can't see a way to override a property from a specific app configuration (client1.properties), like it used to be prior to SB 2.4.
Comment From: ryanjbaxter
I believe the way you order things in spring.config.import will specify the priority order (the last one will win).
Comment From: spring-cloud-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: kis024
@ryanjbaxter what can be ordered here? https://github.com/kis024/Spring-cloud-config-bug/blob/master/src/main/resources/application.properties Please check the demo project linked in the first comment.
Comment From: ryanjbaxter
Have you tried this with Spring Cloud 2021.0.5 or 2022.0.1?
Comment From: kis024
spring-boot-starter-parent => 2.7.9 spring-cloud-dependencies => 2021.0.6 Same behaviour.
spring-boot-starter-parent => 3.0.4 spring-cloud-dependencies => 2022.0.1 Same behaviour.
update demo project to latest versions.
Comment From: ryanjbaxter
For local overrides to work properly you need to use Bootstrap configuration. If you add spring-cloud-starter-bootstrap to the classpath and then set spring.cloud.config.uri in bootstrap.properties and remove the spring.config.import property it should work as expected.
Comment From: kis024
This is an issue report, not a Stack Overflow question.
Comment From: ryanjbaxter
I understand, but this is a limitation that is out of our control because Spring Boot is loading the properties when using spring.config.import. This is why I am suggesting an alternate approach
Comment From: kis024
I'm expecting to see a resolution if this is an accepted issue or just the documentation is obsolete and needs adjustments according to current behaviour.
Comment From: ryanjbaxter
The other option is to use a profile specific properties file in the client. If you create application-overrides.properties and activate the overrides profile properties in that file will override what comes from the server.
Can you point to where in the docs it still references client side overrides?
Comment From: kis024
Comment From: ryanjbaxter
That documentation is very old its from Version: Brixton.BUILD-SNAPSHOT.
I don't see any references to this in our current docs https://docs.spring.io/spring-cloud/docs/current/reference/html/ https://docs.spring.io/spring-cloud/docs/2021.0.5/reference/html/
Comment From: kis024
Comment From: ryanjbaxter
Those are environment variable and system properties not application properties
Comment From: kis024
Old reference needs to be removed and issue closed.
Comment From: ryanjbaxter
Old reference needs to be removed
Can you be specific about which old references need to be removed?
Comment From: christian-german
Another option is to user placeholders in the server's application.properties: https://www.baeldung.com/spring-cloud-config-remote-properties-override#overriding-the-properties-on-the-clients-side
As I was writing this article, I figured out myself how things seem to work. The documentation mentioning the different priorities of the properties between profiles, local, user's home, in-jar, remote in spring-boot/spring-cloud isn't quite clear.
Besides, prior to SB-2.4 or by using the legacy configuration in SB<2.7 (removed in 3.x), it was possible to override server's properties on the client just by enabling spring.cloud.config.overrideNone.
This feature is gone since 3.x and we only have profiles or placeholders left to do so, which is not ideal in my opinion.
Hope this adds some values to this issue.
Comment From: ryanjbaxter
I am happy to add some documentation around overriding properties in the local client app.
@christian-german I do not think you need to add spring.config.use-legacy-processing=true when using boot 2.7.x with spring-cloud-starter-bootstrap. Also as a side not using spring-cloud-starter-bootstrap with Boot 3.0.x will also allow this to continue to work.
Comment From: ryanjbaxter
Here are some updates to the documentation, feedback welcome https://github.com/spring-cloud/spring-cloud-config/pull/2242
Comment From: kis024
I was thinking of dropping the misleading page https://cloud.spring.io/spring-cloud-static/spring-cloud.html in favor of https://docs.spring.io/spring-cloud/docs/current/reference/html/
Comment From: ryanjbaxter
All of our documentation links point to https://docs.spring.io/spring-cloud/docs/current/reference/html/