Skip to content

Conversation

@tstenner
Copy link
Contributor

This allows clients to use properties from multiple vault sources that end in the same key, e.g. foo/bar/application and bar/baz/application.

Without this change, composite vault sources can't have the same key (application name, profile, …):

spring.cloud.config.server.composite:
  - type: vault
    # ...
    backend: vault/path/a
  - type: vault
    # ...
    backend: vault/path/a
{
 "name": "app-name",
  "profiles": [
    "default",
    "some-profile"
  ],
  "propertySources": [
   {
      "name": "vault:some-profile",
      "source": {
        "spring.datasource.username": "some-application"
        "hello": "from /vault/path/a/some-profile"
      }
    },
    {
      "name": "vault:some-profile",
      "source": {
        "hello": "from /vault/path/b/some-profile"
      }
    }
  ]
}

With this patch, the source name contains the full name (e.g. vault:path/b/some-profile) similar to the yaml sources (e.g. /root/path/app/application.yaml).

@ryanjbaxter
Copy link
Contributor

Can you add some tests that validate this fix?

@tstenner
Copy link
Contributor Author

The existing tests already cover it (that's why they are failing). I'll add another commit with the adjusted tests tomorrow.

@tstenner tstenner force-pushed the feature/backendpath branch from 94bb41e to 5edf3de Compare January 15, 2026 17:25

if (properties != null && !properties.isEmpty()) {
environment.add(new PropertySource("vault:" + key, properties));
var backendPath = "vault:" + (StringUtils.hasText(this.backend) ? this.backend + "/" : "")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit concerned about changing the name in a minor release because if someone is relying on the current schema this may break them. One thought I had would be to only change the name when there are multiple vault environment repositories configured so we fix the conflict, but leave the existing behavior in tact for every other case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely. In retrospect, submitting this PR a few months earlier would've solved this nicely.

Your suggestion is still a change for some users (i.e. those who have distinct keys in multiple vault sources), but there it is more likely they actually want the fixed behaviour.

As a migration path I could image adding a flag to include the full vault path (off by default) and change the default in the next major release. This would make the implementation simpler and fully backwards-compatible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a fullKeyPath property (defaulting to false) to the vault property source.
The previous behaviour as checked by the unit tests is unchanged and the new behaviour is checked by a new unit test.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats fine, but we need documentation on the property and why someone would use it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added in 9d48794

This allows clients to use properties from multiple vault sources that
end in the same key, e.g. foo/bar/application and bar/baz/application

Signed-off-by: Tristan Stenner <[email protected]>
@tstenner tstenner force-pushed the feature/backendpath branch from 5edf3de to 95bfdf5 Compare January 16, 2026 09:09
Signed-off-by: Tristan Stenner <[email protected]>
@tstenner tstenner force-pushed the feature/backendpath branch from 7910fbe to 9d48794 Compare January 16, 2026 15:20
@ryanjbaxter ryanjbaxter added this to the 5.0.1 milestone Jan 16, 2026
@ryanjbaxter ryanjbaxter merged commit e0d3660 into spring-cloud:main Jan 16, 2026
2 checks passed
@github-project-automation github-project-automation bot moved this to Done in 2025.0.2 Jan 16, 2026
@tstenner tstenner deleted the feature/backendpath branch January 17, 2026 10:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants