no more inline, starts to be too long ;) 1) not being able to create another Config instance: not sure how it would work and you just prevent most of IoC frameworks to use tamaya then IMO 2) Tamaya should manage its lifecycle: yes but no. You can't or you do what is implemented ATM and redo a container -> same as 1. However I join you saying tamaya needs to define a configuration lifecycle to let sources start/stop properly.
About the classloader - and hopefully to close this topic in *this* thread: yes it is not clean from a lib but that's what does a lot of containers and several libs using app lifecycle listeners to clean up it properly. I don't doubt it works, I just don't find it natural and hard to use in advanced apps. Giong further I think default should be open - you want to lock it for offshoring if I understood - so in your case you would implement the ConfigurationProvider to lock it but default would allow as many instances as needed. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-07 17:19 GMT+01:00 Tresch, Anatole <[email protected]>: > inline... ;) > > -----Original Message----- > From: Romain Manni-Bucau [mailto:[email protected]] > Sent: Mittwoch, 7. Januar 2015 16:37 > To: [email protected] > Subject: Re: Configuration.current() > > 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 ;). > -> OK got it, makes sense ;( > -> So we probably need a different approach, but there are options I am sure > we will figure out the best one. > >>>>> 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. > -> OK. I have talked recently with Mark et al about adding categories, which > could be added by an extension feature. These would perhaps help 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...? >>> >> >> 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...) > -> I did not wanted to say if something is wrong, I am just reasoning ;) > In many cases people do not explicitly decide how configuraition is added. > There is some architectural governance that has decided how your apps and > configs are configured. > Or you install your stuff on some cloud provider, where it is defined > similarly how you can provide configuration (depending on the features you > have or have paid for), so > configuration is a unified API to access it, and a defined way how you can > provide it (typically different per company/product in use). So most of the > people will not work with the Tamaya > SPI, they simply will add their configs to the locations they know and they > are fine. > > -> Given that defining everything on creation of a factory is not what - at > least here in the bank - is desired. We have thousand of offshore people, and > we definitely not want to given them > power to redefine the configuration mechanism per application. It would be a > nightmare. > >> -> 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. > > -> I think Tamaya should manage configuration and its lifecycle. > Configuration is a main concern that should not be dependent on other > frameworks. I would say it should be the other way round... nobody says that > it will be easy... > -> We should nevertheless have to think deeply how we can let it interact > /integrate in the different integration scenarios. > -> the classloader based approach works completely fine here in Credit > Suisse. The only difference is > that we do not use WeakHashMap, but have registered additional > ServiceContextListener and ear-levelled EJBs (with @Deconstruct) > to cleanup configs on shotdown/restart. So I would not say, it does not work, > I would say, let us discuss how > we can make it work ! >
