+1 for me too, one of the real life examples that I have in most of my projects is that you have a site /content/mysite and you have some languages like /content/mysite/en and /content/mysite/fr
It would be nice to put all your global mysite configs on /content/mysite, but still have the possibility to override and make new ones on language level. Or is this not even applicable with the context aware configs? Greets Roy > On 30 Jul 2016, at 10:10, Georg Henzler <[email protected]> wrote: > > A big +1 from my side to support merging (all the way down to property level) > from the very first release. IMHO it's not that hard to implement and it > saves a lot of frustration downstream. > > On 2016-07-29 17:10, Justin Edelson wrote: >> Allow me to disagree. This lack of merging is actually one of the key pain >> points I have with OSGi ConfigAdmin and I would really love to see it >> accommodated here. The problem with not merging is that it results in a lot >> of error-prone duplication and you can easily get into a state where new >> default values (in the global configuration) are not propagated as expected >> because once override any configuration property you are effectively >> hard-coding the *current* global configuration in your override. Future >> changes (or even additions) to that global configuration does not have the >> expected result. >> Consider this case: >> Global: { >> 'services' : { >> 'serviceA' { >> 'endpoint' : 'https://api.com/foo' >> } >> } >> } >> Site: { >> 'services' : { >> 'serviceA' { >> 'endpoint' : 'https://stage.api.com/foo' >> } >> } >> } >> Works OK. But at some point down the line, the developer of the component >> consuming this configuration finds that a timeout value needs to be >> specified. They do the needful and modify the global configuration to be: >> { >> 'services' : { >> 'serviceA' { >> 'endpoint' : 'https://api.com/foo', >> 'timeout' : 500 >> } >> } >> } >> I'd suggest that the reasonable expectation is that the timeout would apply >> to all contexts. But without merging, this won't happen. >> Merging is hard to add after-the-fact because it is almost impossible to >> make backwards-compatible. Since we are starting with a blank slate here, >> I'd strongly suggest that this new capability support merging from the >> start. >> I would also disagree that this isn't a problem already. The adoption of >> service users is a recent specific case where the failure of JcrInstaller >> to support merging was an impediment. We had to add the "amended" >> configuration PID specifically to work around that problem because it was >> pretty clearly nonscalable to have a centralized list of service user >> configurations. I could go through my archives of 6 years of AEM projects >> and easily find hundreds of overridden sling:OsgiConfig nodes which had >> properties totally unrelated to the desired configuration change. But since >> the configuration is all there, there's no real way to know (save for >> documentation) what *specific* configuration change was desired vs. what >> properties had to be copied just to get a component to retain its original >> behavior. >> Caveat - In a former life, I worked extensively with the dependency >> injection framework ATG Nucleus for a large, multi-property, multi-site >> deployment which supported configuration merging and I've spent the last >> many years pining away over this one aspect of Nucleus. >> Justin >> On Fri, Jul 29, 2016 at 10:39 AM Carsten Ziegeler <[email protected]> >> wrote: >>> > Hi, >>> > Properties should not be merged, as that will produce undesirable side >>> > effects, however some things need to be merged. >>> > >>> > Having attempted to write documentation I found it easiest to describe in >>> > terms of json documents. >>> > Using the examples in >>> > https://gist.github.com/ieb/460504e79c861cb980f4f0154210a869 >>> > >>> > given 2 configs from different locations >>> > >>> > Location A >>> > >>> > { >>> > "socialmedia" : { >>> > "youtube" : { >>> > "enabled" : false, >>> > "url" : "https://youtube.com"; >>> > }, >>> > "facebook" : { >>> > "enabled" : false, >>> > "apiusage" : false, >>> > "url" : "https://youtube.com"; >>> > }, >>> > >>> > Location B >>> > >>> > { >>> > "socialmedia" : { >>> > "facebook" : { >>> > "enabled" : true, >>> > "url" : "https://facebook.com"; >>> > } >>> > } >>> > } >>> > >>> > >>> > The result of A then B should be >>> > >>> > { >>> > "socialmedia" : { >>> > "youtube" : { >>> > "enabled" : false, >>> > "url" : "https://youtube.com"; >>> > }, >>> > "facebook" : { >>> > "enabled" : true, >>> > "url" : "https://facebook.com"; >>> > } >>> > } >>> > } >>> > >>> > >>> > ie Objects are merged but properties are not. socialmedia.facebook from A >>> > does not add @apiusage to the result, as socialmedia.facebook form B >>> > overwrites socialmedia.facebook from A. >>> > >>> > That will allow a deployer to completely replace a configuration "object" >>> > without having to get their head around more complex inheritance rules. >>> > This does assume that configurations are collected together into >>> "objects". >>> > I think its is important to keep it simple. >>> > If this isnt simple enough then it needs some more thought. >>> > >>> Yes, I think we agree on this, and that's how my implementation >>> currently works). So for your above example if we have "A then B" and >>> you get the collection for "socialmedia" you get "youtube" and >>> "facebook" with the properties you list above. >>> This is merging on a resource collection level and yes, we must do that. >>> My post here was more about merging properties, sorry that I didn't make >>> this clear :) >>> But it's great that we have a common understand now >>> Thanks >>> Carsten >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> [email protected]
