[
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
