Improve 'spring.config.import' support to allow later imports to use data from earlier ones

[lorenzbaier]

I have created a scenario where I need a password property loaded from configtree: to use for the config server client, which is secured.

I noticed when the configserver: ConfigDataLoader is not marked optional it will fail because the password is not resolved yet in org.springframework.boot.context.config.ConfigDataEnvironment#processInitial but only later in org.springframework.boot.context.config.ConfigDataEnvironment#processWithProfiles

see https://github.com/lorenzbaier/spring-config-server-client-test

I think that the properties should be added to the context as soon as they are available at org.springframework.boot.context.config.ConfigDataImporter#load

[philwebb]

This is a little counter intuitive, but is actually an intentional design decision. We don't want to apply the properties to the Environment until they have all been loaded.

Having said that, the configserver: import can access already loaded properties as they are available from the Binder provided to the ConfigServerConfigDataLocationResolver. The problem is that the current algorithm doesn't deal very well with multi-line imports.

I think we can improve things, but this is quite a complex area of the codebase and we might not be able to do much until Spring Boot 4.0 has been released.

In the meantime, you can workaround the problem by changing your application.yml to the following:

spring:
  application:
    name: demo-secrets-config-client
  config:
    import:
     - "configserver:"
---
spring:
  application:
    name: demo-secrets-config-client
  config:
    import:
     - "optional:configtree:./secret-config-root/"
  cloud:
    config:
      uri: http://localhost:8888
      password: # ./secret-config-root/spring/cloud/config/password

server:
  port: 9333

This will work because the lower document is fully loaded before the upper one. This gives the ConfigServerConfigDataLocationResolver a chance to read the configtree import.

[lorenzbaier]

Ok thanks for the quick reply, I will try the workaround.

Is there any good documentation which covers this? because I could not find any but I think it is a common use case to load some secret from e.g. "configtree" which will be used in a client like the config server

[philwebb]

The documentation isn't great in this area, but I don't think the problem has been raised before. I'd keep the workaround out of the documentation since it looks a little odd and I'd rather fix the underlying problem.