February 2015 - arquillian-issues

[JBoss JIRA] (ARQ-791) JMX: Arquillian is unable to reconnect to JMX server if the connection is lost

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/ARQ-791?page=com.atlassian.jira.plugin.sy... ] Tomaz Cerar commented on ARQ-791: --------------------------------- I think this is obsolete now, and can be closed. Reload issue was addressed differently in wildfly testsuite itself. > JMX: Arquillian is unable to reconnect to JMX server if the connection is lost > ------------------------------------------------------------------------------ > > Key: ARQ-791 > URL: https://issues.jboss.org/browse/ARQ-791 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation > Affects Versions: 1.0.0.CR7 > Reporter: Dominik Pospisil > Assignee: Aslak Knutsen > Labels: arq_qe_blocker, ignored > > If the arq is running a testsuite using AS7 and JMX protocol and the connection to JMX MBean is lost, arq is unable to recover. > What I am trying to do is to run AS7 testsuite and let the specific test to reload server using reload management operation. Subsequent arquillian based tests are failing with the following exception: > org.jboss.remoting3.NotOpenException: Writes closed > at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107) > at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296) > at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177) > at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298) > at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65) > at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120) > at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:134) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57) > at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > 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.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > ... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1)

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen commented on ARQ-1914: ------------------------------------ What does your pom look like now? > Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) > ---------------------------------------------------------------------- > > Key: ARQ-1914 > URL: https://issues.jboss.org/browse/ARQ-1914 > Project: Arquillian > Issue Type: Bug > Components: GlassFish Containers > Affects Versions: 1.1.6.Final > Reporter: Constantin Weißer > > The arquillian glassfish embedded container (in the newest version 1.0.0.CR4) does simply ignore @Convert annotations (JPA 2.1) which leads to errors when running tests that use the persistence layer. > The error output contains > Internal Exception: Exception [EclipseLink-7155] (Eclipse Persistence Services - 2.2.0.v20110202-r8913) > which would explain, why it does not work. JPA 2.1 features are not implemented in EclipseLink 2.2.0. Why does arquillian-glassfish-embedded use such an outdated version of the persistence service? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1)

by Constantin Weißer (JIRA)

[ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.s... ] Constantin Weißer commented on ARQ-1914: ---------------------------------------- Sorry, but where do I set the glassfish version so that Arquillian "sees" it? > Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) > ---------------------------------------------------------------------- > > Key: ARQ-1914 > URL: https://issues.jboss.org/browse/ARQ-1914 > Project: Arquillian > Issue Type: Bug > Components: GlassFish Containers > Affects Versions: 1.1.6.Final > Reporter: Constantin Weißer > > The arquillian glassfish embedded container (in the newest version 1.0.0.CR4) does simply ignore @Convert annotations (JPA 2.1) which leads to errors when running tests that use the persistence layer. > The error output contains > Internal Exception: Exception [EclipseLink-7155] (Eclipse Persistence Services - 2.2.0.v20110202-r8913) > which would explain, why it does not work. JPA 2.1 features are not implemented in EclipseLink 2.2.0. Why does arquillian-glassfish-embedded use such an outdated version of the persistence service? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1)

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen commented on ARQ-1914: ------------------------------------ The Arquillian GlassFish Embedded container adapter doesn't contain/expose any GlassFish version by it self. You add the GlassFish dependency in your own POM, which means you control the GlassFish version it uses. The Adapter supports any version from 3.1 up to latest 4.x release. ? > Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) > ---------------------------------------------------------------------- > > Key: ARQ-1914 > URL: https://issues.jboss.org/browse/ARQ-1914 > Project: Arquillian > Issue Type: Bug > Components: GlassFish Containers > Affects Versions: 1.1.6.Final > Reporter: Constantin Weißer > > The arquillian glassfish embedded container (in the newest version 1.0.0.CR4) does simply ignore @Convert annotations (JPA 2.1) which leads to errors when running tests that use the persistence layer. > The error output contains > Internal Exception: Exception [EclipseLink-7155] (Eclipse Persistence Services - 2.2.0.v20110202-r8913) > which would explain, why it does not work. JPA 2.1 features are not implemented in EclipseLink 2.2.0. Why does arquillian-glassfish-embedded use such an outdated version of the persistence service? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1)

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen updated ARQ-1914: ------------------------------- Component/s: GlassFish Containers > Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) > ---------------------------------------------------------------------- > > Key: ARQ-1914 > URL: https://issues.jboss.org/browse/ARQ-1914 > Project: Arquillian > Issue Type: Bug > Components: GlassFish Containers > Affects Versions: 1.1.6.Final > Reporter: Constantin Weißer > > The arquillian glassfish embedded container (in the newest version 1.0.0.CR4) does simply ignore @Convert annotations (JPA 2.1) which leads to errors when running tests that use the persistence layer. > The error output contains > Internal Exception: Exception [EclipseLink-7155] (Eclipse Persistence Services - 2.2.0.v20110202-r8913) > which would explain, why it does not work. JPA 2.1 features are not implemented in EclipseLink 2.2.0. Why does arquillian-glassfish-embedded use such an outdated version of the persistence service? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1)

