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