Le 2017-06-04 12:21, Niclas Hedhman a écrit :
Well, I implemented the simple/hacky way now.
public interface MyConfig
{
Property<String> osName();
Property<String> home();
Property<String> path();
}
will now read "os.name" from System Properties and $HOME and
$PATH/%PATH%
of Environment variables.
Additionally, System properties takes precedence over environment
variables, so env variables can be overridden more easily.
This is to get defaults if the configuration could not be found in the
corresponding ES, correct?
So, the values gathered from system properties and environment variables
during that "first run" will then be persisted into the corresponding
ES. If the ES is persistent, then the next run of the application will
not use system properties nor environment variables but the values
fetched from the configuration ES, that is values captured from "the
environment" during the first run.
Of course, if using a non-persistent ES for configuration entities (e.g.
MemoryES), then "the environment" will be used on each run.
I didn't think this through but it could get surprising.
As a side note, system properties and environment variable are mutable.
So this new mechanism is in fact taking a copy of their values at some
point in time, application startup, or later service activation.
