Most components should be fine with just injecting the appropriate interface, as that way they are in charge of how the change is propagated – i.e. via normal service bind/unbind. There are a few components, which ignore updates – which is really not what should be done and therefore we will ignore them for now.

Hence the basic mode of operation should be something like this:

@Component
public final SomeComponent implements ComponentService {
    @Reference
    ComponentDataObject config;

}

which will bind ComponentDataObject as a service in OSGi DS. Now we are faced with a slight problem: there is no provider for that service, as it is usually no provider. For that part we need to provide some amount of substrate, so that applications can easily create their component to provide the service, something like:

@Component
// Well, a bit more complicated, as it ends up being a factory component
public final OSGiComponentDataObject extends AbstractDatastoreConfiguration<ComponentDataObject> implements ComponentDataObject {
    @Reference
    void bindDataBroker(DataBroker dataBroker) {
        super.setDataBroker(dataBroker);
    }

    @Activate
    void activate() {
        super.start();
    }

    @Deactivate
    void deactivate() {
        super.stop();
    }
}

Once we have that working and have unblocked migration, we should take it a bit further and do:

@Component
public final SomeComponent implements ComponentService {
     @Reference
     @DatastoreConfiguration
     ComponentDataObject config;

}

i.e. define our specific annotation, and create an annotation processor which will generate OSGiComponentDataObject into the current project.

Based on a prototype in AAA's password service, this is probably going to be quite involved. See https://git.opendaylight.org/gerrit/c/aaa/+/93104 .

The problem is that it is quite a bit of code, which has a dependency on mdsal-binding-api, there is an unneeded proxy, etc.

There is also the tiny issue of the bundle having a Require-Capability for a the config being exposed as a service – and that gets checked statically before the bundle is ever installed. We essentially would need to insert a runtime component which will provide the binding (very much like BluePrint extension, except at feature:install time!)

This might not be feasible