cmrockwell commented on a change in pull request #5:
URL:
https://github.com/apache/sling-org-apache-sling-junit-core/pull/5#discussion_r534469447
##########
File path:
src/main/java/org/apache/sling/junit/annotations/SlingAnnotationsTestRunner.java
##########
@@ -54,19 +60,23 @@ protected Object createTest() throws Exception {
return super.createTest();
} else {
log.debug("Using TestObjectProcessor {}", top);
- return top.process(super.createTest());
+ Object test = top.process(super.createTest());
+ tests.add(test);
Review comment:
I had a similar assumption that a single `test` object field might be
sufficient. But I found keeping list is necessary.
The IT test `TestReferenceJITest.java` has 4 methods marked as @Test. Each
test gets it's own references to the services provided by the @TestReference
annotation; providing each test with 5 such service references in this example.
Thus each test results in an entry to the AnnotationsProcessor map, `ap.map`
where value of each is a List of 5 ServiceGetters. You had mentioned that
`AnnotationsProcessor` is service and therefore a singleton. Using debugging
methods, when paused execution in the SlingAnnotationsTestRunner finally block,
I saw that `ap.map` had entries for 4 entries (corresponding to the 4 methods
marked with @Test). Each entry had a list of 5 ServiceGetters. When
SlingAnnotationsTestRunner only had the single {Object} `test` reference, it
seemed to be just the last test executed and therefore would not unget service
references for the prior tests. On subsequent runs, `ap.map` would net more
entries. Keeping the `tests` in a list allowed the runner to cleanup for eac
h test that it ran.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
