[
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)
