[
https://issues.apache.org/jira/browse/SLING-13146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18069643#comment-18069643
]
Stefan Seifert commented on SLING-13146:
----------------------------------------
hmm - the ThreadsafeMockAdapterManagerWrapper exists to make it possible to run
junit tests in parallel - assuming that each test runs exclusively in a single
thread. in your case, child threads are spawned, and they don't get the correct
thread context passed on.
the issue you describe is directly related to SLING-13003, PR
[https://github.com/apache/sling-org-apache-sling-testing-sling-mock/pull/54] -
if you revert this change, your test case is actually working.
but we should not simply revert that change - it's there for a reason, as i
observed a lot of flaky behavior in larger projects (e.g. wcm.io media handler)
with unit tests failing from time to time (esp. in Github Actions), and also
when using junit in parallel mode. but maybe the fix should be implemented
differently.
before playing around with this, please check if reverting the change from that
PR locally on your side also fixes the problem you observed with the resource
change listener implementation, with the threads spawned by oak.
> ThreadsafeMockAdapterManagerWrapper: Adapters from test class cannot be found
> -----------------------------------------------------------------------------
>
> Key: SLING-13146
> URL: https://issues.apache.org/jira/browse/SLING-13146
> Project: Sling
> Issue Type: Improvement
> Components: Testing
> Affects Versions: Testing Sling Mock 4.0.0, Testing Sling Mock 4.0.2,
> Testing Sling Mock 3.6.0, Testing Sling Mock 4.0.4
> Reporter: Henry Kuijpers
> Priority: Major
>
> When testing an OSGi service with ResourceResolverType=JCR_OAK, that is (for
> example) a ResourceChangeListener, the following could occur:
> # Test class registers an adapter
> # onChange gets triggered on a different thread, which causes:
> [pool-6-thread-1] WARN
> org.apache.sling.testing.mock.sling.ThreadsafeMockAdapterManagerWrapper -
> Create new bundle context for adapter manager because it was null,
> bundleContext=null
> # The adapterfactories are not there in this new AdapterManager
> # The adaptTo-call returns null
> # When manually triggering the onChange-method from the test, the
> adaptTo-call works, as it uses a different AdapterManager that *does* have
> the adapterfactory
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
