Hi Romain trying inline as well ;)
-----Original Message----- >>> 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 OK. > used is the issue + the fact you are bound to 1 configuration by app. I am open to that. I also originally proposed a variant to having additiona named configs, so special cases where we do not want mix up everything in the default config chain can be handled. But I only faced strict opposition, so I gave up on this... > 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. Why? Seems that Mark sees that also differently. Would be interesting to compare your opinions. Nevertheless if it really does not work, we have to find a workaround for that, because this kind of feature is simply crucial... >>> 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. My idea was that if we have two apps, isolated by configuration means, the same key can be configured in both apps differently, there is no interference... Let me know, if I got you wrong... >>> 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. -> if you want to define a SE API it should be complete (clear sentence from Oracle). This means you should be able to program against it, without any further deps. So there is no choice, you have to provide some kind of accessor. That people working a lot on EE find that unusual I completely understand - it felt the same when I was starting on the money JSR. -> if you can leverage existing runtime, you can still do that as part of an extension module, where you for example can use the provided container to manage parts of your solution. That is one of the reasons the ServiceContext is in place, where you can do such things. So it depends on the implementation how far contextuality is reused (or replicated). Depending on the concrete integration target one or the other strategy may be appropriate. I think we should discuss these things, when we are discussing the concrete integration. Because we must probably face both scenarios it is useless IMO to ignore contextuality completely by mean making the API so "inflexible" we cant support it.
