[
https://issues.apache.org/jira/browse/FELIX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478387
]
Clement Escoffier commented on FELIX-222:
-----------------------------------------
According to the osgi-dev mailing list thread, I propose the following the
config admin handler changed :
- the handler does not exposed the ManagedService, configuration will be pushed
via the factory.
- if configurable="true", pushed configuration will be propagated to the
service registration.
It allows the enabling / disabling the propagation easily.
> iPOJO should automatically propagate configuration properties as service
> properties, per CM spec.
> -------------------------------------------------------------------------------------------------
>
> Key: FELIX-222
> URL: https://issues.apache.org/jira/browse/FELIX-222
> Project: Felix
> Issue Type: Improvement
> Components: iPOJO
> Environment: Not relevant.
> Reporter: Steven E. Harris
>
> The Configuration Admin Service Specification advises in Section 104.4.3,
> Property Propagation, that:
> An implementation of a Managed Service should copy all the properties of
> the Dictionary object
> argument in updated(Dictionary), known or unknown, into its service
> registration properties
> using ServiceRegistration.setProperties.
> It looks like iPOJO does some of this propagation for a ManagedService in
> ConfigurationHandler.updated() around line 256, apparently only propagating
> the properties not known as "configurable properties". However, I think this
> reading of the specification may be too literal, in that iPOJO does not do
> the same propagation of the initial properties provided to a
> ManagedServiceFactory.
> ComponentManager implements ManagedServiceFactory. In its updated(String,
> Dictionary) method, it calls on createComponentInstance(), which then calls
> on InstanceManager.configure(), which lets each Handler take its turn
> configuring the new instance. Of particular interest here is
> ProvidedServiceHandler.configure(). It only exposes properties defined in
> <property> elements inside the <provides> element of a component metadata
> specification. Any properties provided in the initial configuration not
> defined beforehand in the metadata are ignored and not published as service
> properties.
> The CM specification does note:
> A configuration target service may ignore any configuration properties it
> does not recognize, or it may change the values of the configuration
> properties
> before these properties are registered. Configuration properties in the
> Framework service registry are not strictly related to the configuration
> information.
> This seems to contradict the advice in the first paragraph, perhaps just
> clarifying that compliance is not mandatory. What would be useful is some
> directive on the <provides> element that would allow all unknown
> configuration properties to be propagated as service properties. At present,
> this propagation must be done manually by defining each service property
> under the <provides> element, which makes it impossible to ever propagate an
> unknown configuration property.
> Finally, though the CM specification does talk about "a Managed Service" and
> mentions the single-argument updated(Dictionary) method, the rest of the text
> in Section 104.4.3 sounds as though it's describing how both ManagedService
> and ManagedServiceFactory should work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
