Show us an example. When I came along manual config composition it always 
caused a decent amount of pain.

We really need concrete examples about how this should work.


LieGrue,
strub





> On Sunday, 28 December 2014, 12:18, Romain Manni-Bucau 
> <[email protected]> wrote:
> > I think it is either not important or so imoortant that it should be
> central.
> 
> I mean if it is not important we use Configuration.current(). If it is
> important then we need to get rid of this contextual config and only handle
> a configuration reference. I guess that what any app would do without any
> framework.
> 
> It also open the door to have multiple configs by app which is nice for
> aggregated apps.
> 
> Le 28 déc. 2014 12:11, "Mark Struberg" <[email protected]> a 
> écrit :
> 
>>  To be honest I have no clear idea about it yet.
>> 
>>  In our application it could have been
>> 
>>  * 'database' (containing credentials, refetch settings, etc) vs
>>  *  'documentarchive' vs
>>  * 'calculationcore'
>> 
>> 
>>  It could also be split on Application.
>> 
>>  One of the features could be to have different ConfigSources per
>>  'category'.
>>  A ConfigSource could have a default category (or none) and would then
>>  apply to all configuration.
>>  Or assigned to a specific category which would then just be merged with
>>  all the default ones.
>> 
>>  And yet another point is security. We sooner or later need to integrate
>>  the SecurityManager. And categories might be used for restricting access to
>>  certain parts of the configuration.
>> 
>>  Just brainstorming a bit...
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>>  On Sunday, 28 December 2014, 11:45, Romain Manni-Bucau <
>>  [email protected]> wrote:
>> 
>> 
>>  >
>>  >
>>  >What are categories? Like prefixes? Tenants?
>>  >Not sure v1 needs it
>>  >Le 28 déc. 2014 11:07, "Mark Struberg" 
> <[email protected]> a écrit :
>>  >
>>  >If we manage configuration container wide for multiple applications and
>>  parts of those then we _might_ like to introduce 'categories'.
>>  >>
>>  >>
>>  >>In DeltaSpike we decided to not needing them because it is easy to 
> just
>>  use namespacing and be done. But DeltaSpike config is mostly used inside an
>>  application and Tamaya should target container-wide configuration.
>>  >>
>>  >>
>>  >>So do we need those?
>>  >>
>>  >>We need to think through a few scenarios e.g. with multiple WARs
>>  configured on the same server. And also clustering.
>>  >>
>>  >>All the configuration along the classpath is 'local' to the 
> current
>>  application anyway, but what about java env and properties, or a database
>>  configuration?
>>  >>Do we simply suggest using namespaces or do we like to introduce 
> some
>>  application/category context?
>>  >>
>>  >>
>>  >>As always: adding this adds complexity and we really ONLY must do 
> that
>>  if the advantages outpace the complexity.
>>  >>
>>  >>
>>  >>LieGrue,
>>  >>strub
>>  >>
>>  >
>>  >
>> 
>

Reply via email to