Variable replacement

[Emily-Jiang]

The issue is from Jeremie:
my.property.version.major=1

my.property.version.minor=0
my.property.version=${my.property.version.major}.{my.property.version.minor}
my.combined.property=Version ${my.property.version}

my.combined.property.withdefault=Version ${my.undefined.property:1.0}

This is very effective for example the file structure of a service. The root directory configuration is the domain of the installation whereas the subdirectory is the domain of application.

This has an impact on the implementation because all properties must be known before solving them. In addition, all properties dependent on a mutable property become mutable as well.

[struberg]

This already has been proposed in July last year
https://github.com/struberg/javaConfig/blob/configValue/api/src/main/java/javx/config/ConfigValue.java#L55

Note that we cannot ALWAYS evaluate those variables because it's certainly valid that they might be part of the payload a user wants to resolve natively. So there must be a switch to enable or disable this.

[jerr]

Mark, you're absolutely right, in most cases that I've met, I also had properties with variables that were not to be computed.

But we can have two approaches for this:

• The first one, we can manage this on the API user side. As the code you specify, it is the user who specifies the management or how to calculate the property.

• The second, the management is transparent to the API user. You can restructure your properties hierarchy without changing a single line of code. This approach is perhaps also to be considered. It makes the properties management more flexible concerning the code.

Some examples that may be appropriate for the second approach:

my.propery.rootdirectory = /opt/myservice/data
my.propery.productdirectory = ${my.propery.rootdirectory}/${my.property.product.category:products}
my.property.product.templatefilename = ${product.id}-${product.name}.pdf
my.property.product.file = ${my.propery.productdirectory}/${my.property.product.templatefilename}

The result for the property my.property.product.file is "/opt/myservice/data/products/${product.id}-${product.name}.pdf"
With the default value of my.propery.productdirectory and undefined properties of my.property.product.file we can manage that.

Sometimes you want to clean up your configuration files without affect the code. This situation has happened to me in several projects.

What do you think about this?

[sgalles]

Hello,
Would this also work for replacement in the default values ?
In this case, I think this would automatically also allow this : #339
because you could simply define your alias as a second property and just set the default value equal to the initial property

@ConfigProperty(name = "my.foo")
...
@ConfigProperty(name = "my.fooalias", defaultValue = "${my.foo}")

[Emily-Jiang]

@sgalles good suggestion.
One thing I would like to add is that we should just do one-level variable replacement not doing nested replacement in the first release.
${foo.${bar}} => will search for foo.${bar} even though bar is a valid variable.

[Emily-Jiang]

Use case:
As a developer, I would like my config value to refer to other config names such as ${foo.${bar}}