polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Configuration structure
Date Sun, 04 Jun 2017 10:48:05 GMT
Yes, to everything;

It is fallback if properties file, json, xml or yaml files can't be found,
then it will do this, and yes, if the config es is persisting it will not
be using them next start.

And yes, both System properties and Environment variables are "copies" of
the System.getProperties() and System.getenv() respectively. SO, should be
no problem that those sources are mutable any more than properties files
are also mutable.


Cheers

On Sun, Jun 4, 2017 at 6:39 PM, Paul Merlin <paulmerlin@apache.org> wrote:

> 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.
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message