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?


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?

1.2: Do we like to add a shutdown/release/cleanup method to the ServiceContext? 



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.


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
> 

Reply via email to