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 > > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
