[jira] [Updated] (FELIX-3377) Allow a component to update its own service properties
[ 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
[jira] [Updated] (FELIX-3377) Allow a component to update its own service properties
[ 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
[ 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
[ 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] [Updated] (FELIX-3377) Allow a component to update its own service properties
[ 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
[ 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] [Updated] (FELIX-3377) Allow a component to update its own service properties
[ 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
