spring.config.import configuration clashes with spring.cloud.config.enabled

Observed behaviour

A spring.config.import config property is set to optional:configserver:http://myconfigserver:5656 in a main configuration file application.properties. In the application-dev.properties config file, the property spring.cloud.config.enabled is set to false, since we don’t require any property to be loaded from the remote config server on the dev profile. However, the observed behavior is that ConfigServerConfigDataLoader implementation doesn’t take into account that setting and is going to try to pull that configuration from the remote server. If the connection fails, it will check for the fail-fast and isOptional flags and make a decision based on that outcome.

Intended behavior

If the spring.cloud.config.enabled property is set to false, ConfigServerConfigDataLoader should not even try to connect to the remote server and return as soon as possible.

[roookeee]

Leaving my stackoverflow answer here in case someone stumbles into this issue via google: https://stackoverflow.com/questions/68702479/disable-config-service-client-activated-with-spring-config-import-in-springboott/69739888#69739888

There are workarounds but the situation of spring.config.import not being overridable, Spring Cloud Config requiring at least one spring.config.import to start with configserver: when it’s enabled and Splring Cloud Config removing it’s PropertySourceLoader for configserver: prefixed spring.config.import entries when disabled makes this very cumbersome.

I for one would wish that Spring Cloud Config would still register its PropertySourceLoader when disabled and just make it a noop. This way no fancy shenanigans (like linked above) are needed - especially when these fancy workarounds break apart because Spring Cloud Configs check for “at least one spring.cloud.config entry must start with configserver:” is not resolving variable placeholders when doing this check:

some.workaround = configserver:localhost:1337
spring.config.import = ${some.workaround}

This is not working because of the aformentioned missing variable resolution. This issue is creating a lot of headaches for our production environment at the moment.

[mplain]

Just spent two days trying to figure out why the dockerfile command line argument does not override spring.config.import specified in application.properties.

spencergibb
all spring.config.import entries are evaluated. They do not behave like normal properties that can be overridden. 

this migration has been very painful =_=