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
