To me, this is just a name associated to one or more config sources. On Sun Dec 28 2014 at 6:48:35 AM Romain Manni-Bucau <[email protected]> wrote:
> like Properties? > > Properties myConf = new Properties(); > myConf.putAll(System.getProperties()); > myConf.putAll(myLoadedProps); > // etc... > > I guess you see how it works in spring as well. > > In CDI you would just @produces it. > > > Drawback: you know "sources" > Advanage: you know the sources so you can select the up to date ones > and void 80% of conflicts (then 20% are solved by natural overriding) > > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-28 12:39 GMT+01:00 Mark Struberg <[email protected]>: > > 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 > >>> >> > >>> > > >>> > > >>> > >> >
