Open philwebb opened 2 years ago
Any updates on this issue?
It will be nice to get a fix for this given how different legacy and config data api processing is and moving forward with spring boot upgrades will be easier if this is fixed.
I think the problem originates from the design of the Config Data mechanism. There are two relevant phases:
ConfigDataResource
. ConfigDataLocationResolverContext
exposes access to the Properties Binder
to let Config Data components inspect configuration properties.ConfigDataResource
. Each resource is loaded.Once all resources are loaded, PropertySources
are added to Spring's Environment
and additional (contributed) configuration properties can be accessed.
In your arrangement, Consul required properties that are contributed by Vault, however, at the time when collecting the config for the Consul integration, neither Vault was accessed nor are any properties visible from Vault's ConfigData contribution.
@philwebb would it be possible to refine Spring Boot's loading mechanism to resolve a Config Data location first, load its ConfigData and then proceed with the next Config Data location?
@mp911de I think so, but it's likely to be risky so I'd rather not do it in the existing releases. I've opened https://github.com/spring-projects/spring-boot/issues/28849
Please see https://github.com/spring-projects/spring-boot/issues/25705 for details.
Opening here as I'm not sure what changes (if any) are needed in Spring Boot to support this request. Perhaps there's some deeper integration between
spring-cloud-vault
andspring-cloud-consul
needed?