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 >> > >
