let's continue inline ;)
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-03-03 11:39 GMT+01:00 Anatole Tresch <[email protected]>: > So lets start the discussion inline ;) > > 2015-03-03 9:44 GMT+01:00 Romain Manni-Bucau <[email protected]>: > > > Hmm > > > > did I miss the discussion where stage was included? Thought we said we > dont > > use it at all. > > > > There was no such discussion ;). But I would say many users expect it to > be present and the mechanism is still simple and > flexible and > it > can be used as well as for configuring different tests with different > config... at least that was my idea... > but no unified stage config so for 1 app you have easily 5 stages :s. Wouldnt add another one > > I'm -1 for "env." prefix (but +1 for the feature), maybe ${env['xxx']} > > a bit like in jbatch for system properties. Issue is env.x is common in > > prod - at least saw it in 2 companies - for other things. > > > > > Unfortunately resolvers are in an extension module. For me it is -1 to add > resolver like syntax here... > Maybe we can choose another prefix or entry key syntax? Ideas? > > > let's import strsubstictutor of [lang3] and use it, no? > > > Finally why config and defaults? Since we can merge config files we > should > > be able to not need 2 places. > > > > Because typically when I configure something I have exactly these 2 levels > at least: > *defaults* coming along with my code. But you are right with the dynamic > ordinal > concepts we are fine, so reading META-INF/cfg/config.properties is enough > ;) > > yes but that's how *you* structure your config but no reason to propagate it. > > So I'd say: > > > > 1. Read *environment properties* and support syntax ${env['x']} > > > > -1 for the resolver styled syntax, +1 for reading > > > > 2. Read all files found in *META-INF/tamaya/configuration.properties* > > > > what is the benefit of using tamaya in the path? Different implementations > would require > migrating the code... > > fair enough, let's use configuration (no shortcuts please): META-INF/configuration.properties > > > > 3. Read current *system properties*. > > > > Side note: not sexy but super useful in prod: do we handle few container > > specific system properties - understand no container API - to use their > > default config locations like ${catalina.base}/conf, ${karaf.base}/etc > > etc..? Should be one trivial class allowing to put config outside the app > > pretty easily and OOTB (why I'd put it in core and not in an extension > > nobody would import in practise). wdyt? > > > > I was also thinking on adding a PropertySource for external locations. > Nevertheless > from a format aspect only properties are supported and we need a mechanism > to > tell core where the external config directory is located... > > > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > > <http://www.tomitribe.com> > > > > 2015-03-03 9:19 GMT+01:00 Anatole Tresch <[email protected]>: > > > > > 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 > > > > > > > > > -- > > > *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* >
