2015-01-08 9:49 GMT+01:00 Mark Struberg <[email protected]>:
> Romain that makes no sense at all.
>

Hehe, do you know how many frameworks you just killed?

> As example for Logging: you also only have one factory, right?
> But still each log level and package could use it's own logging channels. The 
> ones could go to one file, the others to another, the third into the 
> database. Not a problem at all.
>

Not sure what you are saying here.

>
> But by having a single factory *YOU* have FULL control over your whole 
> application! It's NOT (only) the application which decides what to log and 
> where to. It's YOU as dev or ops guy or lady!
>

Sure and there is nothing against in what I say.

What I just want is to be abe to get different configuration instance
to keep it simple. I proposed some impl solution - I admit it was a
bit caricatural cause I wanted it to be understood - but if you like
CDI add a qualifier to providers/sources then you are done. Idea is
just to be able to get a Configuration with a subset of the
implementation of the SPI. Honestly I dont see how we can propose a
solution without it when I look back and see all kind of config
needing it.

>
> LieGrue,
> strub
>
>
>
>
>
>> On Thursday, 8 January 2015, 9:45, Romain Manni-Bucau 
>> <[email protected]> wrote:
>> > If I want N by app then I'll switch the ConfigurationContext to be
>> "prototype" - that's what I meant. Then for manual configs you
>> need to
>> configure the context to load only needed sources/filters so you'll
>> configure the context.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>>
>> 2015-01-08 9:39 GMT+01:00 Anatole Tresch <[email protected]>:
>>>  You dont configure the ConfigurationContext. You configure PropertySources,
>>>  propertySourceProviders and PropertyFilters. The configuration context is
>>>  nothing else than the loaded set of artifacts as were accessible during
>>>  config creation. The configuration impl manages these contexts. By default
>>>  there is 1 context per config. In a container I would expect one per app
>>>  minimally...
>>>  Oliver B. Fischer <[email protected]> schrieb am Do., 8. Jan.
>> 2015
>>>  um 08:59:
>>>
>>>>  ;-)
>>>>
>>>>  But still my initial question is open: How to do I get a Configuration
>>>>  if I have a configured ConfigurationContext?
>>>>
>>>>  Am 08.01.15 um 08:54 schrieb Romain Manni-Bucau:
>>>>  > :) that's what we all say and we left the original thread
>>>>  >
>>>>  >
>>>>  > Romain Manni-Bucau
>>>>  > @rmannibucau
>>>>  > http://www.tomitribe.com
>>>>  > http://rmannibucau.wordpress.com
>>>>  > https://github.com/rmannibucau
>>>>  >
>>>>  >
>>>>  > 2015-01-08 8:50 GMT+01:00 Oliver B. Fischer
>> <[email protected]>:
>>>>  >> Hi all,
>>>>  >>
>>>>  >> I agree with you Anatole. There is no standard way there to
>> place your
>>>>  >> configuration data. And we must not restrict the user in that
>> ways that
>>>>  we
>>>>  >> decide how to solve this problem.
>>>>  >>
>>>>  >>  From my point of view we must provide a framework which helps
>> the user
>>>>  to
>>>>  >> solve his problem. And not the other way around.
>>>>  >>
>>>>  >> Olive
>>>>  >>
>>>>  >> Am 07.01.15 um 11:14 schrieb Anatole Tresch:
>>>>  >>
>>>>  >> --
>>>>  >> N Oliver B. Fischer
>>>>  >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>>>  >> P +49 30 44793251
>>>>  >> M +49 178 7903538
>>>>  >> E [email protected]
>>>>  >> S oliver.b.fischer
>>>>  >> J [email protected]
>>>>  >> X http://xing.to/obf
>>>>  >>
>>>>
>>>>  --
>>>>  N Oliver B. Fischer
>>>>  A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>>>  P +49 30 44793251
>>>>  M +49 178 7903538
>>>>  E [email protected]
>>>>  S oliver.b.fischer
>>>>  J [email protected]
>>>>  X http://xing.to/obf
>>>>
>>>>
>>

Reply via email to