same ;) 2015-01-07 16:26 GMT+01:00 Tresch, Anatole <[email protected]>: > 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... >
I recall and now I think it was this contextual aspect which seems wrong - at least to me - more than the feature itself. >> 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... > if the value is loaded with the same classloader - we can't really control it from tamaya - then it can't be garbaged collected correctly. Said otherwise WeakHashMap doesn't work when there is a cycle betwee key/value even if it is indirect. The classloader being more or less linked to almost everything I guess you get it ;). You should be able to find apache jira issues on beanutils or geronimo/openejb IIRC - makes months/years now ;). >>>> 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... > This works but my case was for 2 part of 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. > > -> 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. Can you show me why mine is wrong - ie just a factory? If you manage to do so then all the stack is wrong I guess (bean validation, jpa, jbatch...) > -> 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. > My point is we dont need service context at all. Integration can be done based on a factory and the integration defines the scope + lifecycle which is surely cleaner that doing what we can lazily and relying on the only thing we can: the classloader. Side note: the classloader will not work as key in most of "big" EE containers and then you'll need to either do container integrations or just add find logic which can also just be wrong and leak between apps or fail. Last point: in OSGi there is no way it works. So basically only case it works well are flat classloader - ie wars or standalone. Not sure we can say it is a solution. factory solution - builder if you prefer I don't want to fight on it - doesnt handle it in tamaya core but in practise it is either what you want - lib case - or fine because you just integrate with your actual environment/container smoothly.
