Trying to answer inline 2015-01-07 15:27 GMT+01:00 Tresch, Anatole <[email protected]>: > 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). >
never said "in advance", just the fact to know each app where it is used is the issue + the fact you are bound to 1 configuration by app. > 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." > I know this WeakHashMap and also know you can't rely on it for classloaders. >>> 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... > Dont get your idea can you detail it please? If it was not clear it is twice the same lib config in the same app. >>> 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...? > Issue is and why I started this thread - I don't believe in both solutions. Either we say the app is responsible of the configuration boot/stop and we don't care of contextuality - what I'd like see next sentence why - or we completely handle it but we have the mentionned issues which to be honest after having thought to it are enough to not use the product (would need as much code as solving it by yourselfin the 50% of cases I'm thinking about). Why I think we shouldn't handle contextuality is simply cause it is trivial to do so when you have an actual app: CDI -> @Produces, Spring -> <bean />, etc. Each app has its "contextual" solution so I wouldn't add another one which wouldn't be integrated. It is close to what JBatch does just providing a factory for the JobOperator and I think it is good for a v1.0. We'll integrate with CDi anyway (and spring I guess?) so we'll have the good default anyway for these containers. For plain SE mode you can't guess and you'll finish to a singleton, does it worth providing it? Looks like a poor solution to me.
