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*
