Romain the point is that you would do that yourself and provide it in e.g. a static field basically (that's what it boils down to - regardless how gloriously you wrap it in factory methods).
LieGrue, strub > On Thursday, 8 January 2015, 8:59, Romain Manni-Bucau <[email protected]> > wrote: > > Hmm, Anatole can you just rephrase it - not sure I get it as you think > it, in particular not sure what your "contextually" means here. > > For me ConfigurationProvider is just the impl of the factory/builder > and is contextual only in the boot phase - ie it uses TCCL to find the > impl. > > ServiceContext would be quite useless in my model but we would have > Configuration instance with a close() method. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > > 2015-01-08 3:11 GMT+01:00 Anatole Tresch <[email protected]>: >> Hi Romain >> >> let me say that way: it was my original design proposal to have a >> ConfigurationSpi that provides different Configuration instances >> contextually. >> So now we might have a ConfigurationProvider instead of ConfigurationSpi, >> but we might end up at the same idea: ConfigurationProvider implements >> contextuality, ServiceContext is just the registry of the instances... >> >> Anatole >> >> >> 2015-01-07 23:20 GMT+01:00 Romain Manni-Bucau > <[email protected]>: >> >>> so basically we have a ServiceContext<KEY> with get(KEY) and >>> release(KEY) - if so OWB has a complete working impl of this pattern? >>> >>> still find weird to have it in core and not in another module. EE list >>> speaks about having a kind of meta container - still an idea today - >>> where you can register "sub containers": >>> >>> Properties p = new Properties(); >>> p.put(ContainerFactory.JPA_CONTAINER, myJpaContainer); >>> p.put(ContainerFactory.BVAL_CONTAINER, myBValContainer); >>> //... >>> Container c = ContainerFactory.create(props); >>> >>> (sub)containers would be here just more or less providers of instances >>> (EntityManagerFactory for JPA, ValidatorFactory for BVal etc...) or >>> factories of these factories - not yet clear. In such a pattern and >>> even if I'm not very convinced of this I think the overall view is >>> good. The main container is still the one to choose how to affect >>> sub-containers. So if you want to plug the config you still have the >>> issue the config does what it wants or you need to not respect the >>> given container to switch the ServiceContext. >>> >>> IMO it is really the case for an app. >>> >>> Makes me think to 2 things: >>> 1) we miss ConfigurationProvider API - this is not the context which >>> is a runtime solution >>> 2) locking to a contextual solution is just a provider implementation > IMO >>> >>> wdyt? >>> >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-01-07 22:58 GMT+01:00 Anatole Tresch <[email protected]>: >>> > Hi Mark just did no know this abbreviation. I agree there are use > cases >>> > where the TCCL is not appropriate (or even null). So adding a > parameter >>> to >>> > set it might be a good idea... >>> > >>> > 2015-01-07 22:50 GMT+01:00 Mark Struberg > <[email protected]>: >>> > >>> >> > TCCL >>> >> > ??? >>> >> >>> >> >>> >> TCCL = ThreadContextClassLoader. >>> >> >>> >> >>> >> java.util.ServiceLoader uses it internally if you don't > explicitly >>> specify >>> >> a ClassLoader as parameter [1]. Thus we do also rely on the > TCCL >>> >> implicitly. But for e.g. @ApplicationScoped beans in shared > libs of >>> EARs we >>> >> might need to not use the TCCL but the application classloader > (== EAR >>> >> ClassLoader). >>> >> >>> >> LieGrue, >>> >> strub >>> >> >>> >> >>> >> >>> >> [1] >>> >> >>> > http://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html#load%28java.lang.Class,%20java.lang.ClassLoader%29 >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> > On Wednesday, 7 January 2015, 22:39, Anatole Tresch < >>> [email protected]> >>> >> wrote: >>> >> > > Hi Mark >>> >> > >>> >> > see inline ;) >>> >> > >>> >> > 2015-01-07 22:25 GMT+01:00 Mark Struberg > <[email protected]>: >>> >> > >>> >> >> well, option 1. already works really fine for CDI, > JSF, EL, JSP, all >>> >> >> Logging frameworks, etc. Why shouldn't it work > well for config >>> neither? >>> >> >> >>> >> > +1 >>> >> > >>> >> > The question is what more do we need? >>> >> >> >>> >> >> 1.a: Do we like to solely rely on the >>> >> >> >>> >> >> TCCL or do we like to add it as parameter to our > factory? >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > TCCL >>> >> > ??? >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > 1.2: Do we like to add a shutdown/release/cleanup method > to the >>> >> >> ServiceContext? >>> >> >> >>> >> > Hmm, since we also have according earlifecycle listeners > and similar >>> >> stuff >>> >> > in place, this makes sense. We should go all miles as > far as we can >>> go >>> >> to >>> >> > have a solution that does not impact system stability, so > IMO yes! >>> >> > >>> >> > >>> >> > >>> >> >> 2. would be fine if there wouldn't be the huge > problem with >>> propagating >>> >> >> each certain configuration. In practice you are back > to reading YOUR >>> >> config >>> >> >> and thus ending up having 47 different and parallel > 'realities'. It >>> >> > is >>> >> >> pretty much impossible to properly handle this in > big apps. If you >>> see >>> >> a >>> >> >> solution for this problem then please share your > ideas. >>> >> >> >>> >> > +1 >>> >> > >>> >> > On top of that managing the mechanisms centrally also > gives you the >>> >> ability >>> >> > to more easily built analysis tools that helps finding > bugs. This is >>> >> often >>> >> > much underestimated, but can be a real pain in big > systems, especially >>> >> when >>> >> > several dozens of teams all are providing some confif > parts... >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> >> >>> >> >> LieGrue, >>> >> >> strub >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> > On Wednesday, 7 January 2015, 21:35, Romain > Manni-Bucau < >>> >> >> [email protected]> wrote: >>> >> >> > > IMO we can't do 1 right cause it is > very dependent of the app >>> >> > and its >>> >> >> > stack. All our solution would be degraded mode > working more or >>> less >>> >> >> > well depending the app. >>> >> >> > >>> >> >> > 2 is nice cause aligned with almost all specs + > simple. >>> >> >> > >>> >> >> > >>> >> >> > Romain Manni-Bucau >>> >> >> > @rmannibucau >>> >> >> > http://www.tomitribe.com >>> >> >> > http://rmannibucau.wordpress.com >>> >> >> > https://github.com/rmannibucau >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > 2015-01-07 20:40 GMT+01:00 Mark Struberg > <[email protected]>: >>> >> >> >> Hi! >>> >> >> >> >>> >> >> >> We had great discussions and many valid > and important aspects >>> did >>> >> > came >>> >> >> up. >>> >> >> > Too bad they were spread all over the place in > various threads ;) >>> >> >> >> >>> >> >> >> So let's again pick up the discussion. >>> >> >> >> >>> >> >> >> We basically have 2 options. >>> >> >> >> >>> >> >> >> >>> >> >> >> 1.) a 'contextual' approach like > we currently have with >>> >> > our >>> >> >> > ServiceContext. There is exactly 1 > Configuration 'per >>> >> > application'. >>> >> >> >> >>> >> >> >> >>> >> >> >> 2.) a 'builder' approach. The > configuration system gets >>> >> > built by >>> >> >> > the user as often as the user likes and in > exactly the way the >>> user >>> >> >> likes. In >>> >> >> > that case andling the configuration for whole > application is _not_ >>> >> > part >>> >> >> of this >>> >> >> > project. Means any contextually would need to > be provided as >>> >> >> @ApplicationScoped >>> >> >> > producer bean or in other ways. >>> >> >> >> >>> >> >> >> Now it's your turn. Gimme all the pros > and cons ;) >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> LieGrue, >>> >> >> >> strub >>> >> >> > >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > *Anatole Tresch* >>> >> > Java Engineer & Architect, JSR Spec Lead >>> >> > Glärnischweg 10 >>> >> > CH - 8620 Wetzikon >>> >> > >>> >> > *Switzerland, Europe Zurich, GMT+1* >>> >> > *Twitter: @atsticks* >>> >> > *Blogs: **http://javaremarkables.blogspot.ch/ >>> >> > <http://javaremarkables.blogspot.ch/>* >>> >> > >>> >> > *Google: atsticksMobile +41-76 344 62 79* >>> >> > >>> >> >>> > >>> > >>> > >>> > -- >>> > *Anatole Tresch* >>> > Java Engineer & Architect, JSR Spec Lead >>> > Glärnischweg 10 >>> > CH - 8620 Wetzikon >>> > >>> > *Switzerland, Europe Zurich, GMT+1* >>> > *Twitter: @atsticks* >>> > *Blogs: **http://javaremarkables.blogspot.ch/ >>> > <http://javaremarkables.blogspot.ch/>* >>> > >>> > *Google: atsticksMobile +41-76 344 62 79* >>> >> >> >> >> -- >> *Anatole Tresch* >> Java Engineer & Architect, JSR Spec Lead >> Glärnischweg 10 >> CH - 8620 Wetzikon >> >> *Switzerland, Europe Zurich, GMT+1* >> *Twitter: @atsticks* >> *Blogs: **http://javaremarkables.blogspot.ch/ >> <http://javaremarkables.blogspot.ch/>* >> >> *Google: atsticksMobile +41-76 344 62 79* >
