As we talked a lot about simplicity, I am not sure, if an extra layer of ConfigurationFactory added so much benefit.
Other's thoughts? Werner On Wed, Jan 7, 2015 at 10:27 AM, Romain Manni-Bucau <[email protected]> wrote: > Hello guys, > > I'd like to discuss - again sorry - Configuration.current(). > > Here the reasons: > 1) this make tamaya context/environment aware - I know these words > means a lot so in more words I mean tamaya knows applications and when > you'll have read 2 it knows all parts of an app > 2) I saw quite commonly the need to start twice - or a bit more - the > same library/part of the app. With current design we need to translate > keys to the part we desire before using the configuration provided by > tamaya. This implies the app knows a way to find all needed keys which > is not always the case even if some patterns (prefixing) can work. It > is surely close to the original need of Anatole's map function in the > config but I wonder why we can't just have multiple config reading > different sources? > 3) if we go one step further and install tamaya in a container then > the app will call the container context impelmentation which will > delegate to the app if there is one cause the container doesnt know > such needs. > > I find it over complicated where finally all we need is to get a > Configuration reference. > > Here what I'd like: > > - SE > > Configuration config = ConfigurationFactory.newConfiguration(/* here > we could optionally put few config, either properties or internal > config file path. it would contain some manual declared sources and > provider and could replace addpropertySource for instance */). > > Default implementation would be the ServiceLoader one we have ATM but > the config passed to this factory could deactivate it and force the > config to use mentionned sources/providers. > > Then if the configuration needs the config as a singleton I think it > is simple enough to let the app do a singleton - in particular since > in most of cases it will be as simple as "@Singleton" (CDI, Spring, > Guice...) > > Last point: the configuration is built in its startup context which > means it resolves all it needs during its own bootstrap and not at > runtime later to avoid contextual side effects. > > - EE/Spring > > In this case it is acceptable to have an automatic configuration: > > @Inject Configuration config; > > this would be built during container boot and would just be a > singleton for the underlying container. > > This still allows apps to create "SE" style config if needed. > > > wdyt? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau >
