[rfc 0134] DS - Better integration with ConfigAdmin/ManagedService

[bjhargrave]

Original bug ID: BZ#763 From: Fredrik Alströmer <fredrik.alstroemer@sap.com> Reported version: R4 V4.1

[bjhargrave]

Comment author: Fredrik Alströmer <fredrik.alstroemer@sap.com>

According the OSGi Service Platform Service Compendium R4, 4.1, the Declarative Services will interact with the Configuration Admin Service and, if there's an update of the configuration with the same PID as the service id, the component will be deactivated and reactivated with the new configuration properties.

Now, the Configuration Admin Service is able to push configuration changes directly to the component using the Managed Service interface. This behavior, however, cannot be combined with the Declarative Services, and on configuration changes, the component will be de- and reactivated regardless.

I would need the SCR to detect the fact that a ManagedService interface is provided for the PID corresponding to the service id (although that should probably be implicit for the sake of simplicity, if it isn't defined), and NOT deactivate the component in this case, but let it handle the update at run-time.

It's not 100% clear to me if this requires changes to the configuration admin service, but I suppose that the SCR could probably insert itself as a middleware, not exposing the service from the component directly, and just forwarding requests whenever the component is active.

[bjhargrave]

Comment author: @bjhargrave

CPEG mtg: We add a modified attribute. If specified component will be called at that method before the service properties are updated. modified method will take same args as activate.

[bjhargrave]

Comment author: @bjhargrave

Here is my draft of the changes necessary to DS to allow for Configuration changes to not require deactivation/reactivation of a component configuration. I need your feedback ASAP. I will begin making these changes to the DS spec unless I receive any objections.

Change Proposal

Add a new 'modified' attribute to the component element. The presence of this attribute indicates the component wants different treatment when a satisfied component configuration has component properties from a (ConfigurationAdmin) Configuration changed. The value of the attribute is a name of a method (which has the same possible signatures as the activate method).

If the modified attribute is not specified, then the current behavior occurs: A satisfied component configuration becomes unsatisfied and must be deactivated. The component configuration may be satisfiable with the changed Configuration.

If the modified attribute is specified, then the component will have the following (altered) behaviors:

A changed Configuration does not automatically result in the component configuration becoming unsatisfied.

A satisfied component configuration may become unsatisfied if the target property of a reference changed as a result of the Configuration change{*1} which results in the reference becoming unsatisfied.

A reference can become unsatisfied by a change in its target property if either: a) A bound service of a static reference is no longer a target service (that is, the bound service does not match the updated target property), or b) There are no target services for a mandatory dynamic reference (that is, there are no service which match the updated target property and the reference requires at least one service)

If the component configuration becomes unsatisfied, it must be deactivated.

If the Configuration change does not cause the component configuration to become unsatisfied, then the following will occur:

If the component configuration is not activated (that is, it is a delayed component for which DS has registered a service), DS must modify the service properties of the component configuration's service.

If the component configuration is activated, DS must, in the following order{*2}:

1) Update the ComponentContext of the component configuration with the modified component properties. 2) Call the modified method named by the modified attribute. This will provide the modified component properties if the modified method's signature accepts them. 3) Modify the bound services of the dynamic references if the set of target services changed due to changes in target properties. This can result in calls to the bind/unbind methods of the dynamic references. 4) Modify the service properties of the component configuration's service if it is a service (that is, the component description specifies the service element).

---

{*1} For a factory component, a target property specified to ComponentFactory.newInstance can never be overriden by a Configuration.

{*2} The above order is basically "reprogram/rebind" the component before advertising the change via the service properties. With this ordering, users of the service will not know about the service property changes until after the component has been "reprogrammed". So there is a window where users of the service will think it is still the old way but it is actually the new way. But I think this ordering most closely follows how a bundle would use ManagedService itself.

[bjhargrave]

Comment author: @bjhargrave

I added the proposal from comment 2 to the DS spec for 4.2.

A pdf of the draft is available at https://www.osgi.org/members/svn/documents/trunk/project/sp-r4.2/drafts/service.component.pdf