Allow values from configtree to resolve nested placeholders

[ChristianAnke]

It would be helpful if for properties which come from a configtree the placeholders will be replaced. Currently this seems to be blocked by the ConfigTreePropertySource producing non String results when getting the value of a property.

[wilkinsona]

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.

[ChristianAnke]

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?

[philwebb]

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.

[wilkinsona]

We're going to try the CharSequence check.

[andrej-urvantsev]

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?

[philwebb]

Not as yet I'm afraid @LazyStone

[andrej-urvantsev]

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.