November 2014 - arquillian-issues

[JBoss JIRA] (ARQ-1881) Fix starting/stopping of remote karaf container

by Martin Basovnik (JIRA)

[ https://issues.jboss.org/browse/ARQ-1881?page=com.atlassian.jira.plugin.s... ] Martin Basovnik updated ARQ-1881: --------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/36 > Fix starting/stopping of remote karaf container > ----------------------------------------------- > > Key: ARQ-1881 > URL: https://issues.jboss.org/browse/ARQ-1881 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Martin Basovnik > Assignee: Thomas Diesler > > Conditions to start and stop remote karaf container are not properly set. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1881) Fix starting/stopping of remote karaf container

by Martin Basovnik (JIRA)

Martin Basovnik created ARQ-1881: ------------------------------------ Summary: Fix starting/stopping of remote karaf container Key: ARQ-1881 URL: https://issues.jboss.org/browse/ARQ-1881 Project: Arquillian Issue Type: Bug Components: OSGi Containers Reporter: Martin Basovnik Assignee: Thomas Diesler Conditions to start and stop remote karaf container are not properly set. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 6 months

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 updated ARQ-1880: -------------------------------- Component/s: (was: Runtime Enricher SPI) > 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 > > 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.8#6338)

9 years, 6 months

1
0
0 / 0

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

by Thomas Diesler (JIRA)

Thomas Diesler created ARQ-1880: ----------------------------------- Summary: Arquillian core relies on TCCL to load infra Key: ARQ-1880 URL: https://issues.jboss.org/browse/ARQ-1880 Project: Arquillian Issue Type: Bug Components: Runtime Enricher SPI Affects Versions: 1.1.2.Final Reporter: 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.8#6338)

9 years, 6 months

1
0
0 / 0

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

by Thomas Diesler (JIRA)

Thomas Diesler created ARQ-1879: ----------------------------------- Summary: 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.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1878) Introduce TableEntry

by Stefan Miklosovic (JIRA)

Stefan Miklosovic created ARQ-1878: -------------------------------------- Summary: Introduce TableEntry Key: ARQ-1878 URL: https://issues.jboss.org/browse/ARQ-1878 Project: Arquillian Issue Type: Enhancement Components: Extension - Recorder Affects Versions: recorder_1.0.0.Beta1 Reporter: Stefan Miklosovic Priority: Optional TableEntry should have header, rows and cells. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1877) PropertyEntry.getProperties doesn't seem to be rendered recursivly

by Stefan Miklosovic (JIRA)

Stefan Miklosovic created ARQ-1877: -------------------------------------- Summary: PropertyEntry.getProperties doesn't seem to be rendered recursivly Key: ARQ-1877 URL: https://issues.jboss.org/browse/ARQ-1877 Project: Arquillian Issue Type: Bug Components: Extension - Recorder Affects Versions: recorder_1.0.0.Beta1 Reporter: Stefan Miklosovic -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1876) Investigate collapsable entries

by Stefan Miklosovic (JIRA)

Stefan Miklosovic created ARQ-1876: -------------------------------------- Summary: Investigate collapsable entries Key: ARQ-1876 URL: https://issues.jboss.org/browse/ARQ-1876 Project: Arquillian Issue Type: Feature Request Components: Extension - Recorder Affects Versions: recorder_1.0.0.Beta1 Reporter: Stefan Miklosovic Priority: Optional Only long exception stacks are done collapsable, try to do it on entry level in general. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1875) JaCoCo extension only works for simple use cases

by John Ament (JIRA)

