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