> 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* >
