[
https://issues.apache.org/jira/browse/FELIX-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks resolved FELIX-4149.
---------------------------------
Resolution: Fixed
Assignee: David Jencks
I'm definitely not going to remove this feature. You have to enable it
explicitly, either with the felix 1.2 namespace or with a
configurableServiceProperties flag in the xml. I added a validation check to
also only allow it for singleton comonents (for pre 1.3, this means
non-service-factory). This might require some users to update to using the
namespace or flag on individual components if they previously had multiple
components configured in the same xml file some of which are service-factories.
> 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
> Assignee: David Jencks
> 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)
