[jira] [Resolved] (SLING-4756) ServiceListener notifications are not filtered

["Robert Munteanu (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Munteanu resolved SLING-4756.
------------------------------------
    Resolution: Fixed

This is now fixed based on the issue description. This might not be 100% backwards compatible with how the OSGi mocks behaved since ServiceListeners registered with a filter which were previously (incorrectly) invoked are no longer invoked, but the behavior should be correct.

Maybe it's worth discussing if when encountering an unsupported filter specification we should simply fail hard with an exception instead of ignoring it, like it does now.

> ServiceListener notifications are not filtered
> ----------------------------------------------
>
>                 Key: SLING-4756
>                 URL: https://issues.apache.org/jira/browse/SLING-4756
>             Project: Sling
>          Issue Type: Bug
>          Components: Testing
>    Affects Versions: Testing OSGi Mock 1.3.0
>            Reporter: Robert Munteanu
>            Assignee: Robert Munteanu
>             Fix For: Testing OSGi Mock 1.3.2
>
>
> While working on SLING-4605 I noticed many ClassCastExceptions filling the logs ( see below ). Similar exceptions are also present for the mock-jackrabbit module, only less verbose ( not stack traces )
> {noformat}
> 5432 [oak-executor-1] WARN org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor - Error while dispatching observation events for ///*[11111b]@org.apache.sling.jcr.resource.internal.JcrResourceListener
> java.lang.ClassCastException: org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider cannot be cast to org.osgi.service.event.EventAdmin
>         at org.apache.sling.jcr.resource.internal.JcrResourceListener.onEvent(JcrResourceListener.java:173)
>         at org.apache.jackrabbit.commons.observation.ListenerTracker$1.onEvent(ListenerTracker.java:164)
>         at org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.contentChanged(ChangeProcessor.java:302)
>         at org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:125)
>         at org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:119)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745){noformat}
> The root cause is that when registering a {{ServiceTracker}} for a given class name the service tracker receives all registered services after it has been instantiated. The fix is the following
> - when registering a service the mandatory {{objectClass}} property must be set for the {{ServiceReference}}'s properties
> - implement simple filtering based on the {{objectClass}} parameter in {{MockBundleContext}}
> - notify only interested {{ServiceListener}} instances based on the filter they are registered with



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)