Recommendations for new behavior of PropertySourcesPlaceholderConfigurer

[diegomarquezp]

Overview

Hello, I'm a maintainer of the Spring Framework on Google Cloud. We have recently been working on upgrading Spring Cloud to 2024.0 and Spring Boot to 3.4. So far, so good, except for our secretmanager integration.

The way we support bean injections for this integration is by specifying properties with the syntax ${sm://secret_id}, implying a request to the Secret Manager service.

Unfortunately, the colon : character is now being interpreted differently since spring-projects/spring-framework@00e05e6, with the resulting behavior being to interpret it as "property sm with fallback value of //secret_id". We have confirmed this in our code sample.

What have we tried so far

We have tried introducing our own static PropertySourcesPlaceholderConfigurer bean (see bean declaration, see source), set up to be configured before the default PlaceholderConfigurer autoconfiguration.

Interestingly, this works perfectly for @Value annotations such as @Value("${sm://my_secret}") (see example), but not for @Configuration classes that reference a properties file (in our case, simply application.properties). I confirmed that the following code has the default PropertySourcesPlaceholderConfigurer (this.placeholdersResolver in Binder.java) when debugging my application:

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/properties/bind/Binder.java

Lines 459 to 465 in 60e0de7

	private <T> Object bindProperty(Bindable<T> target, Context context, ConfigurationProperty property) {
	context.setConfigurationProperty(property);
	Object result = property.getValue();
	result = this.placeholdersResolver.resolvePlaceholders(result);
	result = context.getConverter().convert(result, target);
	return result;
	}

More context

• We use a custom config data location resolver. I suspect this may have to do with how the properties file decides to resolve its placeholder.

Alternatives considered

We are also thinking of additionally supporting the ${sm//my_secret} syntax (without the colon) as a workaround to escape the colon with a backslash, however we would like to avoid our users changing their code as much as possible.

Questions

My first question is: Why would the properties file be parsed with a different PlaceholderConfigurer than what's specified in the static bean? I believe this bean is meant to be a singleton, so I'm not sure where in the application it's decided to associate the default configurer to this configuration.

My second question is: Is there a preferred way to adapt to this new behavior?

[philwebb]

Thanks for the report, but I think someone from the Spring Framework team will be better placed to help. Unfortunately, I can't transfer issues but @bclozel or @snicoll can. Alternatively you can close this one and raise it again at https://github.com/spring-projects/spring-framework/issues

[diegomarquezp]

Thank you. I have closed this one and transferred it to spring-projects/spring-framework#34124