[
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
