[JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler commented on ARQ-1913:
-------------------------------------
This also happens in @BeforeClass on the client side when there is no container involved
{code}
10:37:32,977 WARN [org.jboss.as.arquillian.container.managed.ThreadContextClassloaderTest] (main) TCCL not null: sun.misc.Launcher$AppClassLoader@4aa298b7: java.lang.RuntimeException: TCCL not null: sun.misc.Launcher$AppClassLoader@4aa298b7
at org.jboss.as.arquillian.container.managed.ThreadContextClassloaderTest.assertNoTCCL(ThreadContextClassloaderTest.java:82)
at org.jboss.as.arquillian.container.managed.ThreadContextClassloaderTest.beforeClass(ThreadContextClassloaderTest.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:84)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:141)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:114)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:86)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}
> ARQ calls test methods with TCCL being set
> ------------------------------------------
>
> Key: ARQ-1913
> URL: https://issues.jboss.org/browse/ARQ-1913
> Project: Arquillian
> Issue Type: Bug
> Affects Versions: 1.1.6.Final
> Reporter: Thomas Diesler
>
> While integrating Camel in EAP I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
> Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
> IMHO, ARQ should stay out of the business of setting TCCL. Ideally it would even reset the TCCL to null before calling test code. This would provide a portable known base line across various containers.
> Related: https://github.com/wildfly-extras/wildfly-camel/issues/292
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler edited comment on ARQ-1913 at 2/9/15 7:59 AM:
-------------------------------------------------------------
This is a critical bug for us, because it effectively prevents meaningful Camel testing in WildFly.
was (Author: thomas.diesler):
This is a critical bug for us, because it effectively prevents meaningful Camel testing in WildFly. I see if I can provide a patch ...
> ARQ calls test methods with TCCL being set
> ------------------------------------------
>
> Key: ARQ-1913
> URL: https://issues.jboss.org/browse/ARQ-1913
> Project: Arquillian
> Issue Type: Bug
> Affects Versions: 1.1.6.Final
> Reporter: Thomas Diesler
>
> While integrating Camel in EAP I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
> Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
> IMHO, ARQ should stay out of the business of setting TCCL. Ideally it would even reset the TCCL to null before calling test code. This would provide a portable known base line across various containers.
> Related: https://github.com/wildfly-extras/wildfly-camel/issues/292
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated ARQ-1913:
--------------------------------
Description:
While integrating Camel in EAP I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
IMHO, ARQ should stay out of the business of setting TCCL. Ideally it would even reset the TCCL to null before calling test code. This would provide a portable known base line across various containers.
Related: https://github.com/wildfly-extras/wildfly-camel/issues/292
was:
While integrating Camel in EAP I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
IMHO, ARQ should stay out of the business of setting TCCL. Ideally it would even reset the TCCL to null before calling test code. This would provide a portable known base line across various containers.
> ARQ calls test methods with TCCL being set
> ------------------------------------------
>
> Key: ARQ-1913
> URL: https://issues.jboss.org/browse/ARQ-1913
> Project: Arquillian
> Issue Type: Bug
> Affects Versions: 1.1.6.Final
> Reporter: Thomas Diesler
>
> While integrating Camel in EAP I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
> Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
> IMHO, ARQ should stay out of the business of setting TCCL. Ideally it would even reset the TCCL to null before calling test code. This would provide a portable known base line across various containers.
> Related: https://github.com/wildfly-extras/wildfly-camel/issues/292
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler edited comment on ARQ-1913 at 2/9/15 7:54 AM:
-------------------------------------------------------------
This is a critical bug for us, because it effectively prevents meaningful Camel testing in WildFly. I see if I can provide a patch ...
was (Author: thomas.diesler):
This is a critical bug for us, because it effectively prevents meaningful Camel testing. I see if I can provide a patch ...
> ARQ calls test methods with TCCL being set
> ------------------------------------------
>
> Key: ARQ-1913
> URL: https://issues.jboss.org/browse/ARQ-1913
> Project: Arquillian
> Issue Type: Bug
> Affects Versions: 1.1.6.Final
> Reporter: Thomas Diesler
>
> While integrating Camel in EAP I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
> Camel happens to rely on TCCL, which is of questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
> IMHO, ARQ should stay out of the business of setting TCCL. Ideally it would even reset the TCCL to null before calling test code. This would provide a portable known base line across various containers.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler commented on ARQ-1913:
-------------------------------------
This is a critical bug for us, because it effectively prevents meaningful Camel testing. I see if I can provide a patch ...
> ARQ calls test methods with TCCL being set
> ------------------------------------------
>
> Key: ARQ-1913
> URL: https://issues.jboss.org/browse/ARQ-1913
> Project: Arquillian
> Issue Type: Bug
> Affects Versions: 1.1.6.Final
> Reporter: Thomas Diesler
>
> While integrating Camel in EAP I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
> Camel happens to rely on TCCL, which is of questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
> IMHO, ARQ should stay out of the business of setting TCCL. Ideally it would even reset the TCCL to null before calling test code. This would provide a portable known base line across various containers.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated ARQ-1913:
--------------------------------
Description:
While integrating Camel in EAP I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
IMHO, ARQ should stay out of the business of setting TCCL. Ideally it would even reset the TCCL to null before calling test code. This would provide a portable known base line across various containers.
was:
While integrating Camel in EAP I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
Camel happens to rely on TCCL, which is of questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
IMHO, ARQ should stay out of the business of setting TCCL. Ideally it would even reset the TCCL to null before calling test code. This would provide a portable known base line across various containers.
> ARQ calls test methods with TCCL being set
> ------------------------------------------
>
> Key: ARQ-1913
> URL: https://issues.jboss.org/browse/ARQ-1913
> Project: Arquillian
> Issue Type: Bug
> Affects Versions: 1.1.6.Final
> Reporter: Thomas Diesler
>
> While integrating Camel in EAP I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
> Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
> IMHO, ARQ should stay out of the business of setting TCCL. Ideally it would even reset the TCCL to null before calling test code. This would provide a portable known base line across various containers.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set
by Thomas Diesler (JIRA)
Thomas Diesler created ARQ-1913:
-----------------------------------
Summary: ARQ calls test methods with TCCL being set
Key: ARQ-1913
URL: https://issues.jboss.org/browse/ARQ-1913
Project: Arquillian
Issue Type: Bug
Affects Versions: 1.1.6.Final
Reporter: Thomas Diesler
While integrating Camel in EAP I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
Camel happens to rely on TCCL, which is of questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
IMHO, ARQ should stay out of the business of setting TCCL. Ideally it would even reset the TCCL to null before calling test code. This would provide a portable known base line across various containers.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month