[
https://issues.apache.org/jira/browse/FELIX-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928001#comment-16928001
]
Thomas Watson commented on FELIX-6161:
--------------------------------------
I will point out that this scenario is the motivation for adding
org.osgi.framework.UnfilteredServiceListener to the specification at one point.
But I am reluctant to go with a solution that continually remove/add the
single listener for the bundle in order to change the big filter that covers
all the possible services all the components in the bundle may need. That
sounds like it is filled with timing issues because of events that could be
lost while doing the remove/add with new filter.
I'm also not sure I like a solution that adds more listeners to give the
information and I also wonder if keeping the filters up to date with the
currently configured target filters would not have the same timing issues when
doing the remove/add new filter for the listener. My vote would be to not deal
with this usecase. But I admit the usecase is not one that is appealing to
anything I need SCR for today.
> 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
(v8.3.2#803003)
