without this change when adding the vault token `spring.cloud.config.server.vault.token` we have 2 config token providers on the classpath, the `VaultConfiguration#configTokenProvider` and the `EnvironmentRepositoryConfiguration$DefaultConfigTokenProvider` both with the same bean name. Starting from Boot 2.2 (AFAIR) that's unacceptable by default.
with this change we're changing the bean name so that we don't override the other bean name.
Always including application as default so that it can be shared accross all applications to be consistent with other repository implementations.
Sharing secrets to the application from default profile.
Updated the docs to reflect the changes
* Use a more robust filter when dealing with multiple keys. Fixes#1533
* Simplifying tests
* Creating a variable for the Pattern to avoid creating it everytime
Whenever the `spring.cloud.config.server.overrides` property was changed
(either through the env actuator endpoint or remote bootstrap
configuration) this was not reflected when retrieving the application's
configuration.
fixes gh-1295
The VaultEnvironmentRepository requires a token to be passed in a X-Config-Token header in an HttpServletRequest. This doesn't work well when config server is embedded in an application, as an HttpServletRequest is not available in that case.
These changes allows the Vault token to be provided in the HttpServletRequest header (the default behavior) or as a configuration property.
Without any preparations JGit defaults to read system / user / project
configuration from local file system. Users running tests locally
might see test failures due to their config diverging from the test
author config.
For me JGitEnvironmentRepositoryIntegrationTests.pullDirtyRepo() was
constantly failing, because JGit calculated a different hash for the
created commit than on the build server.
