Arnoud Glimmerveen commented on FELIX-6161:

The current implementation covers a specific use-case of having multiple 
references to the same objectClass with (possibly) different additional 
filtered properties. The single ServiceListener on that objectClass takes in 
the events and distributes them internally (which is the 'problematic' part for 
the Service ListenerHook use case, as it is not able to observe the target 
Other use cases where a component binds to two different objectClasses that are 
coincidentally realized by the same service instance will still trigger the 
behaviour that FELIX-4964 intended to solve: multiple deactivate/activate.

I am looking into the possibility to extend SCR implementation to track whether 
different references end up at the same service instance and try to see if it 
is possible to 'eagerly' determine the impact of the first ServiceEvent on the 
other listeners that are tracking the same service instance, in order to have 
at most one deactivate/activate. This would cover the original behaviour and 
would also enable the Service ListenerHook use case. 
SCR's ability to reconfigure the target filter of a reference could be a 
complicating factor and as [~tjwatson] indicated has the risk of losing events. 
Could this not be addressed by first registering the ServiceListener with the 
reconfigured target filter before unregistering the old one?

Any thoughts on this approach? Would this be feasible?

> SCR: Method of resolving references limits Service ListenerHook 
> implementations
> -------------------------------------------------------------------------------
>                 Key: FELIX-6161
>                 URL: https://issues.apache.org/jira/browse/FELIX-6161
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-2.1.16
>            Reporter: Arnoud Glimmerveen
>            Priority: Major
>         Attachments: FELIX-6161.patch
> When experimenting with creating a Service ListenerHook to realise a 
> [providing a service on demand 
> pattern|https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721],
>  I noticed that references from components managed by Felix SCR were not 
> showing up as expected: When a reference declares a target filter, that 
> target filter is not included in the ListenerInfo provided to the 
> ListenerHook. As a consequence the ListenerHook is unable to create a 
> matching service.
> Source of the observed behaviour is how SCR tracks references, specifically 
> that it opens a ServiceListener for just the className and performs the 
> matching of the target filter inside the ServiceListener. This approach 
> unfortunately hides the target filter from the Service ListenerHook and thus 
> the Service ListenerHook will have insufficient information to create a 
> matching service.
> Also look at the discussion on the dev mailing list: 
> [https://www.mail-archive.com/dev@felix.apache.org/msg48657.html] 

This message was sent by Atlassian Jira

Reply via email to