[
https://issues.apache.org/jira/browse/SLING-13146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18069692#comment-18069692
]
Henry Kuijpers commented on SLING-13146:
----------------------------------------
Yes, reverting that change makes it work again. I forgot to mention that this
issue is present only in newer versions that contain that change.
I agree that it's probably not a good idea to just revert the change, but I
think it should be possible to either turn on/off this behaviour, or be able to
influence it in another way somehow.
In the example test I provided, I showed the problem. What I couldn't do was
use JCR_OAK, as the correct dependencies were not loaded. When a
ResourceChangeListener's onChange is triggered in JCR_OAK, there is no
influence on the thread on which it is executed, which means the calls will
always be executed (outside the control of the unit test) and with an empty
adapter manager.
> 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)
