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

David Jencks commented on FELIX-6161:
-------------------------------------

Looking briefly at your patch from the point of view of FELIX-4964, I think 
that your patch will produce one service reactivation if all references use the 
same target filter, but more than one reactivation if the references use 
different target filters.  I doubt that if you have more than one reference to 
a service from a single component they would have the same filters.... why 
would you need more than one? It's more likely that the filters are different 
but happen to select the same service.

Did I understand your patch correctly?

Does my thinking make sense?

> 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
(v7.6.14#76016)

Reply via email to