Hi,
on the environment variables. There is already a property source for
environment variables. I simply would treat them as normal properties.
The same for system properties. We should only consider a possibility to
disable the access to environment variables. I did it already for the
builder.
But at the end we can not control which properties are read as users can
simply write their own PropertySource or PropertyProvider. Therefor I
wouldn't care so much about it. Or did I miss something?
Best,
Oliver
Am 03.03.15 um 13:13 schrieb Anatole Tresch:
Hi Oliver/Romain
I never meant about reading things in order (ordering is done based on
ordinals), but I agree with the ordinal we are flexible enough.
We can still agg stage or test support as extension, so I will not stick to
it ;)
Summarizing:
- Read environment variable: question where and how to map it...?
- Read META-INF/configuration.properties available
- Read system properties
So we have to discuss the proposal from Romain about adding dynamic
expressions for environment properties...
I am strictly against it, since
- it is not a core feature
- we can omit environment properties at all in Core
- Core should be minimalistic (no dependencies that are not ultimately
needed, so also no strsubstictutor of [lang3] ). So if we cannot agree to
add env properties somehow to a mapped namespace in the config tree (which
is common use), I would not include environment properties at all with
core. The resolver module brings basically exact the described
functionality, so if someone needs it, he can just use this module...
WDYT?
2015-03-03 12:38 GMT+01:00 Oliver B. Fischer <[email protected]>:
Hi Anatole,
first, let us exclude the discussion on stages. In generell I think this a
usefull and needed feature.
But why do we need to read the properties in a specific order? Futhermore
does it help if there a many differente jars. How do we handle this?
And just as a question? Why is the ordinal (priority) not enough?
Just questions.
Bye,
Oliver
Am 03.03.15 um 09:19 schrieb Anatole Tresch:
Dear all
I am currently updating the site and documentation, to approach further a
first release. I am not happy with the current default config setup in
Core. I would propose to provide the following setup (PropertySources and
providers), from weakest to strongest:
1. Read *environment properties* and add them prefixed with "env."
2. Read all files found in *META-INF/cfg/defaults.properties*
3. Read all files found in* META-INF/cfg/${stage}/defaults.properties*
4. Read all files found in *META-INF/cfg/config.properties*
5. Read all files found in *META-INF/cfg/${stage}/config.properties*
6. Read current *system properties*.
Given that we have simple and enough powerful variant, which can be
implemented very easily.
If no stage is set, the stage specific parts are not read. The stage can
be
set by applying a
environment property or (overriding) system property, named
*tamaya.stage*
I expect the Core and API module together not exceed 100k in Java 8 ;)
WDYT?
Anatole
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E [email protected]
S oliver.b.fischer
J [email protected]
X http://xing.to/obf
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E [email protected]
S oliver.b.fischer
J [email protected]
X http://xing.to/obf
