For a customer I extended the OSGi enRoute Configurer to do something like
this. I allowed you to indicate that certain properties were ‘precious'. (See
https://github.com/osgi/osgi.enroute/blob/310c16182abab915907b40803aa8e3377d7ae8ed/osgi.enroute.configurer.simple.provider/src/osgi/enroute/configurer/simple/provider/Configurer.java#L331-L349)
Kind regards,
Peter Kriens
> On 19 Nov 2017, at 21:12, elias vasylenko via osgi-dev
> <osgi-dev@mail.osgi.org> wrote:
>
> Brilliant thanks for the response, I will absolutely file this in the issue
> tracker. I didn't expect it would be reasonable to slip into R7 at this point
> if it wasn't already on the cards behind the scenes so I understand.
>
> There are reasonable philosophical arguments against it ... but it's worth
> considering.
>
> Regards,
>
> Eli
>
> On Sun, 19 Nov 2017 at 09:27 Carsten Ziegeler <cziege...@apache.org
> <mailto:cziege...@apache.org>> wrote:
> Hi,
>
> the Configurator specification (as well as the Configuration Admin one)
> does not support merging of configurations.
>
> Unfortunately, a use case of merging has never been brought up to the
> expert group during the discussions and therefore we didn't consider
> this at all. That said, I think it would be great if you could create an
> issue in the public OSGi issue tracker for this. This will make it
> easier to consider for the expert group and it doesn't get lost.
>
> I think it's too late for the R7 release as we're almost done with all
> the specification work and are currently finalizing the release. But
> it's something we can consider for R8.
>
> Regards
>
> Carsten
>
>
> Osgi Developer Mail List wrote
> > I have some thoughts/questions about the upcoming configurator
> > specification in OSGi R7
> > <https://osgi.org/download/osgi.enterprise-7.0.0-early-draft-2017-10.pdf
> > <https://osgi.org/download/osgi.enterprise-7.0.0-early-draft-2017-10.pdf>>.
> >
> > The spec talks about the concept of a configuration ranking, by which
> > the configurator service selects the most appropriate configuration to
> > apply. But what if we already have a working configuration deployed and
> > only wish to override certain values? Can we do something like the
> > following?
> >
> > [existing-baseline-configuration.json]
> > {
> > "my.pid": {
> > ":configurator:ranking": "0",
> > "key_one": "configured_value",
> > "key_two": "configured_value",
> > "key_three": "configured_value"
> > }
> > }
> >
> > [new-partial-configuration.json]
> > {
> > "my.pid": {
> > ":configurator:ranking": "1",
> > "key_three": "overriding_value"
> > }
> > }
> >
> > Normally in this scenario I assume [new-partial-configuration.json] will
> > be selected as the one to apply and the other will be completely
> > ignored. But I would hope there is a way to tell the configurator we
> > want to merge a configuration with the next-highest-ranked
> > configuration, such that the configurator will ultimately resolve
> > something like the following:
> >
> > [effective configuration]
> > {
> > "my.pid": {
> > "key_one": "configured_value",
> > "key_two": "configured_value",
> > "key_three": "overriding_value"
> > }
> > }
> >
> > I realise this behaviour isn't /always/ what we'd want, but perhaps we
> > could apply some PID-level configurator key to
> > [new-partial-configuration.json] to opt in, e.g.
> > "/:configurator:override-strategy": "complete/partial/whatever"/
> >
> > Since something like this doesn't appear to be mentioned in the latest
> > draft I assume it's not currently planned, but I'm hoping I've
> > misunderstood or misread some part of it because this seems like an easy
> > win to me. Perhaps there has been internal discussion of something like
> > this and it was dismissed for some reason? I realise it adds some
> > complexity to the implementation but I don't think it really adds any
> > confusion to the mental model for users.
> >
> > Any further comment or discussion would be welcome,
> >
> > Cheers,
> >
> > Eli
> >
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> > <https://mail.osgi.org/mailman/listinfo/osgi-dev>
> >
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org <mailto:cziege...@apache.org>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
