Hi,
On Sun, Jul 31, 2016 at 7:07 AM Carsten Ziegeler <cziege...@apache.org>
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.
> >
>
> 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.
>
Do you have a concrete example of when this wouldn't be desired? I'm
struggling to think of a case. But even if this was wrong, we can always
have a flag at either the parent or child level which disables the
inheritance. Still, I wouldn't suggest implementing this without a specific
use case which requires it as this would be a relatively simple and
backwards compatible addition.
>
> 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.
>
I'm not really sure what kind of "tooling" you are describing and based on
the subsequent emails in this thread I'm even more confused. If it isn't
"special" tooling, then how does this tooling know the inheritance/merging
rules?
Regards,
Justin
>
> Regards
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
>
