[
https://issues.apache.org/jira/browse/SLING-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422686#comment-15422686
]
Stefan Seifert commented on SLING-5967:
---------------------------------------
imho this cannot be changed.
the current implementation set a special implementation of adapter manager only
once to support parallel runs of unit tests. in this case multiple threads
access the same static adapter manager methods. the special mock-implementation
of adapt manager handles this by using thread locals with a different set of
registered adapters for each unit test run making sure they do not interfere
with each other.
the only thing we can improve is the documentation to make sure no unit tests
tries to set it's own adapter manager.
> MockSling calls SlingAdaptable.setAdaperManager in static initializer and
> prevents other test from overwriting the adapter manager
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-5967
> URL: https://issues.apache.org/jira/browse/SLING-5967
> Project: Sling
> Issue Type: Improvement
> Components: Testing
> Affects Versions: Testing Sling Mock 2.0.0
> Reporter: Konrad Windszus
>
> Currently {{MockSling}} calls {{SlingAdaptable.setAdapterManager(...)}} in a
> static initializer
> (https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/src/main/java/org/apache/sling/testing/mock/sling/MockSling.java#L47).
> That leads to NPEs in case some other test classes have called
> {{SlingAdaptable.setAdapterManager()}} as well.
> The problem occurs in the following execution order of tests being executed
> within the same Java process:
> 1. a test leveraging SlingContext (which will trigger the static initializer
> in {{MockSling}}
> 2. a test calling {{SlingAdaptable.setAdapterManager()}} (and of course
> {{SlingAdaptable.unsetAdapterManager()}} after the test has been executed)
> 3. another test using SlingContext
> Here it breaks, because MockSling never tries to set its {{AdapterManager}}
> again.
> IMHO the code should be refactored, so that for {{SlingContext}} the
> AdapterManager is registered when it is setup and unregistered when it is no
> longer in use. In addition there should be a hint in the javadoc of
> SlingContext mentioning that {{SlingAdaptable.setAdapterManager(...)}} must
> not be called in tests leveraging {{SlingContext}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
