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