While it might be true that only k8s uses this way atm, still the
implementation is independent and simply file system based. As this
configuration prop is tied to the "secret" keyword as a replacement, I
think renaming it to "secretsdir" makes sense. We might have
"secretspropertyfile" as you say later on.
So if everybody prefers 'secretsdir', that's fine for me (I just think
the format is effectively k8s, we might as well name the property as
such)
I don't think that's maintainable and creates an unnecessary
configuration overhead.
Each time you introduce usage of an interpolation in a configuration
you need to adjust
this central configuration as well.
Well if it is a regex, you you can make sure you put the PID in the
"interpolated namespace", so not that much overhead (but yes, more it's
complicated and extra knowledge is required)
I assume you're concerned about performance? Without numbers proving
this decreades performance significantly, I wouldn't do any upfront
optimization, especially not if it creates configuration burden.
So yes, performance is one part (but most likely not a real problem),
the other aspect that for existing projects, there might be false
replacements made (I know finding $[] occurrences in existing config
values is not that likely, but if for some reason a project has those in
their configs it will cause them a major headache to find out what is
going on. One good way to mitigate that risk would be to to just leave a
reference $[env:key] in the value string unchanged for the case it
cannot be replaced (if I read [1] correctly it would currently result in
an empty string).
-Georg
[1]
https://github.com/apache/felix/blob/4c91624c6f1a47c5d6887446cb02fb906b110d40/configadmin-plugins/interpolation/src/main/java/org/apache/felix/configadmin/plugin/interpolation/InterpolationConfigurationPlugin.java#L145
