Was not thinking of an "extra" layer but more to remove ConfigurationContext then
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-07 11:38 GMT+01:00 Werner Keil <[email protected]>: > 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 >>
