Oh I thought about the SecurityManager stuff again. Romain is right that we don't need categories but instead could leverage namespaces.
A SecurityManager could e.g. use regexp and define that anything with .*passphrase must only be accessed by certain code parts. LieGrue, strub > On Sunday, 28 December 2014, 14:02, Mark Struberg <[email protected]> wrote: > > 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 >>>>> >> >>>>> > >>>>> > >>>>> >>>> >> >
