See https://github.com/spring-cloud/spring-cloud-vault/issues/607#issuecomment-977666573 for more background.
Currently ConfigDataLocationResolverContext.getBinder() is documented as "Provides access to a binder that can be used to obtain previously contributed values", but the actual binder here only provides access to parent contributions. This is because ConfigDataEnvironmentContributors.withProcessedImports processes all imports in a single hit, rather than doing them one at a time and creating a new ConfigDataLoaderContext.
If we change this logic then a ConfigDataLocationResolver should be able to make use of previously contributed data.
Comment From: krisiye
@philwebb - Happy to test any snapshots or milestone releases. Feel free to send them my way. Thanks!
Comment From: krisiye
@philwebb - Any ETA on when this will be available? thanks!
Comment From: philwebb
@krisiye Sorry, no ETA. It's in the 3.x milestone which means we think it makes sense for a 3.x release, but we don't know when we'll get to it.
Comment From: krisiye
@philwebb @mp911de - Now that we have 3.0.0 available and legacy bootstrap processing no longer supported this is now a blocker for upgrading to 3.0.0. I have updated my sample code to help reproduce this issue for the 3.0.0 branch:
https://github.com/krisiye/sb-issue-25705/tree/3.0.0
Would be great to get your feedback on this issue and the suggested path forward!
Comment From: krisiye
@philwebb @mp911de - QUICK UPDATE - Tested a possible solution/workaround today by splitting the vault and consul configuration onto different profiles and then running spring boot with multiple profiles and thus forcing the loading sequence to resolve the vault profile ahead of the consul profile. That appears to work fine with the configDataLoaders as properties from the previously contributed resolution context are made available to the subsequent context through the env property sources. It's just that loader candidates for import within the same profile are resolved without any previous context (such as vault and consul on the same profile).
Another possible workaround would be to introduce alternative forms of authentication for spring cloud consul (such as Kubernetes auth - https://github.com/spring-cloud/spring-cloud-consul/issues/742) and use that instead of a vault consul backend for the consul ACL Token. In this approach, we eliminate contributor dependencies between vault and consul. However, it may still be useful for some similar use cases to have some means to access the previously contributed properties.
Between the two I feel the multiple profile approach seems to be a bit more generic and could be used under many different scenarios to resolve dependencies. Does this seem like a reasonable approach? If it is then maybe this just needs to be well-documented.
Would be great to get your thoughts. Thanks!
Comment From: krisiye
@philwebb @mp911de - Another workaround would be to use the environment contributors (such as -Dspring.config.import=consul:,vault:) instead of configuring these through profiles which seems to be the cleanest of all the options so far. I posted a workaround branch to demonstrate this - https://github.com/krisiye/sb-issue-25705/tree/3.0.0-workaround