felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4149) Do not directly support modifying service registration properties
Date Thu, 19 Sep 2013 06:47:51 GMT

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

David Jencks commented on FELIX-4149:

we're using this feature extensively.  Unfortunately I and the other people using this missed
the announcement that the EEG was going to discuss it.

I think I'd be OK only allowing this for regular scope components (not service factory and
not prototype) but would prefer to give it some more thought.
> Do not directly support modifying service registration properties
> -----------------------------------------------------------------
>                 Key: FELIX-4149
>                 URL: https://issues.apache.org/jira/browse/FELIX-4149
>             Project: Felix
>          Issue Type: Task
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-1.6.2
>            Reporter: Felix Meschberger
>             Fix For: scr-1.8.0
> With FELIX-3377 we implemented a feature for a component to easily influence its service
registration properties. This sounds very useful upfront but has some intricate implications:
> * If a component is instantiated multiple times as a result of being a factory service
(instantiation per using bundle) or even as a new prototype service (instantiation per retrieval
from the service registry) each such instance may independently modify the service registration
properties of the shared service registration. This may have strange implications.
> * If changing the service registration properties may cause changes in using the service,
it may be that a loop may be created: Consider a component C1 being registered as a delayed
service. When this service is retrieved using a service filter, the component is activated
and may change the registration properties. This may cause the consumer's service filter to
not match any more and hence to unget the service immediately. This may cause the Component
C1 to be deactivated and change back the service registration property. Now the consumer's
filter matches again and C1 is retrieved and activated again ...
> Now, granted both situations may also happen if DS would not support setting service
registration properties. But the chances of falling into the trap is higher if it would be
too simple to do. Also explaining the why's and pro's and con's etc. is somewhat complicated.
On the other hand the use case is not one happening very often -- in our application of 100s
of components we had it once or twice.
> So the OSGi CPEG decided to not add this feature to the specification.
> I am aware, that we unfortunately already released a version of Felix DS supporting this
feature. So it will be a hard decision to revert that.
> I propose to disable the feature by default and allow it to be explicitly enabled using
some configuration (similar to what we did with the non-spec-compliant handling of factory
configuration for Component Factory components).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message