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*
