[ https://issues.apache.org/jira/browse/FELIX-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16957290#comment-16957290 ]
Arnoud Glimmerveen commented on FELIX-6161: ------------------------------------------- [~tjwatson] &.[~djencks] would you consider the patch currently attached to this issue ( [^FELIX-6161.patch] ) suitable to be incorporated into SCR? I believe it maintains SCR's behaviour in relation to FELIX-4964, but would then also allow the [service on demand|https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721] pattern to be available for Declarative Service users. An earlier [comment on the mailing list|https://www.mail-archive.com/dev@felix.apache.org/msg48663.html] regarding this issue mentioned concerns regarding performance, in relation to the (possible) increase in ServiceListeners due to this change. Is this still a concern or are there other concerns that should be addressed before accepting this as change/extension of SCR? > 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.4#803005)