[jira] [Commented] (SLING-5967) MockSling calls SlingAdaptable.setAdaperManager in static initializer and prevents other test from overwriting the adapter manager

["Stefan Seifert (JIRA)" <ji...@apache.org>]

    [ 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)