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
<cziege...@apache.org>
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
cziege...@apache.org
