[
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/[email protected]/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/[email protected]/msg48657.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
