[
https://issues.apache.org/jira/browse/FELIX-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16885866#comment-16885866
]
David Jencks commented on FELIX-6161:
-------------------------------------
Rereading FELIX-4964, I see that my "most likely" scenario indeed had
references with identical filters, which your patch takes care of. It's still
possible for references with different filters to match the same service.
Reactivating with different services for the references would be pretty odd;
would this actually happen, or does the reactivation recompute all the
references? If all references are recomputed, the worst that could happen is
the component deactivates/reactivates an extra time for no apparent reason.
I don't think there's a solution that will solve all the problems here. I think
all the problems are edge cases. Personally, I think that magically making
services appear when they are requested (rather than registering services that
represent some non-osgi service when requested) is a bit odd and that
maintaining simpler SCR behavior is more useful and important. What do others
think?
> 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/[email protected]/msg48657.html]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