by Constantin Weißer (JIRA)

Constantin Weißer created ARQ-1914: -------------------------------------- Summary: Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) Key: ARQ-1914 URL: https://issues.jboss.org/browse/ARQ-1914 Project: Arquillian Issue Type: Bug Affects Versions: 1.1.6.Final Reporter: Constantin Weißer The arquillian glassfish embedded container (in the newest version 1.0.0.CR4) does simply ignore @Convert annotations (JPA 2.1) which leads to errors when running tests that use the persistence layer. The error output contains Internal Exception: Exception [EclipseLink-7155] (Eclipse Persistence Services - 2.2.0.v20110202-r8913) which would explain, why it does not work. JPA 2.1 features are not implemented in EclipseLink 2.2.0. Why does arquillian-glassfish-embedded use such an outdated version of the persistence service? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[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 closed ARQ-1913. ------------------------------- Resolution: Rejected ARQ does not set the TCCL. It should however work with the TCCL not being set. > 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

1
0
0 / 0

[JBoss JIRA] (ARQ-1879) Remove dependency on TCCL in JUnitBundleTestRunner

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/ARQ-1879?page=com.atlassian.jira.plugin.s... ] Thomas Diesler resolved ARQ-1879. --------------------------------- Resolution: Out of Date Out of Date > Remove dependency on TCCL in JUnitBundleTestRunner > -------------------------------------------------- > > Key: ARQ-1879 > URL: https://issues.jboss.org/browse/ARQ-1879 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Thomas Diesler > Assignee: Thomas Diesler > > Currently the JUnitBundleTestRunner uses code like this > {code} > public TestResult execute(Class<?> testClass, String methodName) { > ClassLoader ctxLoader = Thread.currentThread().getContextClassLoader(); > try { > // Make sure we run in the context of the arquillian-bundle class loader > Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); > return super.execute(testClass, methodName); > } finally { > Thread.currentThread().setContextClassLoader(ctxLoader); > } > } > {code} > This causes issues with APIs that use the TCCL for resource discovery. Investigate why the TCCL is used at all and whether the testClass CL could be used instead -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-1880) Arquillian core relies on TCCL to load infra

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/ARQ-1880?page=com.atlassian.jira.plugin.s... ] Thomas Diesler reassigned ARQ-1880: ----------------------------------- Assignee: Thomas Diesler > Arquillian core relies on TCCL to load infra > -------------------------------------------- > > Key: ARQ-1880 > URL: https://issues.jboss.org/browse/ARQ-1880 > Project: Arquillian > Issue Type: Bug > Affects Versions: 1.1.2.Final > Reporter: Thomas Diesler > Assignee: Thomas Diesler > > 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 > {code} > 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) > {code} > 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. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen commented on ARQ-1913: ------------------------------------ Sure, this happens by the JVM. {code} public class TCCL { public static void main(String[] args) { System.out.println(Thread.currentThread().getContextClassLoader()); } } {code} {code} sun.misc.Launcher$AppClassLoader@73d16e93 {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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues February 2015