[
https://issues.apache.org/jira/browse/OAK-10610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808552#comment-17808552
]
Julian Sedding commented on OAK-10610:
--------------------------------------
As discussed privately, the issue is with mock-osgi.
At the end of the test it unregisters all services. While unregistereing the
component {{SplitPersistenceService}}, it calls its deactivate method, where
the {{SplitPersistence}} service is manually unregistered. Because
{{SplitPersistence}} is registered as a {{SegmentNodeStorePersistence}},
mock-osgi tries to find all references to this service, in order to deactivate
any referents. The {{SplitPersistenceService}} component has two references to
{{SegmentNodeStorePersistence}} and thus mock-osgi tries to deactivate it.
# Multiple things are wrong with this:
# when determining referents, it should check that the service object matches
# when determining referents, it should consider a refernce's target filter
# it should probably keep track of components it is already deactivating in
order to prevent this sort of cycle, I suppose it could throw an exception in
that case.
cc [~sseifert]
> Adding OSGi wiring test for SplitPersistenceService is failing
> --------------------------------------------------------------
>
> Key: OAK-10610
> URL: https://issues.apache.org/jira/browse/OAK-10610
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: osgi, segment-tar
> Reporter: Andrei Dulceanu
> Priority: Minor
> Attachments: SplitPersistenceServiceTest.patch
>
>
> While running the test in the patch attached, I always get:
> {noformat}
> java.lang.RuntimeException: Unable to invoke method 'deactivate' for class
> org.apache.jackrabbit.oak.segment.osgi.SplitPersistenceService
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeMethod(OsgiServiceUtil.java:325)
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeLifecycleMethod(OsgiServiceUtil.java:225)
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:89)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:231)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.shutdown(MockBundleContext.java:449)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.shutdown(MockOsgi.java:330)
> at
> org.apache.sling.testing.mock.osgi.context.OsgiContextImpl.tearDown(OsgiContextImpl.java:58)
> at
> org.apache.sling.testing.mock.osgi.junit.OsgiContext.access$200(OsgiContext.java:35)
> at
> org.apache.sling.testing.mock.osgi.junit.OsgiContext$1.after(OsgiContext.java:86)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:59)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at
> org.junit.runners.ParentRunner$<...>.invokeLifecycleMethod(OsgiServiceUtil.java:225)
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:89)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:231)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:218)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.restartService(MockBundleContext.java:202)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.handleRefsUpdateOnUnregister(MockBundleContext.java:259)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.unregisterService(MockBundleContext.java:191)
> at
> org.apache.sling.testing.mock.osgi.MockServiceRegistration.unregister(MockServiceRegistration.java:100)
> at
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard$1.unregister(OsgiWhiteboard.java:87)
> at
> org.apache.jackrabbit.oak.segment.osgi.SplitPersistenceService.deactivate(SplitPersistenceService.java:70)
> at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> {noformat}
> The problem is that there is a {{StackOverflowException}} being thrown when
> calling {{deactivate()}}. This might stem from the fact that
> {{SplitPersistenceService}} has a reference to the same type it tries to
> register, but this is only an assumption.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
