@Romain: key prefix only. But it is essentially not in the code but only a 
convention. It is pretty similar to the java package structure. Which also 
shows that this approach works in practice.


@Oliver: as I said, in DeltaSpike we discussed this as well and decided to not 
need it. But Tamaya has a bit wider approach as it targets not only a single 
application but a whole ecosystem. I'm still a bit undecided myself. But I 
think we can just start without 'categories' and see how far we come with just 
namespaces. And if we see a blocker with that then we can still go back and add 
it.


LieGrue,
strub





> On Sunday, 28 December 2014, 14:45, Romain Manni-Bucau 
> <[email protected]> wrote:
> > Question is mainly: is it explicit or key prefixes only. Last works for me
> to start.
> Le 28 déc. 2014 14:40, "Oliver B. Fischer" 
> <[email protected]> a
> écrit :
> 
> 
>>  Hi Mark,
>> 
>>  category seems for me to be very similar to the concept of a namespace. Is
>>  there anything we can do with catagories what we cannot do with namespaces?
>> 
>>  Best,
>> 
>>  Oliver
>> 
>>  Am 28.12.14 um 11:05 schrieb Mark Struberg:
>> 
>>>  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
>>> 
>> 
>>  --
>>  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