You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "David Jencks (Created) (JIRA)" <ji...@apache.org> on 2012/03/07 09:19:58 UTC
[jira] [Created] (FELIX-3377) Allow a component to update its own
service properties
Allow a component to update its own service properties
------------------------------------------------------
Key: FELIX-3377
URL: https://issues.apache.org/jira/browse/FELIX-3377
Project: Felix
Issue Type: Improvement
Components: Declarative Services (SCR)
Affects Versions: scr-1.6.0
Reporter: David Jencks
If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
IIUC this idea does not make sense for component factories.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (FELIX-3377) Allow a component to
update its own service properties
Posted by "Felix Meschberger (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224627#comment-13224627 ]
Felix Meschberger edited comment on FELIX-3377 at 3/7/12 7:27 PM:
------------------------------------------------------------------
This makes sense to me.
Some remarks:
(1) I would probably name the new package o.a.f.scr.component and export it with a mandatory attribute (as we do with other provisional API we export)
(2) I would rather call the MutablePropertiesComponentContext interface ExtComponentContext
(3) The JavaDoc for the updateProperties method should clearly indicate (as you propose) that the properties from the component descriptor are to be amended and/or updated and that these properties are still subject to being overwritten by configuration from Configuration Admin. This would imply that existing properties from the component descriptors cannot be removed, right ?
was (Author: fmeschbe):
This makes sense to me.
Some remarks:
(1) I would probably name the new package o.a.f.scr.component and export it with a mandatory attribute (as we do with other provisional API we export)
(2) I would rather call the MutablePropertiesComponentContext interface ExtComponentContext
(3) The JavaDoc for the updateProperties method should clearly indicate (as you propose) that the properties from the component descriptor are to be amended and/or updated and that these properties are still subject to being overwritten by configuration from Configuration Admin. This would imply that existing properties from the component descriptors cannot be removed, right ?
Have you already submitted an OSGi bug proposing this enhancement in a future spec ?
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (FELIX-3377) Allow a component to
update its own service properties
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270637#comment-13270637 ]
Felix Meschberger edited comment on FELIX-3377 at 5/8/12 5:43 PM:
------------------------------------------------------------------
Updated patch based on FELIX-3377-4.diff :
- use MethodResult to convey the result of the methods
- only support Map as a result (in line Map being used to convey configuration to activate)
- Properly differentiate between null-result (reset service properties) and void (no action)
- Created a new namespace required to support the new functionality
(components with older namespaces are not allowed to return Map)
- updated the testcase for the new namespace
My own patch from May 5th is non-functional.
was (Author: fmeschbe):
Updated patch based on FELIX-3337-4.diff :
- use MethodResult to convey the result of the methods
- only support Map as a result (in line Map being used to convey configuration to activate)
- Properly differentiate between null-result (reset service properties) and void (no action)
- Created a new namespace required to support the new functionality
(components with older namespaces are not allowed to return Map)
- updated the testcase for the new namespace
My own patch from May 5th is non-functional.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4-fmeschbe.patch, FELIX-3377-4.diff, FELIX-3377-returnDictionary.patch, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "David Jencks (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250455#comment-13250455 ]
David Jencks commented on FELIX-3377:
-------------------------------------
I've identified the source of the 3 integration test failures. In rev 1298275 we added to ImmediateComponentManager.deleteComponent a line setting m_configurationProperties to null. This is wrong. This field should only be set when confg admin provides an updates set of properties. In particular, for a component without a modify method, Config Admin calls reconfigured, which sets m_configurationProperties to the new properties. Then since there's no modify method the component has to be deleted..... wiping out the m_componentProperties we just set.... and then recreated.
The trivial patch is
--- a/scr/src/main/java/org/apache/felix/scr/impl/manager/ImmediateComponentManager.java
+++ b/scr/src/main/java/org/apache/felix/scr/impl/manager/ImmediateComponentManager.java
@@ -141,7 +141,6 @@ public class ImmediateComponentManager extends AbstractComponentManager
m_componentContext = null;
m_properties = null;
m_propertiesOverwrite = null;
- m_configurationProperties = null;
}
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated FELIX-3377:
-------------------------------------
Attachment: FELIX-3377-returnDictionary.patch
Here is my proposal.
Instead of extending the ActivatorParameter this patch introduces a MethodResult conveying the result.
In addition a new namespace .../scr/v1.2.0-felix is introduced. The component must be declared with this namespace for the return functionality to be available.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4.diff, FELIX-3377-returnDictionary.patch, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3377) Allow a component to update its own
service properties
Posted by "David Jencks (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks updated FELIX-3377:
--------------------------------
Description:
If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
IIUC this idea does not make sense for component factories.
This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
was:
If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
IIUC this idea does not make sense for component factories.
After checking that it's OK I added attribution to the osgi bug that inspired me. I'll look into your suggestions shortly.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224627#comment-13224627 ]
Felix Meschberger commented on FELIX-3377:
------------------------------------------
This makes sense to me.
Some remarks:
(1) I would probably name the new package o.a.f.scr.component and export it with a mandatory attribute (as we do with other provisional API we export)
(2) I would rather call the MutablePropertiesComponentContext interface ExtComponentContext
(3) The JavaDoc for the updateProperties method should clearly indicate (as you propose) that the properties from the component descriptor are to be amended and/or updated and that these properties are still subject to being overwritten by configuration from Configuration Admin. This would imply that existing properties from the component descriptors cannot be removed, right ?
Have you already submitted an OSGi bug proposing this enhancement in a future spec ?
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225019#comment-13225019 ]
Felix Meschberger commented on FELIX-3377:
------------------------------------------
Thanks a lot for providing the patch.
I have applied it slightly modified in Rev. 1298275:
- Added some more JavaDoc to ExtComponentContext
- Have ExtComponentContext extend ComponentContext
- Internally tread property overwrites like supplied CM configuration
This allows for properly transient property modification instead
of overwriting the actual descriptor properties which would cause
the properties for all instances created from the same descriptor
to be subsequently modified.
Does this sound correct ?
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227350#comment-13227350 ]
Felix Meschberger commented on FELIX-3377:
------------------------------------------
> ExtComponentContext.setServiceProperties and the return Dictionary value from activate and update
> replace the service registration properties rather than update the values calculated by some other method.
Yes
> calling ExtComponentContext.setServiceProperties from within an activate or modify method would
> have the same effect as returning the service properties from the method
Yes. If both are done -- calling setServiceProperties and return Dictionary, the latter would overwrite/replace the former.
> In order to avoid "arguments" over whether config admin or the component sets the service properties,
> the update method would recalculate the service properties when config admin changes them and
> reset what it wants either through a return value or calling ExtComponentContext.setServiceProperties.
IMHO configuration admin properties are primarily to configure the component and are also (kind of secondarily) used to set the service properties. Both make sense, of course. But if we think a component should be able to set its own service properties, it should probably be able to do so completely but without "disturbing" its own configuration.
Thus:
#1 Component propertiesa are default configuration for the component
#2 Config Admin enhances, extends, overwrites default configuration for the component
#3 By default this set of properties is used as service properties (except private properties starting with ".")
#4 The component may overwrite the properties from #3 by returning a Dictionary from activate or modified or by calling setServiceProperties
In practice, I would assume a component to take the properties received from the DS runtime (either ComponentContext.getProperties or the Map passed to the activate or modified method) modify it and use the result to call setProperties or return from activate.
I might be conceivable, though to be slightly "strange" in the API:
(1) activate and modified may return Map<String, Object> for the service properties. This would be inline with the DS 1.1 option to get the configuration passed as a Map into the methods
(2) setServiceProperties would take a Dictionary<String, Object> for the service properties. This would be inline with the original ComponentContext.getProperties method.
WDYT ?
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger resolved FELIX-3377.
--------------------------------------
Resolution: Fixed
Fix Version/s: scr-1.6.2
Resolving with the latest changes in Rev. 1336331
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Assignee: Felix Meschberger
> Fix For: scr-1.6.2
>
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4-fmeschbe.patch, FELIX-3377-4.diff, FELIX-3377-returnDictionary.patch, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "David Jencks (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225612#comment-13225612 ]
David Jencks commented on FELIX-3377:
-------------------------------------
I agree that having an additional map for the overrides is needed to avoid changing the defaults for multiple services based off the same component.
Many thanks!!
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271666#comment-13271666 ]
Felix Meschberger commented on FELIX-3377:
------------------------------------------
Thanks for the feedback. Actually all of the three component level methods -- activate, modified, and deactivate -- allow returning a Map. The bind and unbind methods currently are not supported to return a Map.
So for now I have applied the last patch. So we now have the following:
- Activate, Modified, Deactivate methods may return Map to set service properties
- Namespace "http://felix.apache.org/xmlns/scr/v1.2.0-felix" is required for component
declaration to support this feature
- ExtComponentContext provides setServiceProperties method to explicitly set the
service registration properties at any time
I will resolve this issue for now. If we later come up with reasonable use cases to all Map return for bind and unbind we can create a new issue and easily extend the current implementation.
Thank you very much for your input and patches.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Assignee: Felix Meschberger
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4-fmeschbe.patch, FELIX-3377-4.diff, FELIX-3377-returnDictionary.patch, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269138#comment-13269138 ]
David Jencks commented on FELIX-3377:
-------------------------------------
I prefer returning the activate/whatever method result in a method object, but I think that we need to distinguish between a method whose return type is Dictionary but returns null (I think this means that the service properties should be reset to the base properties + config admin properties) and a method whose return type is void (meaning don't do anything to service properties).
Also, I can't see any reason the bind/unbind and updated methods (and deactivate) shouldn't be able to affect the service properties in the same way.
I'll work on a new patch soon unless you beat me to it :-)
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4.diff, FELIX-3377-returnDictionary.patch, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "David Jencks (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226576#comment-13226576 ]
David Jencks commented on FELIX-3377:
-------------------------------------
I think this is a good idea. I'd like to make sure I understand a couple details.
- Both the ExtComponentContext.setServiceProperties and the return Dictionary value from activate and update replace the service registration properties rather than update the values calculated by some other method.
- calling ExtComponentContext.setServiceProperties from within an activate or modify method would have the same effect as returning the service properties from the method.
- In order to avoid "arguments" over whether config admin or the component sets the service properties, the update method would recalculate the service properties when config admin changes them and reset what it wants either through a return value or calling ExtComponentContext.setServiceProperties.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger reassigned FELIX-3377:
----------------------------------------
Assignee: Felix Meschberger
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Assignee: Felix Meschberger
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4-fmeschbe.patch, FELIX-3377-4.diff, FELIX-3377-returnDictionary.patch, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226146#comment-13226146 ]
Felix Meschberger commented on FELIX-3377:
------------------------------------------
Thinking about it, I would like to refine your original proposal as follows:
(1) New ExtCompontentContext.setServiceProperties(Dictionary)
This replaces the set of properties derived from the component properties,
configuration admin properties, and from the ComponentFactory.newInstance
call and is only used to set the component's service registration property
(2) Allow the activate and modify methods to return Dictionary
If a Dictionary is returned, the respective properties are used for
subsequent service registration (Dictionary returned from activate for
an immediate component) or to update the service registration (Dictionary
returned from modify or from activate for a delayed or service factory
component).
The first method is inline with DS 1.0 tradition, where the ComponentContext provides access to framework related functionality (BundleContext etc.) The second method is inline with the DS 1.1 tradition to require as minimal OSGi API involvement as possible.
Any private properties (starting with a ".") are filtered out of the Dictionary in both cases before using the properties for service registration.
The ExtComponent method thus only influences the service registration but not an configuration supplied to the activate or modified method.
Also updated OSGi Bug 2250 with this proposal.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed FELIX-3377.
------------------------------------
Close after release
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Assignee: Felix Meschberger
> Fix For: scr-1.6.2
>
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4.diff, FELIX-3377-4-fmeschbe.patch, FELIX-3377.diff, FELIX-3377-returnDictionary.patch
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269024#comment-13269024 ]
Felix Meschberger commented on FELIX-3377:
------------------------------------------
> I've identified the source of the 3 integration test failures. In rev 1298275 we added to
> ...
> The trivial patch is
You are of course right. Thanks. I applied that patch in Rev. 1334462
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4.diff, FELIX-3377-returnDictionary.patch, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269172#comment-13269172 ]
Felix Meschberger commented on FELIX-3377:
------------------------------------------
> Also, I can't see any reason the bind/unbind and updated methods (and deactivate) shouldn't be able
> to affect the service properties in the same way.
My patch allows the "updated" method (I call it the modified method) to return service properties.
Allowing the deactivate method to return service properties makes no sense to me. A service registered on behalf of a component is defined with default service registration properties. Those properties may be changed upon component activation. But they should probably be reverted to the original properties before component activation for symmetry reasons. I don't think the deactivate method should be able to define yet another set of properties.
I am not sure, whether the bind and unbind methods should be able to affect the service registration properties. Do you have concrete use cases in mind ?
In any case, I think my mechanism of defining a MethodResult class conveying the result is more flexible that extending the ActivationParameter which is specific to activate style methods (activate, deactivate, and modified).
> but I think that we need to distinguish between a method whose return type is Dictionary but returns null
This distinction may be important for a modified object, right. My patch does not currently support this, but this would be simple: The BaseMethod.invokeMethod currently checks for the result of invoking the method. This could be extended to be multi-state:
* If the method is void, return MethodResult.NONE (maybe rename this to MethodResult.VOID)
* Else return a MethodResult instance with the actual result, which may in fact be null, is returned
Consequently the callers (ImmediateComponentManager.createImplementationObject and ImmediateComponentManager.modify) should be changed to account for this disctinction.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4.diff, FELIX-3377-returnDictionary.patch, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3377) Allow a component to update its own
service properties
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks updated FELIX-3377:
--------------------------------
Attachment: FELIX-3377-4.diff
This improves the previous patch by:
- including tests of the new "return a map" functionality for activate, modify, and deactivate methods.
- reuses the ActivationParameter class to return the results, avoiding the possible concurrency issues of the previous patch.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4.diff, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3377) Allow a component to update its own
service properties
Posted by "David Jencks (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks updated FELIX-3377:
--------------------------------
Attachment: FELIX-3377.diff
Possible implementation of allowing a component to update its own service properties
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "David Jencks (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224856#comment-13224856 ]
David Jencks commented on FELIX-3377:
-------------------------------------
BTW the newer patch at least won't apply without first applying the build patch from FELIX-3371. I have the patches from FELIX-3345 applied also, if this causes problems let me know and I'll come up with something that only needs FELIX-3371.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3377) Allow a component to update its own
service properties
Posted by "David Jencks (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks updated FELIX-3377:
--------------------------------
Attachment: FELIX-3377-3.diff
Implements Felix's suggestions.
This has 3 integration test failures for me that I haven't solved yet. On the other hand I'm getting these failures without the changes as well so it is not clear that I've caused them.
I've implemented this additional featue: if the setServiceProperties method is called with null or an empty dictionary, or the activate or modify method with a Map or Dictionary return type returns null or an empty map/dictionary, then the service properties override is turned off and the service properties are reset to the combination of the defaults from config.xml and the config admin settings.
I'm not thrilled with how the return value for activate and modify methods is returned to the caller, and what I've done might have concurrency issues.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3377) Allow a component to update its own
service properties
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271144#comment-13271144 ]
David Jencks commented on FELIX-3377:
-------------------------------------
I like your latest patch FELIX-3377-4-fmeschbe.patch. I'd be happy it you applied it. I'm going to look more into whether bind, updated, and deactivate methods can plausibly return a Map to affect service registration properties, I think there are some valid use cases.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4-fmeschbe.patch, FELIX-3377-4.diff, FELIX-3377-returnDictionary.patch, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3377) Allow a component to update its own
service properties
Posted by "David Jencks (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks updated FELIX-3377:
--------------------------------
Attachment: FELIX-3377-2.diff
Implement Felix M's suggestions
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3377) Allow a component to update its own
service properties
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated FELIX-3377:
-------------------------------------
Attachment: FELIX-3377-4-fmeschbe.patch
Updated patch based on FELIX-3337-4.diff :
- use MethodResult to convey the result of the methods
- only support Map as a result (in line Map being used to convey configuration to activate)
- Properly differentiate between null-result (reset service properties) and void (no action)
- Created a new namespace required to support the new functionality
(components with older namespaces are not allowed to return Map)
- updated the testcase for the new namespace
My own patch from May 5th is non-functional.
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377-4-fmeschbe.patch, FELIX-3377-4.diff, FELIX-3377-returnDictionary.patch, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired.
> According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira