Spring 3.5.1-3 - problem with importing properties from azure key vault

[GKukulski]

Hello, after change from version 3.5.0 to 3.5.3 i have problem to get properties from azure key-vault.
(testing with version 3.5.0 everything is fine)

Configuration of Azure Key vault:
SPRING_CLOUD_AZURE_KEYVAULT_SECRET_PROPERTY_SOURCES_0_CREDENTIAL_MANAGED_IDENTITY_ENABLED: true
SPRING_CLOUD_AZURE_KEYVAULT_SECRET_PROPERTY_SOURCES_0_ENDPOINT: https://valid_address.vault.azure.net/

I inject properties as @value.

After changing to 3.5.3 i can't see all variables in azure key vault.

[wilkinsona]

Thanks for the report. Given the use of environment variables targeting a list, this may be the same underlying problem as #46184.

[klopfdreh]

We heavily rely on this feature as well. Thanks for reporting @GKukulski

[wilkinsona]

@GKukulski @klopfdreh, please try the latest 3.5.4-SNAPSHOT build available from https://repo.spring.io/snapshot. This has hopefully been fixed by 6fe696b.

[klopfdreh]

He @wilkinsona - I am going to test the SNAPSHOT tomorrow - thanks a lot for all the work so far. 👍

[klopfdreh]

Hey @wilkinsona - I did some tests with few of our applications with 3.5.4-SNAPSHOT:

Note: Example 1 and Example 2 were broken in 3.5.3

Example 1:

1. The Kubernetes Container gets the environment variable CSV_PROCESSOR_REPLACE_0_INPUT_RESOURCE_URI:

2. We use configuration properties / lists:

3. As you can see the environment variable is transfered to the properties as it is used during the execution of the application:

Example 2:

1. The Kubernetes Container gets two env vars REST_CALLER_REST_CALLS_0_BASE_URL REST_CALLER_REST_CALLS_0_PATH:

2. The configuration properties has a list of rest calls:

3. The environment variables are transfered to the properties as the web request is made successfully:

To me this shows that the original behavior is back working as long as the IterableConfigurationPropertySource is also used for @Value annotations, but I guess so. 👍

[wilkinsona]

Thanks very much for testing, @klopfdreh. I'm going to close this one as a duplicate of #46184. @GKukulski if you have a chance to do some testing and that's not the case for you, please don't hesitate to let us know and we'll take another look.