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*
