[ 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