> 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.
>
Well, I could argue the opposite: if you have merging (or inheritance) then
you change the attribute of a parent and this influences all childs and you
have no idea what happens there and worst case you end up editing all child
configurations by overriding that property.
I personally think this comes all down to tooling - no one (at least I
hope so) is editing all these configurations by hand in the repository.
That's - regardless if you have merging or not - error prone.
So a provisioning tool can do all what is requested here: it knows the
parent configuration, it knows the inheritance/merging rules and it
can apply the changes in the way the editor of the configuration intents
to. And that means we *could* move all this functionality into the
tooling but keep the implementation at run time crystal clear.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
