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...
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?
> 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 ;)
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...
> 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*
