From issues at jboss.org Sun Feb 1 07:50:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:50:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1528) Be able to start multiple Android containers simultaneously in one test run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1528: ----------------------------------- Fix Version/s: droidium_1.0.0.Alpha6 (was: droidium_1.0.0.Beta1) > Be able to start multiple Android containers simultaneously in one test run > --------------------------------------------------------------------------- > > Key: ARQ-1528 > URL: https://issues.jboss.org/browse/ARQ-1528 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Priority: Blocker > Fix For: droidium_1.0.0.Alpha6 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:50:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:50:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1536) Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1536: ----------------------------------- Fix Version/s: droidium_1.0.0.Alpha6 (was: droidium_1.0.0.Beta1) > Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so > ---------------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1536 > URL: https://issues.jboss.org/browse/ARQ-1536 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha2 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > Instead of starting activity every time in test method manually, it would be nice to have this possibility: > {code} > @Test > @InSequence(4) > @OperateOnDeployment("todo-mobile-app") > public void loginUserInMobile(@ArquillianResource AndroidDevice device) { > device.getActivityManagerProvider() > .getActivityManager() > .startActivity("org.jboss.aerogear.todo.activities.LoginActivity"); > loginMobileFragment.login("john", "123"); > } > ========================= > @Test > @InSequence(4) > @OperateOnDeployment("todo-mobile-app") > @StartActivity("org.jboss.aerogear.todo.activities.LoginActivity") > public void loginUserInMobile() { > loginMobileFragment.login("john", "123"); > } > {code} > However, with the possibility to have Graphene page fragments, it would be teoretically possible to have propper page objects as well which mean that we could abstract activity into @Page and specify its @Location("activityName") > The problem is, how this translates to Graphene since Droidium starts activities in this manner: > driver.get("and-activity://" + activityName); > There is the need to take that "and-activity" string into consideration with @Location annotation. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:50:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:50:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1557) Align undeployment logic in a proper Arquillian way In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1557: ----------------------------------- Fix Version/s: droidium_1.0.0.Alpha6 (was: droidium_1.0.0.Beta1) > Align undeployment logic in a proper Arquillian way > --------------------------------------------------- > > Key: ARQ-1557 > URL: https://issues.jboss.org/browse/ARQ-1557 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha2 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > Attachments: brainstorming.jpg > > > Right now, undeployment logic for Droidium is bound to observer which observes with precedence -100 on AfterClass event in order to be sure that this observer will be treated as the latest one. > Right now, we have to be sure that undeployment logic is treated lastly in AfterClass since Arquillian Drone destroys WebDriver instances in AfterClass as well and the destruction of WebDriver instance, in our case, means that Selendroid server will be uninstalled from Android device. > Since the destruction of WebDriver instance itself is executed randomly in AfterClass regarding of execution time, we can not do undeployment of APKs on UnDeployDeployment event because when doing so, uninstallation of instrumented APK automatically kills Selendroid server process as well so that in turn means that subsequent trying to destroy WebDriver instance fails since Selendroid server is not running anymore and Drone talks to nobody. > To be sure that all Selendroid servers are uninstalled so we can proceed with the uninstallation of deployments, where it should be done, there has to be a guarantee that all WebDriver instances were already destroyed. > The solution here seems to be quite simple - we put some positive precedence for DroneDestructor (1) however by doing so, it could cause some backward compatibility issues with Drone extension. > (1) https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl/DroneDestructor.java#L69 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:50:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:50:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1613) Allow Android Shell command timeouts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1613: ----------------------------------- Fix Version/s: droidium_1.0.0.Alpha6 (was: droidium_1.0.0.Beta1) > Allow Android Shell command timeouts > ------------------------------------ > > Key: ARQ-1613 > URL: https://issues.jboss.org/browse/ARQ-1613 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha3 > Reporter: Karel Piwko > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > It would be handy, if Droidium can setup timeout for DDMS related operations, such as executing a shell commands. > It looks like it should be possible with: > {code} > DdmPreferences.setTimeOut(timeout); > {code} > By default, timeout is set to 5 seconds, which might be not enough when running in emulated env. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:51:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:51:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1658) Wrong isInstance check prevents usage of new/custom container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1658: ----------------------------------- Fix Version/s: droidium_1.0.0.Alpha6 (was: droidium_1.0.0.Beta1) > Wrong isInstance check prevents usage of new/custom container > -------------------------------------------------------------- > > Key: ARQ-1658 > URL: https://issues.jboss.org/browse/ARQ-1658 > Project: Arquillian > Issue Type: Bug > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha4 > Reporter: Thorben Janssen > Fix For: droidium_1.0.0.Alpha6 > > > If the container configuration contains an unknown qualifier, MultipleContainerRegistryCreator tries to the adapterImplClass class and checks if it implements DeploableContainer. > The current check with isInstance() returns always. The isAssignableFrom() method has to be used instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:51:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:51:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1704) Implement replacement for AndroidDriver dropped in Selenium 2.40 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1704: ----------------------------------- Fix Version/s: droidium_1.0.0.Alpha6 (was: droidium_1.0.0.Beta1) > Implement replacement for AndroidDriver dropped in Selenium 2.40 > ---------------------------------------------------------------- > > Key: ARQ-1704 > URL: https://issues.jboss.org/browse/ARQ-1704 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha4 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > Drone 1.3.0.Final will depend on Selenium 2.40 where AndroidDriver is dropped hence support is dropped from Drone as well. > Implement Android-like driver directly in Droidium as a replacement. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:51:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:51:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1718) Simple way to test on real device without the need to use serial id In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1718: ----------------------------------- Fix Version/s: droidium_1.0.0.Alpha6 (was: droidium_1.0.0.Beta1) > Simple way to test on real device without the need to use serial id > ------------------------------------------------------------------- > > Key: ARQ-1718 > URL: https://issues.jboss.org/browse/ARQ-1718 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Reporter: Tadeas Kriz > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > There should be a way to simply test on device, without the need to use serial id, if only one device is connected. Adb has this functionality (if only one device (real or emulated) is connected, it uses it, or with -d switch to use real device (-e for emulated one)). Droidium should also allow this and quit with error if no serial id is specified, but more devices are connected. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:51:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:51:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1763) Download boilerplate APKs for Droidium by Spacelift In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1763: ----------------------------------- Fix Version/s: droidium_1.0.0.Alpha6 (was: droidium_1.0.0.Beta1) > Download boilerplate APKs for Droidium by Spacelift > --------------------------------------------------- > > Key: ARQ-1763 > URL: https://issues.jboss.org/browse/ARQ-1763 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha5 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > Ftesting with Droidium native plugin requires selendroid-server.apk from Selendroid project. Web testing requires android-driver.apk from same project. > Right now, these apks need to be downloaded manually by user so he has to find it on the net and manually setup it in arq.xml. As this is not desired, Spacelift 1.0.0.Alpha2 can download these artifacts automatically and they can be downloaded to target/ when it is not found so user does not have to do a thing. > https://gist.github.com/kpiwko/10738725 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:51:50 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:51:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1824) Support Google Inc.:Google APIs (x86 System Image):19 format In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1824: ----------------------------------- Fix Version/s: droidium_1.0.0.Alpha6 (was: droidium_1.0.0.Beta1) > Support Google Inc.:Google APIs (x86 System Image):19 format > ------------------------------------------------------------ > > Key: ARQ-1824 > URL: https://issues.jboss.org/browse/ARQ-1824 > Project: Arquillian > Issue Type: Bug > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha5 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: droidium_1.0.0.Alpha6 > > > With new version format in Android SDK, we need to alter parsing options to support '()' in target format. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:52:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:52:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1885) Droidium is not buildable with Java 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1885: ----------------------------------- Fix Version/s: droidium_1.0.0.Alpha6 (was: droidium_1.0.0.Beta1) > Droidium is not buildable with Java 8 > ------------------------------------- > > Key: ARQ-1885 > URL: https://issues.jboss.org/browse/ARQ-1885 > Project: Arquillian > Issue Type: Bug > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Beta1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > {code} > ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (signature-check) on project arquillian-droidium-container: Execution signature-check of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed. IllegalArgumentException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (signature-check) on project arquillian-droidium-container: Execution signature-check of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed. > ... > Caused by: java.lang.IllegalArgumentException > at org.objectweb.asm.ClassReader.(Unknown Source) > at org.objectweb.asm.ClassReader.(Unknown Source) > at org.objectweb.asm.ClassReader.(Unknown Source) > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:52:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:52:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1895) Implement video recorder for Droidium In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1895: ----------------------------------- Fix Version/s: droidium_1.0.0.Alpha6 (was: droidium_1.0.0.Beta1) > Implement video recorder for Droidium > ------------------------------------- > > Key: ARQ-1895 > URL: https://issues.jboss.org/browse/ARQ-1895 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha5 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > Implement recorder for Droidium based on video API of Arquillian Video Recorder. > The goal of this implementation is to record videos of Android phone itself via screenrecorder API in ddmlib since ddms 24.0.0 - aplicable for Android API 19+. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:53:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:53:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1528) Be able to start multiple Android containers simultaneously in one test run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1528. ---------------------------------- > Be able to start multiple Android containers simultaneously in one test run > --------------------------------------------------------------------------- > > Key: ARQ-1528 > URL: https://issues.jboss.org/browse/ARQ-1528 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Priority: Blocker > Fix For: droidium_1.0.0.Alpha6 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:53:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:53:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1536) Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1536. ---------------------------------- > Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so > ---------------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1536 > URL: https://issues.jboss.org/browse/ARQ-1536 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha2 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > Instead of starting activity every time in test method manually, it would be nice to have this possibility: > {code} > @Test > @InSequence(4) > @OperateOnDeployment("todo-mobile-app") > public void loginUserInMobile(@ArquillianResource AndroidDevice device) { > device.getActivityManagerProvider() > .getActivityManager() > .startActivity("org.jboss.aerogear.todo.activities.LoginActivity"); > loginMobileFragment.login("john", "123"); > } > ========================= > @Test > @InSequence(4) > @OperateOnDeployment("todo-mobile-app") > @StartActivity("org.jboss.aerogear.todo.activities.LoginActivity") > public void loginUserInMobile() { > loginMobileFragment.login("john", "123"); > } > {code} > However, with the possibility to have Graphene page fragments, it would be teoretically possible to have propper page objects as well which mean that we could abstract activity into @Page and specify its @Location("activityName") > The problem is, how this translates to Graphene since Droidium starts activities in this manner: > driver.get("and-activity://" + activityName); > There is the need to take that "and-activity" string into consideration with @Location annotation. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:53:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:53:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1557) Align undeployment logic in a proper Arquillian way In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1557. ---------------------------------- > Align undeployment logic in a proper Arquillian way > --------------------------------------------------- > > Key: ARQ-1557 > URL: https://issues.jboss.org/browse/ARQ-1557 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha2 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > Attachments: brainstorming.jpg > > > Right now, undeployment logic for Droidium is bound to observer which observes with precedence -100 on AfterClass event in order to be sure that this observer will be treated as the latest one. > Right now, we have to be sure that undeployment logic is treated lastly in AfterClass since Arquillian Drone destroys WebDriver instances in AfterClass as well and the destruction of WebDriver instance, in our case, means that Selendroid server will be uninstalled from Android device. > Since the destruction of WebDriver instance itself is executed randomly in AfterClass regarding of execution time, we can not do undeployment of APKs on UnDeployDeployment event because when doing so, uninstallation of instrumented APK automatically kills Selendroid server process as well so that in turn means that subsequent trying to destroy WebDriver instance fails since Selendroid server is not running anymore and Drone talks to nobody. > To be sure that all Selendroid servers are uninstalled so we can proceed with the uninstallation of deployments, where it should be done, there has to be a guarantee that all WebDriver instances were already destroyed. > The solution here seems to be quite simple - we put some positive precedence for DroneDestructor (1) however by doing so, it could cause some backward compatibility issues with Drone extension. > (1) https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl/DroneDestructor.java#L69 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:53:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:53:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1613) Allow Android Shell command timeouts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1613. ---------------------------------- > Allow Android Shell command timeouts > ------------------------------------ > > Key: ARQ-1613 > URL: https://issues.jboss.org/browse/ARQ-1613 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha3 > Reporter: Karel Piwko > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > It would be handy, if Droidium can setup timeout for DDMS related operations, such as executing a shell commands. > It looks like it should be possible with: > {code} > DdmPreferences.setTimeOut(timeout); > {code} > By default, timeout is set to 5 seconds, which might be not enough when running in emulated env. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:53:50 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:53:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1658) Wrong isInstance check prevents usage of new/custom container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1658. ---------------------------------- > Wrong isInstance check prevents usage of new/custom container > -------------------------------------------------------------- > > Key: ARQ-1658 > URL: https://issues.jboss.org/browse/ARQ-1658 > Project: Arquillian > Issue Type: Bug > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha4 > Reporter: Thorben Janssen > Fix For: droidium_1.0.0.Alpha6 > > > If the container configuration contains an unknown qualifier, MultipleContainerRegistryCreator tries to the adapterImplClass class and checks if it implements DeploableContainer. > The current check with isInstance() returns always. The isAssignableFrom() method has to be used instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:53:50 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:53:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1704) Implement replacement for AndroidDriver dropped in Selenium 2.40 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1704. ---------------------------------- > Implement replacement for AndroidDriver dropped in Selenium 2.40 > ---------------------------------------------------------------- > > Key: ARQ-1704 > URL: https://issues.jboss.org/browse/ARQ-1704 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha4 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > Drone 1.3.0.Final will depend on Selenium 2.40 where AndroidDriver is dropped hence support is dropped from Drone as well. > Implement Android-like driver directly in Droidium as a replacement. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:54:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:54:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1718) Simple way to test on real device without the need to use serial id In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1718. ---------------------------------- > Simple way to test on real device without the need to use serial id > ------------------------------------------------------------------- > > Key: ARQ-1718 > URL: https://issues.jboss.org/browse/ARQ-1718 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Reporter: Tadeas Kriz > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > There should be a way to simply test on device, without the need to use serial id, if only one device is connected. Adb has this functionality (if only one device (real or emulated) is connected, it uses it, or with -d switch to use real device (-e for emulated one)). Droidium should also allow this and quit with error if no serial id is specified, but more devices are connected. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:54:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:54:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1763) Download boilerplate APKs for Droidium by Spacelift In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1763. ---------------------------------- > Download boilerplate APKs for Droidium by Spacelift > --------------------------------------------------- > > Key: ARQ-1763 > URL: https://issues.jboss.org/browse/ARQ-1763 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha5 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > Ftesting with Droidium native plugin requires selendroid-server.apk from Selendroid project. Web testing requires android-driver.apk from same project. > Right now, these apks need to be downloaded manually by user so he has to find it on the net and manually setup it in arq.xml. As this is not desired, Spacelift 1.0.0.Alpha2 can download these artifacts automatically and they can be downloaded to target/ when it is not found so user does not have to do a thing. > https://gist.github.com/kpiwko/10738725 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:54:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:54:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1824) Support Google Inc.:Google APIs (x86 System Image):19 format In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1824. ---------------------------------- > Support Google Inc.:Google APIs (x86 System Image):19 format > ------------------------------------------------------------ > > Key: ARQ-1824 > URL: https://issues.jboss.org/browse/ARQ-1824 > Project: Arquillian > Issue Type: Bug > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha5 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: droidium_1.0.0.Alpha6 > > > With new version format in Android SDK, we need to alter parsing options to support '()' in target format. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:54:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:54:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1885) Droidium is not buildable with Java 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1885. ---------------------------------- > Droidium is not buildable with Java 8 > ------------------------------------- > > Key: ARQ-1885 > URL: https://issues.jboss.org/browse/ARQ-1885 > Project: Arquillian > Issue Type: Bug > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Beta1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > {code} > ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (signature-check) on project arquillian-droidium-container: Execution signature-check of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed. IllegalArgumentException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (signature-check) on project arquillian-droidium-container: Execution signature-check of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed. > ... > Caused by: java.lang.IllegalArgumentException > at org.objectweb.asm.ClassReader.(Unknown Source) > at org.objectweb.asm.ClassReader.(Unknown Source) > at org.objectweb.asm.ClassReader.(Unknown Source) > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 07:54:50 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 07:54:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1895) Implement video recorder for Droidium In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1895. ---------------------------------- > Implement video recorder for Droidium > ------------------------------------- > > Key: ARQ-1895 > URL: https://issues.jboss.org/browse/ARQ-1895 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha5 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > > Implement recorder for Droidium based on video API of Arquillian Video Recorder. > The goal of this implementation is to record videos of Android phone itself via screenrecorder API in ddmlib since ddms 24.0.0 - aplicable for Android API 19+. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 09:37:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 09:37:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-465) Missing arquillian-recorder-screenshooter dependencies of arquillian-browser-screenshooter 2.1.0-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQGRA-465. ------------------------------------ > Missing arquillian-recorder-screenshooter dependencies of arquillian-browser-screenshooter 2.1.0-SNAPSHOT > --------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-465 > URL: https://issues.jboss.org/browse/ARQGRA-465 > Project: Arquillian Graphene > Issue Type: Bug > Components: build > Reporter: Pavel Jelinek > Assignee: Stefan Miklosovic > Fix For: 2.1.0.Alpha2 > > > Failed to execute goal on project console-graphene: Could not resolve dependencies for project console-graphene:console-graphene:jar:1.0-SNAPSHOT: The following artifacts could not be resolved: org.arquillian.extension:arquillian-recorder-screenshooter-impl-base:jar:1.0.0.Beta1-SNAPSHOT, org.arquillian.extension:arquillian-recorder-screenshooter-spi:jar:1.0.0.Beta1-SNAPSHOT: Could not find artifact org.arquillian.extension:arquillian-recorder-screenshooter-impl-base:jar:1.0.0.Beta1-SNAPSHOT in jboss-developer-repository-group (https://repository.jboss.org/nexus/content/groups/developer/) > after arquillian-recorder-screenshooter move from 1.0.0.Beta1-SNAPSHOT to 1.0.0.Final-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 09:37:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 09:37:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-457) Upgrade Tomcat version in ftest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQGRA-457. ------------------------------------ > Upgrade Tomcat version in ftest > ------------------------------- > > Key: ARQGRA-457 > URL: https://issues.jboss.org/browse/ARQGRA-457 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: ftest > Affects Versions: 2.0.3.Final > Reporter: Pavol Pitonak > Assignee: Pavol Pitonak > Fix For: 2.1.0.Alpha2 > > > Module ftest downloads Tomcat distribution from Maven repository using com.googlecode.t7mp:tomcat:7.0.26. > It should use official Apache's distribution from org.apache.tomcat:tomcat:7.0.55 (latest release 7.x) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 09:38:50 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 09:38:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-374) Allow to setup custom Location URL via arquillian.xml configuration with CustomizableURLResourceProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQGRA-374. ------------------------------------ > Allow to setup custom Location URL via arquillian.xml configuration with CustomizableURLResourceProvider > -------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-374 > URL: https://issues.jboss.org/browse/ARQGRA-374 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > Assignee: Stefan Miklosovic > Fix For: 2.1.0.Alpha2 > > > {code:xml} > > > http://localhost:8080/app/ > > > {code} > The provider will obtain URL from {{URLResourceProvider}} and use it if no other URL is provided. > Configuring this provider should also block deploying application, since its unnecessary. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 09:38:50 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 09:38:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-467) Screenshooter: Tests fail when no Drone contexts exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQGRA-467. ------------------------------------ > Screenshooter: Tests fail when no Drone contexts exist > ------------------------------------------------------ > > Key: ARQGRA-467 > URL: https://issues.jboss.org/browse/ARQGRA-467 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1.0.Alpha1 > Reporter: Luk?? Fry? > Assignee: Stefan Miklosovic > Fix For: 2.1.0.Alpha2 > > > https://github.com/arquillian/arquillian-recorder/issues/10 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 09:38:50 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 09:38:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-463) JavaScript resource loader should use JavaScript.class.getClassLoader() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQGRA-463. ------------------------------------ > JavaScript resource loader should use JavaScript.class.getClassLoader() > ----------------------------------------------------------------------- > > Key: ARQGRA-463 > URL: https://issues.jboss.org/browse/ARQGRA-463 > Project: Arquillian Graphene > Issue Type: Enhancement > Affects Versions: 2.0.3.Final, 2.1.0.Alpha1 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: 2.1.0.Alpha2 > > > It uses ClassLoader.getSystemResourceAsStream(resourceName); -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 09:38:50 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sun, 1 Feb 2015 09:38:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-440) Upgrade Drone to 2.0.0.Alpha3 and Arquillian Core to 1.1.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQGRA-440. ------------------------------------ > Upgrade Drone to 2.0.0.Alpha3 and Arquillian Core to 1.1.5 > ---------------------------------------------------------- > > Key: ARQGRA-440 > URL: https://issues.jboss.org/browse/ARQGRA-440 > Project: Arquillian Graphene > Issue Type: Task > Components: core > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj H?ska > Assignee: Stefan Miklosovic > Fix For: 2.1.0.Alpha2 > > > IMHO we should upgrade to new Drone {{2.0.0.Alpha1}} as well as to Arquillian core {{1.1.4.Final}} in a non stable 2.1.x branch to try compatibility with these versions. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Feb 1 15:26:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 1 Feb 2015 15:26:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1909) Support non beans.xml deployments when using CDI 1.1 In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1909: ---------------------------------- Summary: Support non beans.xml deployments when using CDI 1.1 Key: ARQ-1909 URL: https://issues.jboss.org/browse/ARQ-1909 Project: Arquillian Issue Type: Feature Request Components: Weld Containers Affects Versions: weld_1.0.0.CR8 Reporter: Aslak Knutsen As CDI 1.1 don't require a beans.xml in the deployment to run. Same behavior should work in the weld-se|ee containers. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Feb 3 09:04:49 2015 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Tue, 3 Feb 2015 09:04:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juergen Zimmermann updated ARQGRA-454: -------------------------------------- Affects Version/s: 2.1.0.Alpha2 > NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final > -------------------------------------------------------------- > > Key: ARQGRA-454 > URL: https://issues.jboss.org/browse/ARQGRA-454 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Juergen Zimmermann > Fix For: 2.0.4.Final > > > I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final. > The stacktrace: > {code} > org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException: > Error while initializing: class de.shop.util.IndexPage > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120) > at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291) > at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54) > 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.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > 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.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > 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) > Caused by: java.lang.NullPointerException > at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73) > at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97) > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76) > ... 34 more > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Feb 3 09:04:49 2015 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Tue, 3 Feb 2015 09:04:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037156#comment-13037156 ] Juergen Zimmermann commented on ARQGRA-454: ------------------------------------------- The issue still exists with 2.1.0.Alpha2. > NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final > -------------------------------------------------------------- > > Key: ARQGRA-454 > URL: https://issues.jboss.org/browse/ARQGRA-454 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Juergen Zimmermann > Fix For: 2.0.4.Final > > > I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final. > The stacktrace: > {code} > org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException: > Error while initializing: class de.shop.util.IndexPage > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120) > at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291) > at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54) > 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.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > 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.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > 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) > Caused by: java.lang.NullPointerException > at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73) > at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97) > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76) > ... 34 more > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 4 04:16:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 4 Feb 2015 04:16:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-454: ------------------------------ Fix Version/s: 2.1-Tracking > NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final > -------------------------------------------------------------- > > Key: ARQGRA-454 > URL: https://issues.jboss.org/browse/ARQGRA-454 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Juergen Zimmermann > Fix For: 2.0.4.Final, 2.1-Tracking > > > I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final. > The stacktrace: > {code} > org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException: > Error while initializing: class de.shop.util.IndexPage > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120) > at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291) > at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54) > 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.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > 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.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > 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) > Caused by: java.lang.NullPointerException > at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73) > at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97) > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76) > ... 34 more > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 4 04:17:50 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 4 Feb 2015 04:17:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-454: --------------------------------- Assignee: Luk?? Fry? > NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final > -------------------------------------------------------------- > > Key: ARQGRA-454 > URL: https://issues.jboss.org/browse/ARQGRA-454 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Juergen Zimmermann > Assignee: Luk?? Fry? > Fix For: 2.0.4.Final, 2.1-Tracking > > > I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final. > The stacktrace: > {code} > org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException: > Error while initializing: class de.shop.util.IndexPage > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120) > at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291) > at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54) > 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.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > 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.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > 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) > Caused by: java.lang.NullPointerException > at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73) > at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97) > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76) > ... 34 more > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 4 05:33:48 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 4 Feb 2015 05:33:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1910) EventRecording done in AbstractManagerTestBase is not thread safe In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1910: ---------------------------------- Summary: EventRecording done in AbstractManagerTestBase is not thread safe Key: ARQ-1910 URL: https://issues.jboss.org/browse/ARQ-1910 Project: Arquillian Issue Type: Bug Components: Base Implementation Affects Versions: 1.1.6.Final Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.1.7.Final When combining the Arquillian Core extension test framework and the ExecutorService one might get false event counts. The EventRecorder counts / stores events in a non thread safe way, which essential mean it occasionally might record fewer events then actually happened. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 4 10:00:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 4 Feb 2015 10:00:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1911) EventRecorder should support recording active Thread In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1911: ---------------------------------- Summary: EventRecorder should support recording active Thread Key: ARQ-1911 URL: https://issues.jboss.org/browse/ARQ-1911 Project: Arquillian Issue Type: Enhancement Components: Base Implementation Affects Versions: 1.1.6.Final Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.1.7.Final Arquillian Core test suite should allow to record which Thread an event occurred on. This to help prove Observers using the ExecutorService actually are multi threading. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 06:11:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 9 Feb 2015 06:11:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1912) Failed assertion not reported in stats + NPE in surefire In-Reply-To: References: Message-ID: Thomas Diesler created ARQ-1912: ----------------------------------- Summary: Failed assertion not reported in stats + NPE in surefire Key: ARQ-1912 URL: https://issues.jboss.org/browse/ARQ-1912 Project: Arquillian Issue Type: Bug Affects Versions: 1.1.6.Final Reporter: Thomas Diesler A simple test like this {code} @Test public void testClassLoader() throws Exception { ClassLoader tccl = Thread.currentThread().getContextClassLoader(); Assert.assertNull("TCCL null: " + tccl, tccl); } {code} run on wildfly-8.2.0, leads to {code} 12:06:25,126 SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-2-thread-1) Failed: org.wildfly.camel.test.classloading.ThreadContextClassloaderTest.testClassLoader: java.lang.AssertionError: TCCL null: ModuleClassLoader for Module "deployment.tccl-tests:main" from Service Module Loader expected null, but was: at org.junit.Assert.fail(Assert.java:88) [arquillian-service:] at org.junit.Assert.failNotNull(Assert.java:664) [arquillian-service:] at org.junit.Assert.assertNull(Assert.java:646) [arquillian-service:] at org.wildfly.camel.test.classloading.ThreadContextClassloaderTest.testClassLoader(ThreadContextClassloaderTest.java:72) [tccl-tests:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_31] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_31] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_31] at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_31] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) [arquillian-service:] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) [arquillian-service:] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) [arquillian-service:] at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:325) [arquillian-service:] at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) [arquillian-service:] {code} but the report shows {code} Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 20.639 s [INFO] Finished at: 2015-02-09T12:06:26+01:00 [INFO] Final Memory: 51M/436M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on project wildfly-camel-itests-standalone: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed: There was an error in the forked process [ERROR] org.apache.maven.surefire.testset.TestSetFailedException: java.lang.NullPointerException; nested exception is java.lang.NullPointerException: null [ERROR] java.lang.NullPointerException [ERROR] at org.apache.maven.surefire.report.SmartStackTraceParser.getClass(SmartStackTraceParser.java:67) [ERROR] at org.apache.maven.surefire.report.SmartStackTraceParser.(SmartStackTraceParser.java:57) [ERROR] at org.apache.maven.surefire.common.junit4.JUnit4StackTraceWriter.smartTrimmedStackTrace(JUnit4StackTraceWriter.java:77) [ERROR] at org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:328) [ERROR] at org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:312) [ERROR] at org.apache.maven.surefire.booter.ForkingRunListener.toString(ForkingRunListener.java:258) [ERROR] at org.apache.maven.surefire.booter.ForkingRunListener.testFailed(ForkingRunListener.java:137) [ERROR] at org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:110) [ERROR] at org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:139) [ERROR] at org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:61) [ERROR] at org.junit.runner.notification.RunNotifier.fireTestFailures(RunNotifier.java:134) [ERROR] at org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:128) [ERROR] at org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:23) [ERROR] at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:275) [ERROR] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) [ERROR] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [ERROR] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [ERROR] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [ERROR] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [ERROR] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [ERROR] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [ERROR] at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:202) [ERROR] at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:377) [ERROR] at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:52) [ERROR] at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:216) [ERROR] at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [ERROR] at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:164) {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 06:31:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 9 Feb 2015 06:31:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1912) Failed assertion not reported in stats + NPE in surefire In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler closed ARQ-1912. ------------------------------- Resolution: Out of Date Caused by a combination of surefire-2.16 + usage of the BOM. Updating to surefire-2.18.1 works for me. > Failed assertion not reported in stats + NPE in surefire > -------------------------------------------------------- > > Key: ARQ-1912 > URL: https://issues.jboss.org/browse/ARQ-1912 > Project: Arquillian > Issue Type: Bug > Affects Versions: 1.1.6.Final > Reporter: Thomas Diesler > > A simple test like this > {code} > @Test > public void testClassLoader() throws Exception { > ClassLoader tccl = Thread.currentThread().getContextClassLoader(); > Assert.assertNull("TCCL null: " + tccl, tccl); > } > {code} > run on wildfly-8.2.0, leads to > {code} > 12:06:25,126 SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-2-thread-1) Failed: org.wildfly.camel.test.classloading.ThreadContextClassloaderTest.testClassLoader: java.lang.AssertionError: TCCL null: ModuleClassLoader for Module "deployment.tccl-tests:main" from Service Module Loader expected null, but was: > at org.junit.Assert.fail(Assert.java:88) [arquillian-service:] > at org.junit.Assert.failNotNull(Assert.java:664) [arquillian-service:] > at org.junit.Assert.assertNull(Assert.java:646) [arquillian-service:] > at org.wildfly.camel.test.classloading.ThreadContextClassloaderTest.testClassLoader(ThreadContextClassloaderTest.java:72) [tccl-tests:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_31] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_31] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_31] > at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_31] > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) [arquillian-service:] > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) [arquillian-service:] > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) [arquillian-service:] > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:325) [arquillian-service:] > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) [arquillian-service:] > {code} > but the report shows > {code} > Results : > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 20.639 s > [INFO] Finished at: 2015-02-09T12:06:26+01:00 > [INFO] Final Memory: 51M/436M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on project wildfly-camel-itests-standalone: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed: There was an error in the forked process > [ERROR] org.apache.maven.surefire.testset.TestSetFailedException: java.lang.NullPointerException; nested exception is java.lang.NullPointerException: null > [ERROR] java.lang.NullPointerException > [ERROR] at org.apache.maven.surefire.report.SmartStackTraceParser.getClass(SmartStackTraceParser.java:67) > [ERROR] at org.apache.maven.surefire.report.SmartStackTraceParser.(SmartStackTraceParser.java:57) > [ERROR] at org.apache.maven.surefire.common.junit4.JUnit4StackTraceWriter.smartTrimmedStackTrace(JUnit4StackTraceWriter.java:77) > [ERROR] at org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:328) > [ERROR] at org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:312) > [ERROR] at org.apache.maven.surefire.booter.ForkingRunListener.toString(ForkingRunListener.java:258) > [ERROR] at org.apache.maven.surefire.booter.ForkingRunListener.testFailed(ForkingRunListener.java:137) > [ERROR] at org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:110) > [ERROR] at org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:139) > [ERROR] at org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:61) > [ERROR] at org.junit.runner.notification.RunNotifier.fireTestFailures(RunNotifier.java:134) > [ERROR] at org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:128) > [ERROR] at org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:23) > [ERROR] at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:275) > [ERROR] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > [ERROR] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > [ERROR] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > [ERROR] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > [ERROR] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > [ERROR] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > [ERROR] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > [ERROR] at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:202) > [ERROR] at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:377) > [ERROR] at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:52) > [ERROR] at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:216) > [ERROR] at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > [ERROR] at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:164) > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 07:52:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 9 Feb 2015 07:52:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: 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) From issues at jboss.org Mon Feb 9 07:54:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 9 Feb 2015 07:54:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038751#comment-13038751 ] 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) From issues at jboss.org Mon Feb 9 07:54:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 9 Feb 2015 07:54:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038751#comment-13038751 ] 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) From issues at jboss.org Mon Feb 9 07:54:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 9 Feb 2015 07:54:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Mon Feb 9 07:56:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 9 Feb 2015 07:56:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Mon Feb 9 07:59:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 9 Feb 2015 07:59:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038754#comment-13038754 ] Thomas Diesler commented on ARQ-1913: ------------------------------------- https://github.com/arquillian/arquillian-core/pull/79 > 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) From issues at jboss.org Mon Feb 9 07:59:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 9 Feb 2015 07:59:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038751#comment-13038751 ] 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) From issues at jboss.org Mon Feb 9 08:00:53 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 9 Feb 2015 08:00:53 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038754#comment-13038754 ] Thomas Diesler edited comment on ARQ-1913 at 2/9/15 7:59 AM: ------------------------------------------------------------- PR sent: https://github.com/arquillian/arquillian-core/pull/79 was (Author: thomas.diesler): https://github.com/arquillian/arquillian-core/pull/79 > 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) From issues at jboss.org Tue Feb 10 02:26:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Tue, 10 Feb 2015 02:26:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler updated ARQ-1913: -------------------------------- Comment: was deleted (was: PR sent: https://github.com/arquillian/arquillian-core/pull/79) > 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) From issues at jboss.org Tue Feb 10 04:43:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Tue, 10 Feb 2015 04:43:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039033#comment-13039033 ] 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 at 4aa298b7: java.lang.RuntimeException: TCCL not null: sun.misc.Launcher$AppClassLoader at 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) From issues at jboss.org Tue Feb 10 06:14:48 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 10 Feb 2015 06:14:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039058#comment-13039058 ] 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 at 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) From issues at jboss.org Tue Feb 10 07:53:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Tue, 10 Feb 2015 07:53:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1879) Remove dependency on TCCL in JUnitBundleTestRunner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Tue Feb 10 07:53:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Tue, 10 Feb 2015 07:53:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1880) Arquillian core relies on TCCL to load infra In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Tue Feb 10 07:59:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Tue, 10 Feb 2015 07:59:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1913) ARQ calls test methods with TCCL being set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Tue Feb 10 09:44:49 2015 From: issues at jboss.org (=?UTF-8?Q?Constantin_Wei=C3=9Fer_=28JIRA=29?=) Date: Tue, 10 Feb 2015 09:44:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: 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) From issues at jboss.org Tue Feb 10 09:48:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 10 Feb 2015 09:48:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Tue Feb 10 09:49:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 10 Feb 2015 09:49:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039142#comment-13039142 ] 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) From issues at jboss.org Tue Feb 10 10:16:49 2015 From: issues at jboss.org (=?UTF-8?Q?Constantin_Wei=C3=9Fer_=28JIRA=29?=) Date: Tue, 10 Feb 2015 10:16:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039159#comment-13039159 ] 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) From issues at jboss.org Tue Feb 10 10:47:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 10 Feb 2015 10:47:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039174#comment-13039174 ] 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) From issues at jboss.org Tue Feb 10 16:24:50 2015 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 10 Feb 2015 16:24:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-791) JMX: Arquillian is unable to reconnect to JMX server if the connection is lost In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039246#comment-13039246 ] 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) From issues at jboss.org Wed Feb 11 03:08:49 2015 From: issues at jboss.org (=?UTF-8?Q?Constantin_Wei=C3=9Fer_=28JIRA=29?=) Date: Wed, 11 Feb 2015 03:08:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039293#comment-13039293 ] Constantin Wei?er commented on ARQ-1914: ---------------------------------------- That's my poml.xml: https://gist.github.com/anonymous/0a476761c8de1bab0d8d > 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) From issues at jboss.org Wed Feb 11 03:13:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 03:13:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039294#comment-13039294 ] Aslak Knutsen commented on ARQ-1914: ------------------------------------ You choose GlassFish Embedded 3.1.1 https://gist.github.com/anonymous/0a476761c8de1bab0d8d#file-pom-xml-L121 > 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) From issues at jboss.org Wed Feb 11 03:29:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 11 Feb 2015 03:29:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1881) Fix starting/stopping of remote karaf container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler updated ARQ-1881: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Done > 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.11#6341) From issues at jboss.org Wed Feb 11 03:30:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 11 Feb 2015 03:30:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1870) Method KarafRemoteContainerConfiguration.validate() does not call super method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler updated ARQ-1870: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Done > Method KarafRemoteContainerConfiguration.validate() does not call super method > ------------------------------------------------------------------------------ > > Key: ARQ-1870 > URL: https://issues.jboss.org/browse/ARQ-1870 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Martin Basovnik > Assignee: Thomas Diesler > > Method {{KarafRemoteContainerConfiguration.validate()}} does not call super method. > Neither {{JMXContainerConfiguration.validate()}} nor {{CommonContainerConfiguration.validate()}} is called. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 03:30:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 11 Feb 2015 03:30:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1856) Remove dynamic import from arquillian-bundle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler updated ARQ-1856: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Done > Remove dynamic import from arquillian-bundle > -------------------------------------------- > > Key: ARQ-1856 > URL: https://issues.jboss.org/browse/ARQ-1856 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: osgi_2.0.0.Final > > > Currently, the arquillian bundle contains a dynamic import "*" which may lead to undesired package wiring. Theoretically, it should possible to embed all required dependencies in the arq-bundle and load the test classes from the test-bundle(s) via Bundle.loadClass(...) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 03:31:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 11 Feb 2015 03:31:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1787) Move tests to separate maven module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler updated ARQ-1787: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Done > Move tests to separate maven module > ----------------------------------- > > Key: ARQ-1787 > URL: https://issues.jboss.org/browse/ARQ-1787 > Project: Arquillian > Issue Type: Enhancement > Components: OSGi Containers > Reporter: Stefan Bunciak > Assignee: Thomas Diesler > > Move tests to separate maven module, so that all container adapter share the same set of tests. Container-specific tests can still reside with the container adapter implementation -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 04:47:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 04:47:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1880) Arquillian core relies on TCCL to load infra In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1880: ------------------------------- Fix Version/s: 1.1.7.Final > 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 > Fix For: 1.1.7.Final > > > 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) From issues at jboss.org Wed Feb 11 13:11:48 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 13:11:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1818) JUnit @Before/After phase is called after/before Arquillian's Before/After phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1818. -------------------------------- Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/606b4b29a3a561bc0ea6ed2f4883f7e37fa5153c > JUnit @Before/After phase is called after/before Arquillian's Before/After phase > -------------------------------------------------------------------------------- > > Key: ARQ-1818 > URL: https://issues.jboss.org/browse/ARQ-1818 > Project: Arquillian > Issue Type: Bug > Components: Test Harness Integration > Affects Versions: 1.1.5.Final, 1.1.6.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Priority: Blocker > Fix For: 1.1.7.Final > > > In < 1.1.5.Final JUnit's @Before and @After was called by Arquillian as part of Arquillian's Before and After phases. This changed by accident during the JUnit Rule support rewrite and @Before is now called after Arquillian's Before and @After phase is now called Before Arquillian's After. > This break down APIs like Deployer/ContainerController as non of the Suite/Class/Test Contexts are active at that point. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 13:51:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 13:51:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1880) Arquillian core relies on TCCL to load infra In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1880. -------------------------------- Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/f0036995df93e0464aa089fd1513aeffc082c6d9 > 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 > Fix For: 1.1.7.Final > > > 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) From issues at jboss.org Wed Feb 11 15:07:48 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 15:07:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1915) ShrinkWrap Descriptors upgrade 2.0.0-alpha-7 In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1915: ---------------------------------- Summary: ShrinkWrap Descriptors upgrade 2.0.0-alpha-7 Key: ARQ-1915 URL: https://issues.jboss.org/browse/ARQ-1915 Project: Arquillian Issue Type: Enhancement Components: Base Implementation Affects Versions: 1.1.6.Final Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.1.7.Final -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 15:10:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 15:10:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1915) ShrinkWrap Descriptors upgrade 2.0.0-alpha-7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1915. -------------------------------- Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/be61ca9988698f67704ad90ee8ba5c7ba21618ad > ShrinkWrap Descriptors upgrade 2.0.0-alpha-7 > -------------------------------------------- > > Key: ARQ-1915 > URL: https://issues.jboss.org/browse/ARQ-1915 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Affects Versions: 1.1.6.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.7.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 16:10:48 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 16:10:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1910) EventRecording done in AbstractManagerTestBase is not thread safe In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1910. -------------------------------- Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/792137b750f27393903a90295f78d8adae2492dc > EventRecording done in AbstractManagerTestBase is not thread safe > ----------------------------------------------------------------- > > Key: ARQ-1910 > URL: https://issues.jboss.org/browse/ARQ-1910 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation > Affects Versions: 1.1.6.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.7.Final > > > When combining the Arquillian Core extension test framework and the ExecutorService one might get false event counts. > The EventRecorder counts / stores events in a non thread safe way, which essential mean it occasionally might record fewer events then actually happened. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 16:11:48 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 16:11:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1911) EventRecorder should support recording active Thread In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1911. -------------------------------- Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/75cd8e349b8cb2c51da6ad8d35bcb084eb423ff2 > EventRecorder should support recording active Thread > ---------------------------------------------------- > > Key: ARQ-1911 > URL: https://issues.jboss.org/browse/ARQ-1911 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Affects Versions: 1.1.6.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.7.Final > > > Arquillian Core test suite should allow to record which Thread an event occurred on. This to help prove Observers using the ExecutorService actually are multi threading. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 16:22:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 16:22:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1911) EventRecorder should support recording active Thread In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1911. ------------------------------ > EventRecorder should support recording active Thread > ---------------------------------------------------- > > Key: ARQ-1911 > URL: https://issues.jboss.org/browse/ARQ-1911 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Affects Versions: 1.1.6.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.7.Final > > > Arquillian Core test suite should allow to record which Thread an event occurred on. This to help prove Observers using the ExecutorService actually are multi threading. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 16:22:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 16:22:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1818) JUnit @Before/After phase is called after/before Arquillian's Before/After phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1818. ------------------------------ > JUnit @Before/After phase is called after/before Arquillian's Before/After phase > -------------------------------------------------------------------------------- > > Key: ARQ-1818 > URL: https://issues.jboss.org/browse/ARQ-1818 > Project: Arquillian > Issue Type: Bug > Components: Test Harness Integration > Affects Versions: 1.1.5.Final, 1.1.6.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Priority: Blocker > Fix For: 1.1.7.Final > > > In < 1.1.5.Final JUnit's @Before and @After was called by Arquillian as part of Arquillian's Before and After phases. This changed by accident during the JUnit Rule support rewrite and @Before is now called after Arquillian's Before and @After phase is now called Before Arquillian's After. > This break down APIs like Deployer/ContainerController as non of the Suite/Class/Test Contexts are active at that point. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 16:22:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 16:22:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1880) Arquillian core relies on TCCL to load infra In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1880. ------------------------------ > 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 > Fix For: 1.1.7.Final > > > 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) From issues at jboss.org Wed Feb 11 16:22:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 16:22:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1915) ShrinkWrap Descriptors upgrade 2.0.0-alpha-7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1915. ------------------------------ > ShrinkWrap Descriptors upgrade 2.0.0-alpha-7 > -------------------------------------------- > > Key: ARQ-1915 > URL: https://issues.jboss.org/browse/ARQ-1915 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Affects Versions: 1.1.6.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.7.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 16:22:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 11 Feb 2015 16:22:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1910) EventRecording done in AbstractManagerTestBase is not thread safe In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1910. ------------------------------ > EventRecording done in AbstractManagerTestBase is not thread safe > ----------------------------------------------------------------- > > Key: ARQ-1910 > URL: https://issues.jboss.org/browse/ARQ-1910 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation > Affects Versions: 1.1.6.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.7.Final > > > When combining the Arquillian Core extension test framework and the ExecutorService one might get false event counts. > The EventRecorder counts / stores events in a non thread safe way, which essential mean it occasionally might record fewer events then actually happened. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Feb 12 06:55:49 2015 From: issues at jboss.org (=?UTF-8?Q?Constantin_Wei=C3=9Fer_=28JIRA=29?=) Date: Thu, 12 Feb 2015 06:55:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039766#comment-13039766 ] Constantin Wei?er commented on ARQ-1914: ---------------------------------------- Hi Aslak, thanks for your quick response. I changed this setting to 4.1. This does resolve the prior mentioned error but results in this: SEVERE: Exception while loading the app : WELD-001202 Error parsing jar:file:/tmp/gfembed4868208385859575508tmp/applications/test/WEB-INF/lib/test.jar!/META-INF/beans.xml org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 8; XML document structures must start and end within the same entity. The respective file in the archive is: https://gist.github.com/anonymous/703394b1d59dde7431a5 I ran a XML validator on it and it does not report any errors. > 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) From issues at jboss.org Thu Feb 12 07:00:52 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 12 Feb 2015 07:00:52 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039767#comment-13039767 ] Aslak Knutsen commented on ARQ-1914: ------------------------------------ The file it's complaining about is beans.xml. You posted persistence.xml. > 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) From issues at jboss.org Thu Feb 12 07:31:49 2015 From: issues at jboss.org (=?UTF-8?Q?Constantin_Wei=C3=9Fer_=28JIRA=29?=) Date: Thu, 12 Feb 2015 07:31:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039773#comment-13039773 ] Constantin Wei?er commented on ARQ-1914: ---------------------------------------- The error was this: @Deployment public static JavaArchive createTestArchive() { return ShrinkWrap.create(JavaArchive.class, "test.jar").addPackage(Company.class.getPackage()).addPackage( CompanyPersistenceServiceBean.class.getPackage()).addAsManifestResource( new ByteArrayAsset("".getBytes()), ArchivePaths.create("beans.xml")).addAsManifestResource( "persistence.xml", ArchivePaths.create("persistence.xml")); } It should be "". It seems my issue is hereby solved. Thanks very much, Aslak! > 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) From issues at jboss.org Mon Feb 16 07:39:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 07:39:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1916) Update Droidium to Arquillian 1.1.7 In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1916: -------------------------------------- Summary: Update Droidium to Arquillian 1.1.7 Key: ARQ-1916 URL: https://issues.jboss.org/browse/ARQ-1916 Project: Arquillian Issue Type: Task Components: Extension - Droidium Affects Versions: droidium_1.0.0.Alpha6 Reporter: Stefan Miklosovic -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 16 07:40:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 07:40:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1916) Update Droidium to Arquillian 1.1.7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned ARQ-1916: -------------------------------------- Assignee: Stefan Miklosovic > Update Droidium to Arquillian 1.1.7 > ----------------------------------- > > Key: ARQ-1916 > URL: https://issues.jboss.org/browse/ARQ-1916 > Project: Arquillian > Issue Type: Task > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 16 07:41:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 07:41:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1917) Update Droidium to Spacelift 1.0.0.Alpha5 In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1917: -------------------------------------- Summary: Update Droidium to Spacelift 1.0.0.Alpha5 Key: ARQ-1917 URL: https://issues.jboss.org/browse/ARQ-1917 Project: Arquillian Issue Type: Task Components: Extension - Droidium Affects Versions: droidium_1.0.0.Alpha6 Reporter: Stefan Miklosovic -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 16 07:41:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 07:41:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1917) Update Droidium to Spacelift 1.0.0.Alpha5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned ARQ-1917: -------------------------------------- Assignee: Stefan Miklosovic > Update Droidium to Spacelift 1.0.0.Alpha5 > ----------------------------------------- > > Key: ARQ-1917 > URL: https://issues.jboss.org/browse/ARQ-1917 > Project: Arquillian > Issue Type: Task > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 16 07:42:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 07:42:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1918) Update Recorder to Arquillian 1.1.7 In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1918: -------------------------------------- Summary: Update Recorder to Arquillian 1.1.7 Key: ARQ-1918 URL: https://issues.jboss.org/browse/ARQ-1918 Project: Arquillian Issue Type: Task Components: Extension - Recorder Affects Versions: recorder_1.0.0.Beta1 Reporter: Stefan Miklosovic involve neccessary changes introduced with Before/AfterRules eventing. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 16 07:42:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 07:42:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1918) Update Recorder to Arquillian 1.1.7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned ARQ-1918: -------------------------------------- Assignee: Stefan Miklosovic > Update Recorder to Arquillian 1.1.7 > ----------------------------------- > > Key: ARQ-1918 > URL: https://issues.jboss.org/browse/ARQ-1918 > Project: Arquillian > Issue Type: Task > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Beta1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > > involve neccessary changes introduced with Before/AfterRules eventing. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 16 07:45:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 07:45:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1919) Android SDK with no images fails while testing on physical device In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1919: -------------------------------------- Summary: Android SDK with no images fails while testing on physical device Key: ARQ-1919 URL: https://issues.jboss.org/browse/ARQ-1919 Project: Arquillian Issue Type: Bug Components: Extension - Droidium Affects Versions: droidium_1.0.0.Alpha6 Reporter: Stefan Miklosovic When you want to test on a physical device, there is not any need to have system images installed. This issue is rarely hit in practice, however when using Droidium in CI environment, testing on physical device and not requiring system images to be even installed is major performance improvement. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 16 07:47:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 07:47:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1919) Android SDK with no images fails while testing on physical device In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned ARQ-1919: -------------------------------------- Assignee: Stefan Miklosovic > Android SDK with no images fails while testing on physical device > ----------------------------------------------------------------- > > Key: ARQ-1919 > URL: https://issues.jboss.org/browse/ARQ-1919 > Project: Arquillian > Issue Type: Bug > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > > When you want to test on a physical device, there is not any need to have system images installed. This issue is rarely hit in practice, however when using Droidium in CI environment, testing on physical device and not requiring system images to be even installed is major performance improvement. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 16 07:55:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 07:55:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1920) Update Droidium to use Selendroid 0.14.0 In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1920: -------------------------------------- Summary: Update Droidium to use Selendroid 0.14.0 Key: ARQ-1920 URL: https://issues.jboss.org/browse/ARQ-1920 Project: Arquillian Issue Type: Task Components: Extension - Droidium Affects Versions: droidium_1.0.0.Alpha6 Reporter: Stefan Miklosovic -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 16 07:55:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 07:55:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1920) Update Droidium to use Selendroid 0.14.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned ARQ-1920: -------------------------------------- Assignee: Stefan Miklosovic > Update Droidium to use Selendroid 0.14.0 > ---------------------------------------- > > Key: ARQ-1920 > URL: https://issues.jboss.org/browse/ARQ-1920 > Project: Arquillian > Issue Type: Task > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 16 07:59:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 07:59:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040495#comment-13040495 ] Stefan Miklosovic commented on ARQ-1914: ---------------------------------------- new ByteArrayAsset("".getBytes()) that is completely wrong, where is your ending tag? when you want to create emtpy beans.xml, create it like this .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml") > 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) From issues at jboss.org Mon Feb 16 08:01:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 08:01:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1914. ------------------------------------ Resolution: Rejected > 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) From issues at jboss.org Mon Feb 16 08:01:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 16 Feb 2015 08:01:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1914) Arquillian embedded tests do not support @Convert/@Converter (JPA 2.1) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1914. ---------------------------------- > 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) From issues at jboss.org Mon Feb 16 08:21:50 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 16 Feb 2015 08:21:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1921) ResourceProvider SPI should differentiate between Class and Method injection In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1921: ---------------------------------- Summary: ResourceProvider SPI should differentiate between Class and Method injection Key: ARQ-1921 URL: https://issues.jboss.org/browse/ARQ-1921 Project: Arquillian Issue Type: Feature Request Components: Runtime Enricher SPI Affects Versions: 1.1.7.Final Reporter: Aslak Knutsen If a ResourceEnricher wants to have differently scoped objects based on this being injected on Class level or Method level the ResourceProvider SPI needs to relay this information somehow. Currently this is hidden. An easy fix without breaking the SPI signature would be to add a Class/Method Qualifier annotation that's auto provided by the ResourceProvider impl. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 16 08:21:50 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 16 Feb 2015 08:21:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1921) ResourceProvider SPI should differentiate between Class and Method injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1921: ------------------------------- Fix Version/s: 1.1.8 > ResourceProvider SPI should differentiate between Class and Method injection > ---------------------------------------------------------------------------- > > Key: ARQ-1921 > URL: https://issues.jboss.org/browse/ARQ-1921 > Project: Arquillian > Issue Type: Feature Request > Components: Runtime Enricher SPI > Affects Versions: 1.1.7.Final > Reporter: Aslak Knutsen > Fix For: 1.1.8 > > > If a ResourceEnricher wants to have differently scoped objects based on this being injected on Class level or Method level the ResourceProvider SPI needs to relay this information somehow. Currently this is hidden. > An easy fix without breaking the SPI signature would be to add a Class/Method Qualifier annotation that's auto provided by the ResourceProvider impl. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Feb 17 11:08:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 17 Feb 2015 11:08:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1922) Undeleted ArquillianSpaceliftExtension file prevents its usage with Arquillian extensions In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1922: -------------------------------------- Summary: Undeleted ArquillianSpaceliftExtension file prevents its usage with Arquillian extensions Key: ARQ-1922 URL: https://issues.jboss.org/browse/ARQ-1922 Project: Arquillian Issue Type: Bug Components: Extension - Spacelift Affects Versions: spacelift_1.0.0.Alpha5 Reporter: Stefan Miklosovic -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Feb 17 11:08:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 17 Feb 2015 11:08:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1922) Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1922: ----------------------------------- Summary: Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions (was: Undeleted ArquillianSpaceliftExtension file prevents its usage with Arquillian extensions) > Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions > ---------------------------------------------------------------------------------------------------- > > Key: ARQ-1922 > URL: https://issues.jboss.org/browse/ARQ-1922 > Project: Arquillian > Issue Type: Bug > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha5 > Reporter: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Feb 17 11:09:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 17 Feb 2015 11:09:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1922) Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1922: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-spacelift/pull/27 > Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions > ---------------------------------------------------------------------------------------------------- > > Key: ARQ-1922 > URL: https://issues.jboss.org/browse/ARQ-1922 > Project: Arquillian > Issue Type: Bug > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha5 > Reporter: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Feb 17 11:09:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 17 Feb 2015 11:09:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1922) Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned ARQ-1922: -------------------------------------- Assignee: Stefan Miklosovic > Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions > ---------------------------------------------------------------------------------------------------- > > Key: ARQ-1922 > URL: https://issues.jboss.org/browse/ARQ-1922 > Project: Arquillian > Issue Type: Bug > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha5 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Feb 17 11:19:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 17 Feb 2015 11:19:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1922) Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1922: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions > ---------------------------------------------------------------------------------------------------- > > Key: ARQ-1922 > URL: https://issues.jboss.org/browse/ARQ-1922 > Project: Arquillian > Issue Type: Bug > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha5 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 18 10:18:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 18 Feb 2015 10:18:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1917) Update Droidium to Spacelift 1.0.0.Alpha6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1917: ----------------------------------- Summary: Update Droidium to Spacelift 1.0.0.Alpha6 (was: Update Droidium to Spacelift 1.0.0.Alpha5) > Update Droidium to Spacelift 1.0.0.Alpha6 > ----------------------------------------- > > Key: ARQ-1917 > URL: https://issues.jboss.org/browse/ARQ-1917 > Project: Arquillian > Issue Type: Task > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Feb 19 10:23:49 2015 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Thu, 19 Feb 2015 10:23:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1923) Cannot build Warp 1.0.0.Alpha7 with OpenJDK 8 In-Reply-To: References: Message-ID: Pavol Pitonak created ARQ-1923: ---------------------------------- Summary: Cannot build Warp 1.0.0.Alpha7 with OpenJDK 8 Key: ARQ-1923 URL: https://issues.jboss.org/browse/ARQ-1923 Project: Arquillian Issue Type: Bug Components: Extension - Warp Affects Versions: warp_1.0.0.Alpha7 Reporter: Pavol Pitonak # git clone https://github.com/arquillian/arquillian-extension-warp.git # mvn clean install result: * when launched with OpenJDK 8, one test fails TestExecutedMethod.testSerializedAnnotation {code} java.lang.IllegalStateException: java.lang.IllegalStateException: Error instantiating proxy for annotation. Annotation type: interface org.jboss.arquillian.warp.impl.shared.TestingAnnotation at org.jboss.arquillian.warp.impl.shared.SerializedAnnotation.getAnnotation(SerializedAnnotation.java:61) at org.jboss.arquillian.warp.impl.shared.TestExecutedMethod.testSerializedAnnotation(TestExecutedMethod.java:49) 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:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) Caused by: java.lang.IllegalStateException: Error instantiating proxy for annotation. Annotation type: interface org.jboss.arquillian.warp.impl.shared.TestingAnnotation at org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider.get(AnnotationInstanceProvider.java:83) at org.jboss.arquillian.warp.impl.shared.SerializedAnnotation.getAnnotation(SerializedAnnotation.java:59) ... 24 more Caused by: java.lang.IllegalAccessException: Class org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider can not access a member of class org.jboss.arquillian.warp.impl.shared.$Proxy5 with modifiers "public" at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101) at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:295) at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:287) at java.lang.reflect.Constructor.newInstance(Constructor.java:398) at org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider.get(AnnotationInstanceProvider.java:76) ... 25 more {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Feb 20 07:24:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Fri, 20 Feb 2015 07:24:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1917) Update Droidium to Spacelift 1.0.0.Alpha6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1917. ------------------------------------ Fix Version/s: droidium_1.0.0.Alpha6 Resolution: Done https://github.com/arquillian/arquillian-droidium/commit/000f49202a71a553e6a8b9e559fee65563f8f4b1 > Update Droidium to Spacelift 1.0.0.Alpha6 > ----------------------------------------- > > Key: ARQ-1917 > URL: https://issues.jboss.org/browse/ARQ-1917 > Project: Arquillian > Issue Type: Task > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Alpha6 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Feb 20 07:24:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Fri, 20 Feb 2015 07:24:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1917) Update Droidium to Spacelift 1.0.0.Alpha6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1917: ----------------------------------- Fix Version/s: (was: droidium_1.0.0.Alpha6) > Update Droidium to Spacelift 1.0.0.Alpha6 > ----------------------------------------- > > Key: ARQ-1917 > URL: https://issues.jboss.org/browse/ARQ-1917 > Project: Arquillian > Issue Type: Task > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Feb 20 13:08:49 2015 From: issues at jboss.org (Rafael Benevides (JIRA)) Date: Fri, 20 Feb 2015 13:08:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1924) Bad behaviour on Shrinkwrap.addAsServiceProvider In-Reply-To: References: Message-ID: Rafael Benevides created ARQ-1924: ------------------------------------- Summary: Bad behaviour on Shrinkwrap.addAsServiceProvider Key: ARQ-1924 URL: https://issues.jboss.org/browse/ARQ-1924 Project: Arquillian Issue Type: Bug Components: OpenWebBeans Containers, Weld Containers Affects Versions: 1.1.7.Final, 1.0.0.CR8 Reporter: Rafael Benevides The attached maven project contains two tests: 1 - ExtensionInJarTest - This adds a Service through .addAsServiceProvider to an JAR that is placed inside a WAR 2 - ExtensionInWarTest - This add a Service through .addAsServiceProvider directly to a WAR If you run the tests inside Wildfly: {code} mvn clean test -Parq-wildfly-remote //it works {code} If you run the tests using Weld or OWB: {code} mvn clean test -PWeld //it fails on ExtensionInJarTest mvn clean test -POWB //it fails on ExtensionInJarTest {code} The expected behaviour is that Weld and OWB shouldn't fail. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Feb 20 13:09:49 2015 From: issues at jboss.org (Rafael Benevides (JIRA)) Date: Fri, 20 Feb 2015 13:09:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1924) Bad behaviour on Shrinkwrap.addAsServiceProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Benevides updated ARQ-1924: ---------------------------------- Attachment: arquillian-test.zip > Bad behaviour on Shrinkwrap.addAsServiceProvider > ------------------------------------------------ > > Key: ARQ-1924 > URL: https://issues.jboss.org/browse/ARQ-1924 > Project: Arquillian > Issue Type: Bug > Components: OpenWebBeans Containers, Weld Containers > Affects Versions: 1.0.0.CR8, 1.1.7.Final > Reporter: Rafael Benevides > Attachments: arquillian-test.zip > > > The attached maven project contains two tests: > 1 - ExtensionInJarTest - This adds a Service through .addAsServiceProvider to an JAR that is placed inside a WAR > 2 - ExtensionInWarTest - This add a Service through .addAsServiceProvider directly to a WAR > If you run the tests inside Wildfly: > {code} > mvn clean test -Parq-wildfly-remote //it works > {code} > If you run the tests using Weld or OWB: > {code} > mvn clean test -PWeld //it fails on ExtensionInJarTest > mvn clean test -POWB //it fails on ExtensionInJarTest > {code} > The expected behaviour is that Weld and OWB shouldn't fail. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Feb 20 13:16:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 20 Feb 2015 13:16:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1924) Bad behaviour on Shrinkwrap.addAsServiceProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042545#comment-13042545 ] Aslak Knutsen commented on ARQ-1924: ------------------------------------ Yeah, the faked class loading done for war's in the weld and owb containers is extremely simplistic.. > Bad behaviour on Shrinkwrap.addAsServiceProvider > ------------------------------------------------ > > Key: ARQ-1924 > URL: https://issues.jboss.org/browse/ARQ-1924 > Project: Arquillian > Issue Type: Bug > Components: OpenWebBeans Containers, Weld Containers > Affects Versions: 1.0.0.CR8, 1.1.7.Final > Reporter: Rafael Benevides > Attachments: arquillian-test.zip > > > The attached maven project contains two tests: > 1 - ExtensionInJarTest - This adds a Service through .addAsServiceProvider to an JAR that is placed inside a WAR > 2 - ExtensionInWarTest - This add a Service through .addAsServiceProvider directly to a WAR > If you run the tests inside Wildfly: > {code} > mvn clean test -Parq-wildfly-remote //it works > {code} > If you run the tests using Weld or OWB: > {code} > mvn clean test -PWeld //it fails on ExtensionInJarTest > mvn clean test -POWB //it fails on ExtensionInJarTest > {code} > The expected behaviour is that Weld and OWB shouldn't fail. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Feb 24 07:22:49 2015 From: issues at jboss.org (Emond Papegaaij (JIRA)) Date: Tue, 24 Feb 2015 07:22:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1925) @After no longer runs within transaction boundaries since 1.1.7 In-Reply-To: References: Message-ID: Emond Papegaaij created ARQ-1925: ------------------------------------ Summary: @After no longer runs within transaction boundaries since 1.1.7 Key: ARQ-1925 URL: https://issues.jboss.org/browse/ARQ-1925 Project: Arquillian Issue Type: Feature Request Components: Extension - Transaction Affects Versions: 1.1.7.Final, transaction_1.0.1.Final Reporter: Emond Papegaaij With the changes in TestLifecycleEvents introduced in Arquillian core 1.1.7, the @After junit methods no longer run within the transaction boundaries. In TransactionHandler.endTransactionAfterTest, first the transaction is ended and then the event proceeds, calling @After methods. I've created a pull request that switches these call, this fixes our testcases. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Feb 24 07:22:49 2015 From: issues at jboss.org (Emond Papegaaij (JIRA)) Date: Tue, 24 Feb 2015 07:22:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1925) @After no longer runs within transaction boundaries since 1.1.7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emond Papegaaij updated ARQ-1925: --------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-transaction/pull/10 > @After no longer runs within transaction boundaries since 1.1.7 > --------------------------------------------------------------- > > Key: ARQ-1925 > URL: https://issues.jboss.org/browse/ARQ-1925 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Transaction > Affects Versions: transaction_1.0.1.Final, 1.1.7.Final > Reporter: Emond Papegaaij > > With the changes in TestLifecycleEvents introduced in Arquillian core 1.1.7, the @After junit methods no longer run within the transaction boundaries. In TransactionHandler.endTransactionAfterTest, first the transaction is ended and then the event proceeds, calling @After methods. > I've created a pull request that switches these call, this fixes our testcases. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Feb 24 07:24:49 2015 From: issues at jboss.org (Emond Papegaaij (JIRA)) Date: Tue, 24 Feb 2015 07:24:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1925) @After no longer runs within transaction boundaries since 1.1.7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043124#comment-13043124 ] Emond Papegaaij commented on ARQ-1925: -------------------------------------- The pull request includes the pull request for ARQ-1842, which is not yet merged. > @After no longer runs within transaction boundaries since 1.1.7 > --------------------------------------------------------------- > > Key: ARQ-1925 > URL: https://issues.jboss.org/browse/ARQ-1925 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Transaction > Affects Versions: transaction_1.0.1.Final, 1.1.7.Final > Reporter: Emond Papegaaij > > With the changes in TestLifecycleEvents introduced in Arquillian core 1.1.7, the @After junit methods no longer run within the transaction boundaries. In TransactionHandler.endTransactionAfterTest, first the transaction is ended and then the event proceeds, calling @After methods. > I've created a pull request that switches these call, this fixes our testcases. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Feb 24 07:59:49 2015 From: issues at jboss.org (Martijn Dashorst (JIRA)) Date: Tue, 24 Feb 2015 07:59:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1926) ARQ-1842 Show original exception instead of NullPointerExcetpion from TransactionHandler In-Reply-To: References: Message-ID: Martijn Dashorst created ARQ-1926: ------------------------------------- Summary: ARQ-1842 Show original exception instead of NullPointerExcetpion from TransactionHandler Key: ARQ-1926 URL: https://issues.jboss.org/browse/ARQ-1926 Project: Arquillian Issue Type: Bug Components: Extension - Transaction Affects Versions: 1.1.7.Final, 1.1.6.Final Reporter: Martijn Dashorst This is a duplicate of ARQ-1842, but assigned to the proper component (1842 is assigned to core, this one to extension-transaction) ARQ-1842 has a pull request solving this issue. See ARQ-1842 Show original exception instead of NullPointerExcetpion from TransactionHandler -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 25 10:48:51 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 25 Feb 2015 10:48:51 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1919) Android SDK with no images fails while testing on physical device In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1919. ------------------------------------ Fix Version/s: droidium_1.0.0.Beta1 Resolution: Done https://github.com/arquillian/arquillian-droidium/commit/60b460ff5c332c52aa26369bd6e647610c544447 > Android SDK with no images fails while testing on physical device > ----------------------------------------------------------------- > > Key: ARQ-1919 > URL: https://issues.jboss.org/browse/ARQ-1919 > Project: Arquillian > Issue Type: Bug > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Beta1 > > > When you want to test on a physical device, there is not any need to have system images installed. This issue is rarely hit in practice, however when using Droidium in CI environment, testing on physical device and not requiring system images to be even installed is major performance improvement. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 25 15:57:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 25 Feb 2015 15:57:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1920) Update Droidium to use Selendroid 0.14.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1920. ------------------------------------ Fix Version/s: droidium_1.0.0.Beta1 Resolution: Done https://github.com/arquillian/arquillian-droidium/commit/a2701e324134ceea51cf65cb0f96ead9ffd5d297 > Update Droidium to use Selendroid 0.14.0 > ---------------------------------------- > > Key: ARQ-1920 > URL: https://issues.jboss.org/browse/ARQ-1920 > Project: Arquillian > Issue Type: Task > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 25 17:14:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 25 Feb 2015 17:14:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1918) Update Recorder to Arquillian 1.1.7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043762#comment-13043762 ] Stefan Miklosovic commented on ARQ-1918: ---------------------------------------- [~aslak] https://github.com/arquillian/arquillian-recorder/blob/794cecd3c3c9c7ff87ab6f2a1d664cd71995f815/arquillian-recorder-reporter/arquillian-recorder-reporter-impl/src/main/java/org/arquillian/recorder/reporter/impl/ReporterLifecycleObserver.java#L163-L183 https://github.com/arquillian/arquillian-recorder/blob/794cecd3c3c9c7ff87ab6f2a1d664cd71995f815/arquillian-recorder-reporter/arquillian-recorder-reporter-impl/src/main/java/org/arquillian/recorder/reporter/impl/ReporterLifecycleObserver.java#L188-L210 > Update Recorder to Arquillian 1.1.7 > ----------------------------------- > > Key: ARQ-1918 > URL: https://issues.jboss.org/browse/ARQ-1918 > Project: Arquillian > Issue Type: Task > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Beta1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: recorder_1.0.0.Final > > > involve neccessary changes introduced with Before/AfterRules eventing. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 25 17:14:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 25 Feb 2015 17:14:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1918) Update Recorder to Arquillian 1.1.7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1918. ------------------------------------ Fix Version/s: recorder_1.0.0.Final Resolution: Done > Update Recorder to Arquillian 1.1.7 > ----------------------------------- > > Key: ARQ-1918 > URL: https://issues.jboss.org/browse/ARQ-1918 > Project: Arquillian > Issue Type: Task > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Beta1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: recorder_1.0.0.Final > > > involve neccessary changes introduced with Before/AfterRules eventing. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 25 18:29:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 25 Feb 2015 18:29:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1922) Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1922: ----------------------------------- Fix Version/s: spacelift_1.0.0.Alpha6 > Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions > ---------------------------------------------------------------------------------------------------- > > Key: ARQ-1922 > URL: https://issues.jboss.org/browse/ARQ-1922 > Project: Arquillian > Issue Type: Bug > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha5 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: spacelift_1.0.0.Alpha6 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 25 18:30:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 25 Feb 2015 18:30:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1922) Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1922. ---------------------------------- > Undeleted ArquillianSpaceliftExtension file prevents Spacelift from usage with Arquillian extensions > ---------------------------------------------------------------------------------------------------- > > Key: ARQ-1922 > URL: https://issues.jboss.org/browse/ARQ-1922 > Project: Arquillian > Issue Type: Bug > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha5 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: spacelift_1.0.0.Alpha6 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 25 18:35:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 25 Feb 2015 18:35:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1921) ResourceProvider SPI should differentiate between Class and Method injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043769#comment-13043769 ] Stefan Miklosovic commented on ARQ-1921: ---------------------------------------- [~aslak] you mean like you get it in lookup method in "Annotation... qualifiers" parameter? How these annotations would be called? I can look at it. > ResourceProvider SPI should differentiate between Class and Method injection > ---------------------------------------------------------------------------- > > Key: ARQ-1921 > URL: https://issues.jboss.org/browse/ARQ-1921 > Project: Arquillian > Issue Type: Feature Request > Components: Runtime Enricher SPI > Affects Versions: 1.1.7.Final > Reporter: Aslak Knutsen > Fix For: 1.1.8.Final > > > If a ResourceEnricher wants to have differently scoped objects based on this being injected on Class level or Method level the ResourceProvider SPI needs to relay this information somehow. Currently this is hidden. > An easy fix without breaking the SPI signature would be to add a Class/Method Qualifier annotation that's auto provided by the ResourceProvider impl. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Feb 26 02:16:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 26 Feb 2015 02:16:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1921) ResourceProvider SPI should differentiate between Class and Method injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043805#comment-13043805 ] Aslak Knutsen commented on ARQ-1921: ------------------------------------ [~smikloso] yea, I was just thinking adding two inner annotations to the ResourceProvider interface. Then passing them down as part of the Qualifiers. Perhaps named something like Class|MethodType. or Class|MethodInjection > ResourceProvider SPI should differentiate between Class and Method injection > ---------------------------------------------------------------------------- > > Key: ARQ-1921 > URL: https://issues.jboss.org/browse/ARQ-1921 > Project: Arquillian > Issue Type: Feature Request > Components: Runtime Enricher SPI > Affects Versions: 1.1.7.Final > Reporter: Aslak Knutsen > Fix For: 1.1.8.Final > > > If a ResourceEnricher wants to have differently scoped objects based on this being injected on Class level or Method level the ResourceProvider SPI needs to relay this information somehow. Currently this is hidden. > An easy fix without breaking the SPI signature would be to add a Class/Method Qualifier annotation that's auto provided by the ResourceProvider impl. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Feb 26 10:21:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Thu, 26 Feb 2015 10:21:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1921) ResourceProvider SPI should differentiate between Class and Method injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned ARQ-1921: -------------------------------------- Assignee: Stefan Miklosovic > ResourceProvider SPI should differentiate between Class and Method injection > ---------------------------------------------------------------------------- > > Key: ARQ-1921 > URL: https://issues.jboss.org/browse/ARQ-1921 > Project: Arquillian > Issue Type: Feature Request > Components: Runtime Enricher SPI > Affects Versions: 1.1.7.Final > Reporter: Aslak Knutsen > Assignee: Stefan Miklosovic > Fix For: 1.1.8.Final > > > If a ResourceEnricher wants to have differently scoped objects based on this being injected on Class level or Method level the ResourceProvider SPI needs to relay this information somehow. Currently this is hidden. > An easy fix without breaking the SPI signature would be to add a Class/Method Qualifier annotation that's auto provided by the ResourceProvider impl. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Feb 26 10:21:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Thu, 26 Feb 2015 10:21:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1921) ResourceProvider SPI should differentiate between Class and Method injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1921: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/81 > ResourceProvider SPI should differentiate between Class and Method injection > ---------------------------------------------------------------------------- > > Key: ARQ-1921 > URL: https://issues.jboss.org/browse/ARQ-1921 > Project: Arquillian > Issue Type: Feature Request > Components: Runtime Enricher SPI > Affects Versions: 1.1.7.Final > Reporter: Aslak Knutsen > Assignee: Stefan Miklosovic > Fix For: 1.1.8.Final > > > If a ResourceEnricher wants to have differently scoped objects based on this being injected on Class level or Method level the ResourceProvider SPI needs to relay this information somehow. Currently this is hidden. > An easy fix without breaking the SPI signature would be to add a Class/Method Qualifier annotation that's auto provided by the ResourceProvider impl. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Feb 26 14:19:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 26 Feb 2015 14:19:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1921) ResourceProvider SPI should differentiate between Class and Method injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1921: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/597373b680ddd361a8763ccc931033d9cb9c43e5 > ResourceProvider SPI should differentiate between Class and Method injection > ---------------------------------------------------------------------------- > > Key: ARQ-1921 > URL: https://issues.jboss.org/browse/ARQ-1921 > Project: Arquillian > Issue Type: Feature Request > Components: Runtime Enricher SPI > Affects Versions: 1.1.7.Final > Reporter: Aslak Knutsen > Assignee: Stefan Miklosovic > Fix For: 1.1.8.Final > > > If a ResourceEnricher wants to have differently scoped objects based on this being injected on Class level or Method level the ResourceProvider SPI needs to relay this information somehow. Currently this is hidden. > An easy fix without breaking the SPI signature would be to add a Class/Method Qualifier annotation that's auto provided by the ResourceProvider impl. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Feb 27 08:43:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Fri, 27 Feb 2015 08:43:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1927) Make use of TCCL in ARQ ManagedContainer configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler moved WFLY-4394 to ARQ-1927: ------------------------------------------- Project: Arquillian (was: WildFly) Key: ARQ-1927 (was: WFLY-4394) Component/s: (was: Test Suite) Fix Version/s: 1.1.8.Final (was: 9.0.0.Beta1) > Make use of TCCL in ARQ ManagedContainer configurable > ----------------------------------------------------- > > Key: ARQ-1927 > URL: https://issues.jboss.org/browse/ARQ-1927 > Project: Arquillian > Issue Type: Feature Request > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: 1.1.8.Final > > > In WildFly it is considerred intended behaviour that test code gets called with the TCCL set to the test deployment. IMHO this shadows potential problems when the functionality under test is not called from an ARQ test case (i.e. from an normal javaee endpoint) > For Camel integration this behaviour is not acceptable. > CrossLink: https://github.com/wildfly-extras/wildfly-camel/issues/340 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Feb 27 09:04:49 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Fri, 27 Feb 2015 09:04:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1927) Make use of TCCL in ARQ ManagedContainer configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler updated ARQ-1927: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/82 > Make use of TCCL in ARQ ManagedContainer configurable > ----------------------------------------------------- > > Key: ARQ-1927 > URL: https://issues.jboss.org/browse/ARQ-1927 > Project: Arquillian > Issue Type: Feature Request > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: 1.1.8.Final > > > In WildFly it is considerred intended behaviour that test code gets called with the TCCL set to the test deployment. IMHO this shadows potential problems when the functionality under test is not called from an ARQ test case (i.e. from an normal javaee endpoint) > For Camel integration this behaviour is not acceptable. > CrossLink: https://github.com/wildfly-extras/wildfly-camel/issues/340 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sat Feb 28 08:20:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sat, 28 Feb 2015 08:20:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1918) Update Recorder to Arquillian 1.1.7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1918. ---------------------------------- > Update Recorder to Arquillian 1.1.7 > ----------------------------------- > > Key: ARQ-1918 > URL: https://issues.jboss.org/browse/ARQ-1918 > Project: Arquillian > Issue Type: Task > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Beta1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: recorder_1.0.0.Final > > > involve neccessary changes introduced with Before/AfterRules eventing. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sat Feb 28 08:41:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sat, 28 Feb 2015 08:41:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1928) Update Droidium to use Arquillian Recorder 1.0.0.Final In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1928: -------------------------------------- Summary: Update Droidium to use Arquillian Recorder 1.0.0.Final Key: ARQ-1928 URL: https://issues.jboss.org/browse/ARQ-1928 Project: Arquillian Issue Type: Task Components: Extension - Droidium Affects Versions: droidium_1.0.0.Alpha6 Reporter: Stefan Miklosovic -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sat Feb 28 08:42:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sat, 28 Feb 2015 08:42:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1928) Update Droidium to use Arquillian Recorder 1.0.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned ARQ-1928: -------------------------------------- Assignee: Stefan Miklosovic > Update Droidium to use Arquillian Recorder 1.0.0.Final > ------------------------------------------------------ > > Key: ARQ-1928 > URL: https://issues.jboss.org/browse/ARQ-1928 > Project: Arquillian > Issue Type: Task > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sat Feb 28 08:50:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sat, 28 Feb 2015 08:50:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1928) Update Droidium to use Arquillian Recorder 1.0.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1928. ------------------------------------ Resolution: Done https://github.com/arquillian/arquillian-droidium/commit/30b4ce6260e31fb50c9744b22796874aaa6d6446 > Update Droidium to use Arquillian Recorder 1.0.0.Final > ------------------------------------------------------ > > Key: ARQ-1928 > URL: https://issues.jboss.org/browse/ARQ-1928 > Project: Arquillian > Issue Type: Task > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sat Feb 28 08:51:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Sat, 28 Feb 2015 08:51:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1916) Update Droidium to Arquillian 1.1.7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1916. ------------------------------------ Resolution: Done https://github.com/arquillian/arquillian-droidium/commit/1841e9e11dc1aedbb6fdf8b7870f9a5c27f559c2 > Update Droidium to Arquillian 1.1.7 > ----------------------------------- > > Key: ARQ-1916 > URL: https://issues.jboss.org/browse/ARQ-1916 > Project: Arquillian > Issue Type: Task > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha6 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341)