[
https://issues.apache.org/jira/browse/FELIX-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks updated FELIX-4149:
--------------------------------
Fix Version/s: (was: scr-1.8.2)
scr-2.0.0
> 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-2.0.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 was sent by Atlassian JIRA
(v6.2#6252)
