Thanks for the suggestion.

This is a little bit similar to #29642. A notable difference here, however, is that org.springframework.boot.env.ConfigTreePropertySource.Value is part of the property source implementation and, unlike the String[] in #29642, something that cannot be controlled. It feels like placeholder replacement should be possible, but it also doesn't feel right for PropertySourcesPlaceholdersResolver to know about org.springframework.boot.env.ConfigTreePropertySource.Value.

Thanks for the answer!

Sounds legit to me. Surely it is not easy to to simply support this for all the various property source providers. Somehow it has to be unified how replacements can be performed with the different providers.

I see minimum two ways to solve this:
A: It is possible to convert a value to a string (by asking the property provider) and handle then the nested placeholders
B: let the provider itself perform the nested replacement
C: ???

what do you think?

We might be able to change PropertySourcesPlaceholdersResolver to check for a CharSequence rather than a String since ConfigTreePropertySource.Value implements CharSequence. There is a risk a configtree file might be binary and we accidentally change the contents.

We're going to try the CharSequence check.

I tried to use env variables in configtree in SB 3.2.5 and it does not seem to work unfortunately.

Is there any progress at the moment?

Not as yet I'm afraid @lazystone

Ok, i understand the struggle here(we don't want to accidentally replace something in binary files), but I also realized that my problem was wrong from the beginning, so I'll describe it here for others.

Initially we used configmaps in k8s environments to provide configuration overrides for SB. And standard way to pass secrets to it was to read them from k8s secrets, put them in environment variables and SB would resolve them later.

Then, with introduction of configtree in SB we started to use it. And we did exactly the same thing as before - tried to use placeholders for secrets. One thing that we were missing I think - the whole purpose of configtree approach.

Using configtree we could mount secrets as we mount configmaps in k8s pod and use them directly as configuration overrides.

So, whoever faces this problem - have another look on your use case. Maybe you don't need this feature that much.

We're going to try the CharSequence check.

See #40862

Superseded by #40862.

Prompted by a review of #40862, I've realised that supporting this consistently isn't going to be straightforward. For example, LoggingSystemProperties uses PropertySourcesPropertyResolver so it would not benefit from a change made to the Boot-specific ConfigurationPropertySourcesPropertyResolver as #40862 proposes. There are also other classes that make use of PropertySourcesPropertyResolver outside of Boot to consider, such as Framework's PropertySourcesPlaceholderConfigurer.

It looks like a change in Framework may be a better option for fixing this consistently. spring-projects/spring-framework#32876 proposed a step in that direction, but it was declined. We'll discuss this with the Framework team and consider our options.

With thanks to @quaff and @snicoll, this has now been addressed in Framework. The enhancement will be available in Spring Boot 3.4.0-M2 as part of an upgrade to Framework 6.2.0-M7.