Describe the bug I am new to Spring config server and was playing around with the setup , and stumbled upon this usecase where the priority of properties is like

  • if the config-client has local application.properties has the property polar.greeting=A, when I say local it would be bundled in src/main/resources.
  • If the remote config backed by aws s3 has the property application.properties where polar.greeting=B then when I do /actuator/env on my config client , where local property takes precedence over the remote config without me setting any explicit overrides either at the system property level or either at the application.yml in the config-client.
  • if I add remote config which application-profile.properties where polar.greeting=C, then for sure that take priority over the local one.

My question , is this behaviour expected?

config client https://github.com/kunalsumbly/catalog-service/tree/spring_config_server

config server https://github.com/kunalsumbly/config-service/tree/spring-cloud-config-server

Comment From: ryanjbaxter

Yes this is the correct behavior. Property sources coming from spring.config.import will be prioritized over anything in application.properties unless, as you observed, the "local" properties are profile specific.

However I system properties should always take higher precedence.

Comment From: kunalsumbly

Thanks for your reply @ryanjbaxter , I guess my understanding based on the spring config documentation was that

in terms of Priority order should be this.

  1. Remote profile-specific (highest)

  2. Remote default (should override local)

  3. Local properties (lowest)

Clearly this is not that case , when we are using spring.config.import , in this case , I see that order is

  1. Remote profile-specific (highest)

  2. Local properties (would override remote default )

  3. Remote default (lowest)