[
https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224627#comment-13224627
]
Felix Meschberger commented on FELIX-3377:
------------------------------------------
This makes sense to me.
Some remarks:
(1) I would probably name the new package o.a.f.scr.component and export it
with a mandatory attribute (as we do with other provisional API we export)
(2) I would rather call the MutablePropertiesComponentContext interface
ExtComponentContext
(3) The JavaDoc for the updateProperties method should clearly indicate (as you
propose) that the properties from the component descriptor are to be amended
and/or updated and that these properties are still subject to being overwritten
by configuration from Configuration Admin. This would imply that existing
properties from the component descriptors cannot be removed, right ?
Have you already submitted an OSGi bug proposing this enhancement in a future
spec ?
> 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
