[
https://issues.apache.org/jira/browse/FELIX-4964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14632355#comment-14632355
]
Carsten Ziegeler commented on FELIX-4964:
-----------------------------------------
I'm not sure if your idea is similar to my thoughts: right now we have a
separate tracker for each reference, this are informed asynchronously and
independently on a change. What about having a single tracker tracking all
changes and this one knows the internal trackers we have right now. Once a
change comes in, it goes through the list of all these internal trackers,
calculates the change set and then acts on that set. So basically instead of
letting the framework service reg do the dispatching, we do it ourselfs.
> [DS] Reactivate component at most once per service event
> --------------------------------------------------------
>
> Key: FELIX-4964
> URL: https://issues.apache.org/jira/browse/FELIX-4964
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-2.0.0
> Reporter: David Jencks
> Assignee: David Jencks
> Fix For: scr-2.0.0
>
>
> When a component has several references to the same service (most likely
> scenario is field references for object, properties, service ref all for the
> same service) and a service event results in the component being deactivated
> and activated (such as a static reference being replaced by another) then we
> should only reactivate the component instance once.
> The solution I have in mind involves distributing events to the service
> trackers for the components in a bundle through the BundleComponentActivator
> and tracking the components that need to be activated with the event. Once
> all the relevant service trackers have been notified, we can try to activate
> all the components relevant to that service event.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
