more or less as given previously it is almost never true - do you still wrap even SE softs in plain manual java? You almost always have a light "container" - word is surely not the best but something managing your lifecycle.
This pattern brings the integration outside the core. It is a drawback but a big advantage. A drawback cause you let the user doing it - but often it is 3 lines. An advantage cause we don't conflict with the app, we don't introduce any leak etc..and finally with the release/close method we need anyway the app will manage the lifecycle whatever we propose so finally we have an abstraction which doesn't help IMO. Also and I think I mentionned it being fully contextual prevents the app to control the visibility of the conf so if you think some teams need best practise you'll quickly see it will be used everywhere and that's not what you want IMO - at least I don't ;). Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-08 9:02 GMT+01:00 Mark Struberg <[email protected]>: > 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* >>
