[
https://issues.apache.org/jira/browse/SLING-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14561108#comment-14561108
]
Robert Munteanu commented on SLING-4756:
----------------------------------------
Another option is to rebase the OSGi mocks on top of [Apache Felix
Connect|https://svn.apache.org/repos/asf/felix/trunk/connect/] ( formerly
[PojoSR|https://code.google.com/p/pojosr/] ) , but I'm not sure if that will
what we want and keep the project lightweight.
> 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)
