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*
