again: if you use namespacing then there is just no conflict. If we do all that stuff just to avoid conflicts, then we should go back and confess it. That's just a non problem.
We should NOT do weirdly complex stuff just to work around other peoples stupid ideas. Remember, we agreed to start on a clean sheet. That was the main argument to use Java8 as well. Imo we should not aim to be a 1:1 drop in replacement for every sub-par legacy solution but to resolve user problems. That includes that they surely have to adopt their way of thinking sometimes. LieGrue, strub > On Sunday, 28 December 2014, 12:46, 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 >>>> >> >>>> > >>>> > >>>> >>> >
