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)