You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Steven E. Harris (JIRA)" <ji...@apache.org> on 2007/03/04 21:23:50 UTC
[jira] Created: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
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.
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478490 ]
Clement Escoffier commented on FELIX-222:
-----------------------------------------
It's what I would like.
However it has some issues to resolve :
- how handlers will be notified of the update ? Does handler have a dedicated method (reconfigure(Dictionary d) ) ?
- does I invalidate the instance during the re-configuration ? How maintaining created objects consistent ?
> 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.
[jira] Updated: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
Posted by "Steven E. Harris (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478103 ]
Clement Escoffier commented on FELIX-222:
-----------------------------------------
In my mind, the difference between ManagedServiceFactory & ManagedService is that the first one create instances (i.e. service provider) while the second one configure an existing instance. In iPOJO, the difference is when the updated method is called. On a ManagedServiceFactory targetting an existing instance, the instance is killed and recreated with the new configuration. When the updated method is called on the ManagedService, the instance is not stopped, the new configuration is apply "on the fly".
I does not know this details about the config admin. That means, that iPOJO cannot expose ManagedService if the is parent factory is exposed. I don't have a solution on the shelf, we can do the following items :
First, I need to ask on the osgi-dev mailing list if the propagation must or must not be implemented, or if it can be enable/disable.
Secondly, the configurable="true" should propagate the received (instance) configuration to service registration. (Perhaps should we change configurable in propagation). It keeps the problem of the instance recreation.
If you see another stategy, it is welcome.
> 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.
[jira] Commented: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
Posted by "Steven E. Harris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477870 ]
Steven E. Harris commented on FELIX-222:
----------------------------------------
The example "Configuring a Console Bundle" in Section 104.5.5.1 of the Configuration Admin specification shows this kind of propagation taking place for a ManagedService.
Unfortunately, the "similar" example in section 104.6.5 for ManagedServiceFactory does not show the same propagation taking place, as the Consoles themselves are not shown as registered as services, and hence have no service properties to expose.
> 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.
[jira] Commented: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477967 ]
Clement Escoffier commented on FELIX-222:
-----------------------------------------
iPOJO does not propagate property received by the ManagedServiceFactory. Some of these properties can be private, and must not be published inside service registration.
However, an iPOJO instance can be dynamically re-configured if exposing the ManagedService. In this case, the component instance say : "I am re-configurable via the configuration admin, and updated properties will be propagated to my service registrations". To allow this behavior, put configurable="true" in the "properties" element.
<properties configurable="true">
<property ..../>
<property .../>
</properties>
I don't think that configurable="true" is the good way to say this. If somebody has a better word (perhaps reconfigurable is better).
> 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.
[jira] Commented: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
Posted by "Steven E. Harris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478481 ]
Steven E. Harris commented on FELIX-222:
----------------------------------------
When you say, "configuration will be pushed via the factory", does this mean that the related fields in the service class instance will be updated? Is it possible for the instance to be notified that its configuration got updated? Does it go through a lifecycle state transition upon update?
> 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.
[jira] Closed: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall closed FELIX-222.
---------------------------------
Resolution: Fixed
Assignee: Richard S. Hall
I applied the patch.
> 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
> Assigned To: Richard S. Hall
> Attachments: reconfiguration.patch
>
>
> 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.
[jira] Commented: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
Posted by "Steven E. Harris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478115 ]
Steven E. Harris commented on FELIX-222:
----------------------------------------
Note the related thread on the OSGI-Dev mailing list:
Configuration Property propagation by ManagedServiceFactory
http://www2.osgi.org/pipermail/osgi-dev/2007-March/000415.html
> 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.
[jira] Updated: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Clement Escoffier updated FELIX-222:
------------------------------------
Attachment: reconfiguration.patch
Patch to applied on the iPOJO Core project.
This patch allow to reconfigure and to propagate properties to service registration via the ManagedServiceFactory. The propagation is allowed by the configurable attribute.
Moreover, the patch solve a lot of formatting problems (missing comments, indentation ...)
> 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
> Attachments: reconfiguration.patch
>
>
> 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.
[jira] Commented: (FELIX-222) iPOJO should automatically propagate
configuration properties as service properties, per CM spec.
Posted by "Steven E. Harris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478087 ]
Steven E. Harris commented on FELIX-222:
----------------------------------------
What's the difference in the privacy of properties to provided to a ManagedServiceFactory versus a ManagedService? Is the idea that some properties may be addressed to the factory itself, not the created service? (Side question: Does "ManagedServiceFactory" mean "Factory to created ManagedServices" or "Managed Factory to create Services"? See the difference?)
By the way, one can't simply set the "configurable" attribute to true for a ManagedServiceFactory. The problem is that the components created by the factory are then registered themselves as ManagedServices, using their "service.pid" property. This registration is expressly forbidden by the CM specification in Section 104.6.2 in the paragraph starting with "The receiver must not".
I tried setting "configurable" to "true" and the Equinox CM bundle picked up on this problem, rejecting the ManagedService registration since its PID was already bound to a "factory configuration" known to CM.
> 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.