Hi Romain/all >> 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
Tamaya does not need to know all applications in advance. It must be able to detect it is running in a certain application (=context) and then being able to provide the correct config for it. With classloaders you have some kind of isolation Tamaya must adhere similarly. E.g. when you added a PropertySource as part of your app1, which is not visible in app2, the corresponding config/property source should not be available in app2 similarly. So you WILL have different Configuration instances in such cases, there is no way out of that. You do not necessarily must have a Configuration created from scratch for each Classloader. You can e.g. depend on an environment service (which evaluates an environment config from the current context classloader). Depending on the env config visible it provides the according contextID, which defines the isolation. You can then combine this contextID with each classloader in place as Mark suggested, so future evaluation is fast. This allow you as well to load a system/domain config once on startup and attach id with the system classloader and add further configurations along your isolation needs transparently ( all said is implementation logic within the Configuration implementation). BTW this mechanism DOES NOT LEAK, it does exactly what it should map classloaders to config/environment keys and forget all if the classloaders are thrown away, see Javadoc of WeakHashMap: "Hash table based implementation of the Map interface, with weak keys. An entry in a WeakHashMap will automatically be removed when its key is no longer in ordinary use." >> 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? This should be solved by isolation? I don’t see a need for key mapping here... >> 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. >> ... >> 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 */). That looks like my ConfigurationBuilder. Of course you could do something like that, e.g. as part of an extension. But I don’t think it is the way configuration should be handled in an enterprise context. Or in other words, instead of writing this code, you can register an according property source and you are done...?
