+1 2015-03-05 9:14 GMT+01:00 Romain Manni-Bucau <[email protected]>:
> Most of the time they just use another naming convention x.y.z vs X_Y_Z. > That is why having placeholders is not a bad solution since it handles all > cases. That said we can keep them out to start and see if placeholding is > important enough to import it in core. > Le 5 mars 2015 09:03, "Anatole Tresch" <[email protected]> a écrit : > > > Mixing up environment variable and system properties is in most cases not > > what you want. Could even be that the environment variables control, what > > config you see... > > So I think either we map them to a separate namespace, or we leave them > > out. With the resolver module, we have the possibility to resolve them > > using variables/placeholders. > > That is enough IMO ;) > > > > 2015-03-05 8:46 GMT+01:00 Oliver B. Fischer <[email protected]>: > > > > > 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 > > > > > > > > > > > > -- > > *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* > > > -- *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*
