Spring-cloud-config: Command line argument does not override remote config

[jhaeyaert]

Hi,

I use these versions :

• Spring 5.0.3.RELEASE
• Spring Boot 2.0.0.RC1
• Spring Cloud Config 2.0.0.M5 (Finchley.M6)

I use the following configurations served by the remote config server :

application-dev1.yaml

server.port: 8080
my.option: 'foo'

application-dev2.yaml

another.option: 'bar'

My program own a bootstrap.yaml file containing :

spring.cloud.config.uri: http://config-server.internal.com

Then I run my program using the following arguments :

java -jar demo.jar --spring.profiles.active=dev1,dev2 --server.port=9999 

The spring cloud documentation http://cloud.spring.io/spring-cloud-static/Finchley.M6/single/spring-cloud.html#overriding-bootstrap-properties explains that command line arguments always take precedence over remote config.

The property sources that are added to you application by the bootstrap context are often "remote" (e.g. from a Config Server), and by default they cannot be overridden locally, except on the command line.

Unfortunately, the server.port value stay set to 8080 (defined in dev1.yaml) instead of 9999 (passed in argument).

Notice that when using only dev2 profile (no server.port is defined for this profile), the server.port argument is effectively taken in account.

Is there something I missed or there is a bug in the configuration load order ?

The ability to override some configurations with command-line arguments is very useful for quickly testing specific configurations without significant effort.

Thx for your time.

[spencergibb]

http://cloud.spring.io/spring-cloud-static/Edgware.SR2/single/spring-cloud.html#overriding-bootstrap-properties

[jhaeyaert]

Yes this is the documentation I pointed in my explanation and it says that property sources that are added to the application cannot be overridden locally, except on the command line.

The issue is precisely about the management of command line arguments that should overload the remote configuration, isn't it ?

[spencergibb]

Yup, but system properties work with that setting. So java -Dserver.port=9999 -jar my.jar.

[jhaeyaert]

I can confirm that it's not working for me using the system property -Dserver.port=9999 and spring cloud config enabled.
I also tested with another custom property (--my.test=foo) using both system property and command argument and the property is never overridden.

On the other hand this is working when spring cloud config is disabled and I point directly on local folder holding all the configurations (using --spring.config.additional-location=file:/)

I can prepare a reproductible case if necessary ?

Thx for your help.

[jhaeyaert]

I finally figured out the solution.
The documentation is not very clear cause it says that command line arguments always take precedence over remote configuration.

The property sources that are added to you application by the bootstrap context are often "remote" (e.g. from a Config Server), and by default they cannot be overridden locally, except on the command line.

This is not the case.
To achieve that, you have to activate the '''spring.cloud.config.override-system-properties=false''' configuration (the documentation only talk about System properties but it seems to be applicable to command line arguments too).

Here again it's not explicitly said that you have to put it inside one of the configuration files served by the config server and must match with activated profiles.

Ex : lets say you have the following files on the remote config server for your application.

• application.yml
• application-dev1.yml
• application-dev2.yml

Be care about where you put the '''spring.cloud.config.override-system-properties=false''' config and what profiles you activate. If you put it inside the application-dev2.yml, overriding configuration with the command line arguments will only work if you activate the dev2 profile (could be interesting if you want to protect some profiles but could be hard to maintain and lead to behaviours hard to understand).

You can close this issue (maybe open another to improve documentation ?)

Hope this little explication could help some people and preserve them some headaches.

[ryanjbaxter]

@jhaeyaert so if we remove "except on the command line" from the documentation would that make things clearer? Feel free to submit a PR to the docs to help clarify things.

[jhaeyaert]

Yes it could be a good start.
I will try to take some time to improve the docs.

[ryanjbaxter]

Fixed via a commit in Spring Cloud Commons https://github.com/spring-cloud/spring-cloud-commons/commit/bda67f235c764f53ce2596607dad35e1a5f9c01f

[SDhaniyaGen]

This issue is fixed in asciidoc but document is still showing old content :
http://cloud.spring.io/spring-cloud-static/Edgware.SR2/single/spring-cloud.html#overriding-bootstrap-properties

[spencergibb]

It's fixed in Finchley, not edgware

[SDhaniyaGen]

@spencergibb : Thanks, just realized I was referring to an old documentation. I know it's readers responsibility to check documentation version but it would be really helpful if page has a header that says refer to a newer version for updated docs. Just a suggestion and thanks for the good work.

[nagesh-salunke]

Thanks @jhaeyaert

[git-josip]

Here again it's not explicitly said that you have to put it inside one of the configuration files served > by the config server and must match with activated profiles.

Ex : lets say you have the following files on the remote config server for your application.

• application.yml
• application-dev1.yml
• application-dev2.yml

Be care about where you put the '''spring.cloud.config.override-system-properties=false''' config and what profiles you activate. If you put it inside the application-dev2.yml, overriding configuration with the command line arguments will only work if you activate the dev2 profile (could be interesting if you want to protect some profiles but could be hard to maintain and lead to behaviours hard to understand).

Thank you for this.
This solved my 3 days agony.
Documentation is unclear. whole time I was thinking I need to put these values inside config-server application.yaml, not inside served properties, as I thought this it config-server flag.
Thank you one more time @jhaeyaert