felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3377) Allow a component to update its own service properties
Date Mon, 12 Mar 2012 07:36:41 GMT

    [ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227350#comment-13227350
] 

Felix Meschberger commented on FELIX-3377:
------------------------------------------

> ExtComponentContext.setServiceProperties and the return Dictionary value from activate
and update
> replace the service registration properties rather than update the values calculated
by some other method.

Yes

> calling ExtComponentContext.setServiceProperties from within an activate or modify method
would
> have the same effect as returning the service properties from the method

Yes. If both are done -- calling setServiceProperties and return Dictionary, the latter would
overwrite/replace the former.

> In order to avoid "arguments" over whether config admin or the component sets the service
properties,
> the update method would recalculate the service properties when config admin changes
them and
> reset what it wants either through a return value or calling ExtComponentContext.setServiceProperties.


IMHO configuration admin properties are primarily to configure the component and are also
(kind of secondarily) used to set the service properties. Both make sense, of course. But
if we think a component should be able to set its own service properties, it should probably
be able to do so completely but without "disturbing" its own configuration.

Thus:

#1 Component propertiesa are default configuration for the component
#2 Config Admin enhances, extends, overwrites default configuration for the component
#3 By default this set of properties is used as service properties (except private properties
starting with ".")
#4 The component may overwrite the properties from #3 by returning a Dictionary from activate
or modified or by calling setServiceProperties

In practice, I would assume a component to take the properties received from the DS runtime
(either ComponentContext.getProperties or the Map passed to the activate or modified method)
modify it and use the result to call setProperties or return from activate.

I might be conceivable, though to be slightly "strange" in the API:

(1) activate and modified may return Map<String, Object> for the service properties.
This would be inline with the DS 1.1 option to get the configuration passed as a Map into
the methods
(2) setServiceProperties would take a Dictionary<String, Object> for the service properties.
This would be inline with the original ComponentContext.getProperties method.

WDYT ?
                
> 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

        

Mime
View raw message