2015-01-07 22:38 GMT+01:00 Anatole Tresch <[email protected]>: > 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 >
Cause several logging frameworks are broken and some are not contextual once created and others are singleton even in EE. > 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 > ??? > > Thread.CurrentThread().getContextClassLoader() > > > > 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*
