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*
