[
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
