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*
