You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Konrad Windszus (JIRA)" <ji...@apache.org> on 2016/08/16 12:39:22 UTC

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

Konrad Windszus created SLING-5967:
--------------------------------------

             Summary: 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)