[ https://issues.jboss.org/browse/ARQ-1875?page=com.atlassian.jira.plugin.s... ] John Ament updated ARQ-1875: ---------------------------- Status: Open (was: Pull Request Sent) > JaCoCo extension only works for simple use cases > ------------------------------------------------ > > Key: ARQ-1875 > URL: https://issues.jboss.org/browse/ARQ-1875 > Project: Arquillian > Issue Type: Bug > Components: Extension - Jacoco > Affects Versions: jacoco_1.0.0.Alpha7 > Reporter: John Ament > > In JaCoCo Alpha 7, the tests pass on the build, however the extension itself only works if you have a very small use case. If you have a more robust test that uses database connections, external modules, you get ASM conflicts. > Here's an example output: > {quote} > Caused by: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel(org.objectweb.asm.Label) > at java.lang.Class.getMethod(Class.java:1773) [rt.jar:1.8.0_20] > at org.apache.cxf.common.util.ReflectionInvokationHandler.invoke(ReflectionInvokationHandler.java:85) > ... 28 more > 13:34:21,040 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "api-webapp.war")]) - failure description: { > "JBAS014671: Failed services" => {"jboss.deployment.unit.\"api-webapp.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"api-webapp.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"api-webapp.war\" > Caused by: javax.xml.ws.WebServiceException: java.lang.reflect.UndeclaredThrowableException > Caused by: java.lang.reflect.UndeclaredThrowableException > Caused by: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel(org.objectweb.asm.Label)"}, > "JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"api-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"api-webapp.war\".beanmanager]"] > {quote} > My jboss-deployment-structure.xml looks like this: > {code} > <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1"> >  > <deployment> > <exclusions> > <module name="org.jboss.resteasy.resteasy-jackson2-provider"/> > </exclusions> > <dependencies> > <module name="com.private" services="import"/> > <module name="org.bouncycastle" services="import"/> > <module name="org.picketlink" services="import"/> > <module name="org.apache.james.mime4j" services="import"/> > <module name="org.hibernate.validator" services="import"/> > <module name="org.hibernate.validator.cdi" services="import"/> > <module name="org.hibernate" services="import"/> > <module name="org.javassist" services="import"/> > <module name="org.apache.commons.http" services="import"/> > <module name="org.apache.commons.email" services="import"/> > <module name="org.apache.commons.lang" services="import"/> > <module name="org.apache.commons.codec" services="import"/> > <module name="org.apache.commons.io" services="import"/> > <module name="org.apache.xerces" services="import"/> > <module name="org.apache.tika" services="import"/> > <module name="org.json" services="import"/> > <module name="org.apache.velocity" services="import"/> > <module name="org.apache.httpcomponents" services="import"/> > <module name="org.apache.log4j" services="import"/> > <module name="org.jboss.logmanager" services="import"/> > <module name="com.google.guava" services="import"/> > <module name="org.codehaus.jackson.jackson-mapper-asl" services="import"/> > <module name="org.codehaus.jackson.jackson-jaxrs" services="import"/> > <module name="org.bouncycastle.bcpg" services="import"/> > <module name="org.jboss.resteasy.resteasy-jackson-provider" services="import"/> > <module name="org.jboss.resteasy.resteasy-multipart-provider" services="import"/> > <module name="org.quartzscheduler" services="import"/> > <module name="org.joda.time" services="import"/> > <module name="org.codehaus.jackson.jackson-core-asl" services="import" /> >  > <module name="org.apache.cxf" services="import"/> > <module name="org.apache.cxf.impl" services="import"/> > <module name="org.picketlink"/> > <module name="org.picketbox"/> > <module name="javax.security.auth.message.api" /> > <module name="javax.security.jacc.api" /> > <module name="org.apache.ws.security"/> > <module name="org.elasticsearch" services="import" meta-inf="import"/> > <module name="org.camunda"/> > </dependencies> > </deployment> > </jboss-deployment-structure> > {code} > Some of these are custom modules, usually just wrapping open source libraries. There's one private one I hid, but it doesn't have any ASM. It seems like hibernate's the culprit here. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1875) JaCoCo extension only works for simple use cases

by Leonardo Loch Zanivan (JIRA)

[ https://issues.jboss.org/browse/ARQ-1875?page=com.atlassian.jira.plugin.s... ] Leonardo Loch Zanivan commented on ARQ-1875: -------------------------------------------- I'm using Arquillian JaCoCo 1.0.0.Alpha7 with JDK 8u20 and WildFly 8.1.0.Final in a couple of web apps and I didn't had any issue. They're Java EE 7 web apps which uses JAX-RS, EJB, JPA, but no WS. IMHO I think it's a WildFly component issue, it's supposed to run with Java 8 and will cause other compatibility issues with libraries which requires ASM 5+. > JaCoCo extension only works for simple use cases > ------------------------------------------------ > > Key: ARQ-1875 > URL: https://issues.jboss.org/browse/ARQ-1875 > Project: Arquillian > Issue Type: Bug > Components: Extension - Jacoco > Affects Versions: jacoco_1.0.0.Alpha7 > Reporter: John Ament > > In JaCoCo Alpha 7, the tests pass on the build, however the extension itself only works if you have a very small use case. If you have a more robust test that uses database connections, external modules, you get ASM conflicts. > Here's an example output: > {quote} > Caused by: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel(org.objectweb.asm.Label) > at java.lang.Class.getMethod(Class.java:1773) [rt.jar:1.8.0_20] > at org.apache.cxf.common.util.ReflectionInvokationHandler.invoke(ReflectionInvokationHandler.java:85) > ... 28 more > 13:34:21,040 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "api-webapp.war")]) - failure description: { > "JBAS014671: Failed services" => {"jboss.deployment.unit.\"api-webapp.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"api-webapp.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"api-webapp.war\" > Caused by: javax.xml.ws.WebServiceException: java.lang.reflect.UndeclaredThrowableException > Caused by: java.lang.reflect.UndeclaredThrowableException > Caused by: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel(org.objectweb.asm.Label)"}, > "JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"api-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"api-webapp.war\".beanmanager]"] > {quote} > My jboss-deployment-structure.xml looks like this: > {code} > <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1"> >  > <deployment> > <exclusions> > <module name="org.jboss.resteasy.resteasy-jackson2-provider"/> > </exclusions> > <dependencies> > <module name="com.private" services="import"/> > <module name="org.bouncycastle" services="import"/> > <module name="org.picketlink" services="import"/> > <module name="org.apache.james.mime4j" services="import"/> > <module name="org.hibernate.validator" services="import"/> > <module name="org.hibernate.validator.cdi" services="import"/> > <module name="org.hibernate" services="import"/> > <module name="org.javassist" services="import"/> > <module name="org.apache.commons.http" services="import"/> > <module name="org.apache.commons.email" services="import"/> > <module name="org.apache.commons.lang" services="import"/> > <module name="org.apache.commons.codec" services="import"/> > <module name="org.apache.commons.io" services="import"/> > <module name="org.apache.xerces" services="import"/> > <module name="org.apache.tika" services="import"/> > <module name="org.json" services="import"/> > <module name="org.apache.velocity" services="import"/> > <module name="org.apache.httpcomponents" services="import"/> > <module name="org.apache.log4j" services="import"/> > <module name="org.jboss.logmanager" services="import"/> > <module name="com.google.guava" services="import"/> > <module name="org.codehaus.jackson.jackson-mapper-asl" services="import"/> > <module name="org.codehaus.jackson.jackson-jaxrs" services="import"/> > <module name="org.bouncycastle.bcpg" services="import"/> > <module name="org.jboss.resteasy.resteasy-jackson-provider" services="import"/> > <module name="org.jboss.resteasy.resteasy-multipart-provider" services="import"/> > <module name="org.quartzscheduler" services="import"/> > <module name="org.joda.time" services="import"/> > <module name="org.codehaus.jackson.jackson-core-asl" services="import" /> >  > <module name="org.apache.cxf" services="import"/> > <module name="org.apache.cxf.impl" services="import"/> > <module name="org.picketlink"/> > <module name="org.picketbox"/> > <module name="javax.security.auth.message.api" /> > <module name="javax.security.jacc.api" /> > <module name="org.apache.ws.security"/> > <module name="org.elasticsearch" services="import" meta-inf="import"/> > <module name="org.camunda"/> > </dependencies> > </deployment> > </jboss-deployment-structure> > {code} > Some of these are custom modules, usually just wrapping open source libraries. There's one private one I hid, but it doesn't have any ASM. It seems like hibernate's the culprit here. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues November 2014