-
Bug
-
Resolution: Done
-
Major
-
1.1.2.Final
-
None
-
None
While testing FSW product stuff it turns out that test code is executed with a TCCL from the ARQ bundle. If ARQ does not set a TCCL we get
Caused by: java.lang.ClassNotFoundException: org/jboss/arquillian/test/impl/EventTestRunnerAdaptor at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:270) at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:105) at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:97) at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:52) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:93) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at org.junit.runner.JUnitCore.run(JUnitCore.java:138) at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65) at org.jboss.arquillian.osgi.JUnitBundleTestRunner.execute(JUnitBundleTestRunner.java:34)
Having a TCCL set is highly problematic in OSGi because it bypasses al user defined wiring rules. When test code calls into API that uses TCCL, that API will try to load types from the ARQ Bundle classloader, which of course has no visibility to the requested types/resources.
The ARQ infra should ideally not have to depend on TCCL for loading its own types. Second best would be to reset the TCCL after all infra stuff is done and before the call into the test case.
The TCCL association is part of the public API. From the perspective of the test case, it needs to be defined and ideally be guaranteed to be null.