[
https://issues.apache.org/jira/browse/FELIX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven E. Harris updated FELIX-222:
-----------------------------------
Description:
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.
was:
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.
The seems to contradict the advise 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.
Fixed a few spelling errors.
> 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.
