You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Arnoud Glimmerveen (JIRA)" <ji...@apache.org> on 2019/07/15 21:14:00 UTC
[jira] [Commented] (FELIX-6161) SCR: Method of resolving references
limits Service ListenerHook implementations
[ https://issues.apache.org/jira/browse/FELIX-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16885627#comment-16885627 ]
Arnoud Glimmerveen commented on FELIX-6161:
-------------------------------------------
I have made an attempt to address the observed problem (see [^FELIX-6161.patch]). Main change is that filtering happens by the service registry, rather than inside the ServiceListener.
All tests pass on my machine, and solves the issue that I observed.
Looking at the history I found that the approach to filtering inside the listener was introduced when fixing FELIX-4964. Looking at that original problem description I think my changes should continue to address that use case as well, but I am not entirely sure. Is this something perhaps [~djencks] could look in to?
> 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)