> 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.
Yes and no. Yes, because there is always only one effective version for your application. No, because you easily can use namespacing to address that. If you have multiple configurations in your application then you have to explicitly declare which one of them to use for EACH usage anyway. This is exactly the same effort which is needed if you simply declare the namespace for each usage. > 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. Each config has a different ordinal. So it makes perfect sense to pickup configs with the same file name from different jars. That way you can very easily add a jar to your application and just tweak it's configuration as you need 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 And who does this? And what scope would it have? @ApplicationScoped from CDI? Who is responsible in SE? What the current() does IS basically to define a scope! > I know this WeakHashMap and also know you can't rely on it for classloaders. Often it works but there are more tricky cases where it might become fragile. The problem is that sometimes different frameworks block each other. What about introducing a ServiceContext#release() method? That could be called by the container when undeploying the application. LieGrue, strub > On Wednesday, 7 January 2015, 15:39, Romain Manni-Bucau > <[email protected]> wrote: > >T rying 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. >
