From issues at jboss.org Fri Jan 2 06:18:30 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Fri, 2 Jan 2015 06:18:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1894) Deleted videos appear in resulting report In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1894: -------------------------------------- Summary: Deleted videos appear in resulting report Key: ARQ-1894 URL: https://issues.jboss.org/browse/ARQ-1894 Project: Arquillian Issue Type: Bug Components: Extension - Recorder Affects Versions: recorder_1.0.0.Alpha4 Reporter: Stefan Miklosovic -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 2 06:19:30 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Fri, 2 Jan 2015 06:19:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1894) Deleted videos appear in resulting report In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned ARQ-1894: -------------------------------------- Assignee: Stefan Miklosovic > Deleted videos appear in resulting report > ----------------------------------------- > > Key: ARQ-1894 > URL: https://issues.jboss.org/browse/ARQ-1894 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Alpha4 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 2 12:55:29 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Fri, 2 Jan 2015 12:55:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1895) Implement video recorder for Droidium In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1895: -------------------------------------- Summary: 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 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 Fri Jan 2 12:55:29 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Fri, 2 Jan 2015 12:55:29 -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 reassigned ARQ-1895: -------------------------------------- Assignee: Stefan Miklosovic > 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 > > 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 Fri Jan 2 12:55:30 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Fri, 2 Jan 2015 12:55:30 -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 ] Work on ARQ-1895 started by Stefan Miklosovic. ---------------------------------------------- > 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 > > 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 Mon Jan 5 11:14:29 2015 From: issues at jboss.org (John Poth (JIRA)) Date: Mon, 5 Jan 2015 11:14:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1896) Make JMX objectname configurable for JMXTestRunner and JMXMethodExecutor In-Reply-To: References: Message-ID: John Poth created ARQ-1896: ------------------------------ Summary: Make JMX objectname configurable for JMXTestRunner and JMXMethodExecutor Key: ARQ-1896 URL: https://issues.jboss.org/browse/ARQ-1896 Project: Arquillian Issue Type: Feature Request Components: Base Implementation Affects Versions: 1.1.6.Final Reporter: John Poth Currently, JMXTestRunner#runTestMethod(String className, String methodName) expects to find the test class and run the test method using the classloader set in the constructor. This is a problem when my tests are expected to run inside different containers (hence different classloaders). One easy work around is to publish one JMXTestRunner per container (hence unique objectname has to be provided to avoid conflict). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 5 11:24:29 2015 From: issues at jboss.org (John Poth (JIRA)) Date: Mon, 5 Jan 2015 11:24:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1896) Make JMX objectname configurable for JMXTestRunner and JMXMethodExecutor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Poth updated ARQ-1896: --------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/74 Simple commit. Everything is in the pull request description. > Make JMX objectname configurable for JMXTestRunner and JMXMethodExecutor > ------------------------------------------------------------------------ > > Key: ARQ-1896 > URL: https://issues.jboss.org/browse/ARQ-1896 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.6.Final > Reporter: John Poth > > Currently, JMXTestRunner#runTestMethod(String className, String methodName) expects to find the test class and run the test method using the classloader set in the constructor. This is a problem when my tests are expected to run inside different containers (hence different classloaders). One easy work around is to publish one JMXTestRunner per container (hence unique objectname has to be provided to avoid conflict). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 5 11:27:31 2015 From: issues at jboss.org (Michal Vanco (JIRA)) Date: Mon, 5 Jan 2015 11:27:31 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-127) Verify TestNG Parallel test exeuction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029955#comment-13029955 ] Michal Vanco commented on ARQ-127: ---------------------------------- Hi Aslak (and others), today I came back to this issue after some time as it's still seems to be a critical thing which we would appreciate with arquillian-testng-stangalone library. I still used the same example just with updated dependencies. I tried some hacking at Arquillian.class and it seems like the usage of ThreadLocal is breaking this TestNG parallelism feature... {noformat} ... Running TestSuite BEFORE SUITE, runner:null Going to set test runner:org.jboss.arquillian.test.impl.EventTestRunnerAdaptor at 266c6ce1, threadLocal:java.lang.ThreadLocal at 18603b7c BEFORE CLASS, runner:null BEFORE CLASS, runner:null AFTER TEST, runner:null AFTER TEST, runner:null AFTER TEST, runner:null AFTER TEST, runner:null AFTER TEST, runner:null AFTER TEST, runner:null AFTER CLASS, runner:null AFTER CLASS, runner:null AFTER SUITE, runner:org.jboss.arquillian.test.impl.EventTestRunnerAdaptor at 266c6ce1 {noformat} It's initialized once at the suite level, but none of the class/test methods are able to access it and it ends up with same message: {noformat} java.lang.IllegalStateException: No TestRunnerAdaptor found, @BeforeSuite has not been called at org.jboss.arquillian.testng.Arquillian.verifyTestRunnerAdaptorHasBeenSet(Arquillian.java:252) at org.jboss.arquillian.testng.Arquillian.arquillianBeforeClass(Arquillian.java:104) {noformat} [~aslak] - can you please confirm that there is any chance that Arquillian will be sometime able to handle this kind of parallelism (at least on class level)? Or maybe there is some quick hint you can provide... or should I just forget this requirement or workaround it at "ugly way"? Thanks a lot for your help! And I also thanks [~lfryc] for his help and support :) > Verify TestNG Parallel test exeuction > ------------------------------------- > > Key: ARQ-127 > URL: https://issues.jboss.org/browse/ARQ-127 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Performance, Test Harness Integration > Reporter: Aslak Knutsen > Assignee: St?le Pedersen > Priority: Critical > Fix For: 2.0.0.Beta1 > > Attachments: testng-parallel.zip > > > Verify that Arquillian behaves correctly when ran in TestNG Parallel modes. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 6 02:35:29 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 6 Jan 2015 02:35:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQRUSH-27) Implement change in structure: suite -> case* -> test* -> patterns+ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQRUSH-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQRUSH-27: --------------------------------- Assignee: (was: Luk?? Fry?) > Implement change in structure: suite -> case* -> test* -> patterns+ > ------------------------------------------------------------------- > > Key: ARQRUSH-27 > URL: https://issues.jboss.org/browse/ARQRUSH-27 > Project: Arquillian RushEye > Issue Type: Task > Components: Core, Manager > Reporter: Luk?? Fry? > Priority: Blocker > Fix For: 1.0.0.Alpha1 > > > To reflect test suites, Core should contain concept of {{case}} as container for tests. > {{test}} then forms a base for one comparison. > The new structure reflects how real functional tests maps to its output > * one functional test method = one case > * one functional test transition (image change) = one test > See ARQRUSH-26 > Support detection of changes in cases and tests (removals, additions, modifications) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 6 10:50:30 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 6 Jan 2015 10:50:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1897) Converting to time unit from miliseconds for CountDownWatch#timeLeft() is not necessary In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1897: -------------------------------------- Summary: Converting to time unit from miliseconds for CountDownWatch#timeLeft() is not necessary Key: ARQ-1897 URL: https://issues.jboss.org/browse/ARQ-1897 Project: Arquillian Issue Type: Bug Components: Extension - Spacelift Affects Versions: spacelift_1.0.0.Alpha3 Reporter: Stefan Miklosovic -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 6 10:57:29 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 6 Jan 2015 10:57:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1897) Converting to time unit from miliseconds for CountDownWatch#timeLeft() is not necessary In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1897. ------------------------------------ Assignee: Stefan Miklosovic Fix Version/s: spacelift_1.0.0.Alpha4 Resolution: Done https://github.com/arquillian/arquillian-spacelift/commit/db95c47cafc9f901a2fb23bbbfbdae73c9d04fe4 > Converting to time unit from miliseconds for CountDownWatch#timeLeft() is not necessary > --------------------------------------------------------------------------------------- > > Key: ARQ-1897 > URL: https://issues.jboss.org/browse/ARQ-1897 > Project: Arquillian > Issue Type: Bug > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha3 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: spacelift_1.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 8 08:13:29 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Thu, 8 Jan 2015 08:13:29 -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 resolved ARQ-1895. ------------------------------------ Fix Version/s: droidium_1.0.0.Beta1 Resolution: Done > 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.Beta1 > > > 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 Fri Jan 9 06:09:29 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Fri, 9 Jan 2015 06:09:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1898) Provide ExecutionServiceFactory instance by default In-Reply-To: References: Message-ID: Karel Piwko created ARQ-1898: -------------------------------- Summary: Provide ExecutionServiceFactory instance by default Key: ARQ-1898 URL: https://issues.jboss.org/browse/ARQ-1898 Project: Arquillian Issue Type: Feature Request Components: Extension - Spacelift Affects Versions: spacelift_1.0.0.Alpha3 Reporter: Karel Piwko ExecutionServiceFactory should be instantiated by default. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:12:29 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Fri, 9 Jan 2015 06:12:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1898) Provide ExecutionServiceFactory instance by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko resolved ARQ-1898. ------------------------------ Assignee: Karel Piwko Fix Version/s: spacelift_1.0.0.Alpha4 Resolution: Done Fixed in https://github.com/arquillian/arquillian-spacelift/commit/35ff36adf8b7d74d0cc5ce1216faf794780abb42 > Provide ExecutionServiceFactory instance by default > --------------------------------------------------- > > Key: ARQ-1898 > URL: https://issues.jboss.org/browse/ARQ-1898 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha3 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: spacelift_1.0.0.Alpha4 > > > ExecutionServiceFactory should be instantiated by default. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:28:29 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:28:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1760) Replace the WebLogic.Deployer deployment mechanism with JMX for WLS 12.1.2 and higher In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1760: ------------------------------- Fix Version/s: wls_1.0.0.Alpha3 (was: wls_1.0.0.next) > Replace the WebLogic.Deployer deployment mechanism with JMX for WLS 12.1.2 and higher > ------------------------------------------------------------------------------------- > > Key: ARQ-1760 > URL: https://issues.jboss.org/browse/ARQ-1760 > Project: Arquillian > Issue Type: Feature Request > Components: WebLogic Containers > Affects Versions: wls_1.0.0.Alpha2 > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: wls_1.0.0.Alpha3 > > > Replace the error prone WebLogic.Deployer based deployment mechanism with the JMX based deployer for WLS 12.1.2 (and higher version of WLS). The older deployment mechanism would however need to be in use for older versions of WLS since they do not have support for JMX based deployment of applications. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:29:40 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:29:40 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-784) The wlsHome property of the WebLogic containers should default to a pre-defined environment variable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-784: ------------------------------ Fix Version/s: wls_1.0.0.Alpha3 (was: wls_1.0.0.next) > The wlsHome property of the WebLogic containers should default to a pre-defined environment variable > ---------------------------------------------------------------------------------------------------- > > Key: ARQ-784 > URL: https://issues.jboss.org/browse/ARQ-784 > Project: Arquillian > Issue Type: Enhancement > Components: WebLogic Containers > Affects Versions: wls_1.0.0.Alpha1, wls_1.0.0.Alpha2 > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: wls_1.0.0.Alpha3 > > > The `wlsHome` property does not have a default value at present, and users are expected to specify this in arquillian.xml; a system property could be used in arquillian.xml, but this would require Surefire or the test-execution environment to pass an existing environment variable as a system property. > It would useful to default this to the `WL_HOME` environment variable to preserve the intent of the property. However, we could consider using the `WLS_HOME` environment variable (this points to the `WL_HOME/server` directory) since all usages refer to resources in the server sub-directory. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:29:40 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:29:40 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1183) Allow the use of non-blocking random number generators for deployments against WebLogic Servers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1183: ------------------------------- Fix Version/s: wls_1.0.0.Alpha3 (was: wls_1.0.0.next) > Allow the use of non-blocking random number generators for deployments against WebLogic Servers > ----------------------------------------------------------------------------------------------- > > Key: ARQ-1183 > URL: https://issues.jboss.org/browse/ARQ-1183 > Project: Arquillian > Issue Type: Enhancement > Components: WebLogic Containers > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Priority: Minor > Fix For: wls_1.0.0.Alpha3 > > > The WLS container adapter forks a {{weblogic.Deployer}} task that runs in a separate JVM. This may result in timeouts on Unix/Linux machines where /dev/random does not provide sufficient entropy in a limited period of time. This eventually results in random and inexplicable failures during deployment or undeployment of archives when connecting to an AdminServer through a SSL channel. The stacktraces usually contain errors with the message "java.io.IOException: Stream closed.; No available router to destination". > Allow for configuring /dev/urandom as a PRNG source. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:30:29 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:30:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1184) Use wljmxclient.jar instead of weblogic.jar in the searchpath of the WebLogic JMX client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1184: ------------------------------- Fix Version/s: wls_1.0.0.Alpha3 (was: wls_1.0.0.next) > Use wljmxclient.jar instead of weblogic.jar in the searchpath of the WebLogic JMX client > ---------------------------------------------------------------------------------------- > > Key: ARQ-1184 > URL: https://issues.jboss.org/browse/ARQ-1184 > Project: Arquillian > Issue Type: Enhancement > Components: WebLogic Containers > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: wls_1.0.0.Alpha3 > > > The {{WebLogicJMXLibClassLoader}} currently loads classes from weblogic.jar instead of using the documented. This was done during resolution of ARQ-725 to avoid initialization of a Java SecurityManager, but this is a bad idea in retrospect considering that the use of weblogic.jar may be unsupported and that internal details of WebLogic Server may change in the future. > Therefore, the default search path for the {{WebLogicJMXLibClassLoader}} would be changed from weblogic.jar to wljmxclient.jar. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:30:29 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:30:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-785) Implement a managed WebLogic Server container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-785: ------------------------------ Fix Version/s: wls_1.0.0.Alpha3 (was: wls_1.0.0.next) > Implement a managed WebLogic Server container > --------------------------------------------- > > Key: ARQ-785 > URL: https://issues.jboss.org/browse/ARQ-785 > Project: Arquillian > Issue Type: Feature Request > Components: WebLogic Containers > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Priority: Minor > Fix For: wls_1.0.0.Alpha3 > > > Currently, we have support for remote WebLogic Server containers. We ought to explore the possibility of bringing in support for managed WebLogic Server containers, via the use of startWebLogic/startManagedWebLogic and stopWebLogic/stopManagedWebLogic scripts. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:30:29 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:30:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1173) Remove the javaHome configuration property for the WLS containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1173: ------------------------------- Fix Version/s: wls_1.0.0.Alpha3 (was: wls_1.0.0.next) > Remove the javaHome configuration property for the WLS containers > ----------------------------------------------------------------- > > Key: ARQ-1173 > URL: https://issues.jboss.org/browse/ARQ-1173 > Project: Arquillian > Issue Type: Enhancement > Components: WebLogic Containers > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Priority: Minor > Fix For: wls_1.0.0.Alpha3 > > > The javaHome property in the {{CommonWebLogicConfiguration}} class is and never was utilized by the container. Remove the property to avoid confusing users of it's purpose. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:31:30 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:31:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1122) ServletRuntime lookup only returns servlets of first web application found In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1122: ------------------------------- Fix Version/s: wls_1.0.0.Alpha3 (was: wls_1.0.0.next) > ServletRuntime lookup only returns servlets of first web application found > -------------------------------------------------------------------------- > > Key: ARQ-1122 > URL: https://issues.jboss.org/browse/ARQ-1122 > Project: Arquillian > Issue Type: Enhancement > Components: WebLogic Containers > Affects Versions: 1.0.2.Final > Environment: Weblogic 12c > Reporter: Ralph Abbink > Assignee: Vineet Reynolds > Priority: Minor > Fix For: wls_1.0.0.Alpha3 > > > After enriching our regular maven built .ear i noticed the following exception: {noformat}ArquillianServletRunner not found. Could not determine ContextRoot from ProtocolMetadata, please contact DeployableContainer developer.{noformat} > It appears the lookup for servletRuntimes only returns the servlets of the first web application in the deployment. In our .ear we have several web modules and the first one found wasn't the module i enriched using Arquillian. > {code:title=WebLogicJMXClient.java} > private ObjectName[] findServletRuntimes(ObjectName wlServerRuntime, String deploymentName) throws Exception > { > ObjectName[] applicationRuntimes = (ObjectName[]) connection.getAttribute(wlServerRuntime, "ApplicationRuntimes"); > for(ObjectName applicationRuntime: applicationRuntimes) > { > String applicationName = (String) connection.getAttribute(applicationRuntime, "Name"); > if(applicationName.equals(deploymentName)) > { > ObjectName[] componentRuntimes = (ObjectName[]) connection.getAttribute(applicationRuntime, "ComponentRuntimes"); > for(ObjectName componentRuntime : componentRuntimes) > { > String componentType = (String) connection.getAttribute(componentRuntime, "Type"); > if (componentType.toString().equals("WebAppComponentRuntime")) > { > ObjectName[] servletRuntimes = (ObjectName[]) connection.getAttribute(componentRuntime, "Servlets"); > return servletRuntimes; > } > } > } > } > throw new DeploymentException( > "The deployment details were not found in the MBean Server. Possible causes include:\n" > + "1. The deployment failed. Review the admin server and the target's log files.\n" > + "2. The deployment succeeded partially. The deployment must be the Active state. Instead, it might be in the 'New' state.\n" > + " Verify that the the admin server can connect to the target(s), and that no firewall rules are blocking the traffic on the admin channel."); > } > {code} > {code:title="Returning all servlets found" WebLogicJMXClient.java} > private List findServletRuntimes(ObjectName wlServerRuntime, String deploymentName) throws Exception > { > ObjectName[] applicationRuntimes = (ObjectName[]) connection.getAttribute(wlServerRuntime, "ApplicationRuntimes"); > for(ObjectName applicationRuntime: applicationRuntimes) > { > String applicationName = (String) connection.getAttribute(applicationRuntime, "Name"); > if(applicationName.equals(deploymentName)) > { > List servletRuntimes = new ArrayList(); > ObjectName[] componentRuntimes = (ObjectName[]) connection.getAttribute(applicationRuntime, "ComponentRuntimes"); > for(ObjectName componentRuntime : componentRuntimes) > { > String componentType = (String) connection.getAttribute(componentRuntime, "Type"); > if (componentType.toString().equals("WebAppComponentRuntime")) > { > servletRuntimes.addAll(Arrays.asList((ObjectName[]) connection.getAttribute(componentRuntime, "Servlets"))); > } > } > return servletRuntimes; > } > } > throw new DeploymentException( > "The deployment details were not found in the MBean Server. Possible causes include:\n" > + "1. The deployment failed. Review the admin server and the target's log files.\n" > + "2. The deployment succeeded partially. The deployment must be the Active state. Instead, it might be in the 'New' state.\n" > + " Verify that the the admin server can connect to the target(s), and that no firewall rules are blocking the traffic on the admin channel."); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:31:30 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:31:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1133) Upgrade to Arquillian core 1.0.2.Final for WebLogic Containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1133: ------------------------------- Fix Version/s: wls_1.0.0.Alpha3 (was: wls_1.0.0.next) > Upgrade to Arquillian core 1.0.2.Final for WebLogic Containers > --------------------------------------------------------------- > > Key: ARQ-1133 > URL: https://issues.jboss.org/browse/ARQ-1133 > Project: Arquillian > Issue Type: Component Upgrade > Components: WebLogic Containers > Affects Versions: wls_1.0.0.Alpha2 > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: wls_1.0.0.Alpha3 > > > Update the WebLogic containers to Arquillian Core 1.0.2.Final. > This is more to ensure that the tests for the container adapter can use the {{Testable}} API to define the archive to test. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:31:30 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:31:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1172) Implement an embedded WebLogic Server container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1172: ------------------------------- Fix Version/s: wls_1.0.0.Alpha3 (was: wls_1.0.0.next) > Implement an embedded WebLogic Server container > ----------------------------------------------- > > Key: ARQ-1172 > URL: https://issues.jboss.org/browse/ARQ-1172 > Project: Arquillian > Issue Type: Feature Request > Components: WebLogic Containers > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Priority: Minor > Fix For: wls_1.0.0.Alpha3 > > > WebLogic Server 12c supports EJB 3.1 and is hence expected to support testing of EJBs in an embedded container, at a minimum. > This feature request is to investigate implementation of the embedded Arquillian container for WLS 12c in particular. Support for an embedded mode of operation for WLS 10.3.x is to be investigated, and may be implemented if supported by Oracle (as documentated APIs or similar). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:32:30 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:32:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-784) The wlsHome property of the WebLogic containers should default to a pre-defined environment variable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-784. ----------------------------- > The wlsHome property of the WebLogic containers should default to a pre-defined environment variable > ---------------------------------------------------------------------------------------------------- > > Key: ARQ-784 > URL: https://issues.jboss.org/browse/ARQ-784 > Project: Arquillian > Issue Type: Enhancement > Components: WebLogic Containers > Affects Versions: wls_1.0.0.Alpha1, wls_1.0.0.Alpha2 > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: wls_1.0.0.Alpha3 > > > The `wlsHome` property does not have a default value at present, and users are expected to specify this in arquillian.xml; a system property could be used in arquillian.xml, but this would require Surefire or the test-execution environment to pass an existing environment variable as a system property. > It would useful to default this to the `WL_HOME` environment variable to preserve the intent of the property. However, we could consider using the `WLS_HOME` environment variable (this points to the `WL_HOME/server` directory) since all usages refer to resources in the server sub-directory. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:32:30 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:32:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1173) Remove the javaHome configuration property for the WLS containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1173. ------------------------------ > Remove the javaHome configuration property for the WLS containers > ----------------------------------------------------------------- > > Key: ARQ-1173 > URL: https://issues.jboss.org/browse/ARQ-1173 > Project: Arquillian > Issue Type: Enhancement > Components: WebLogic Containers > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Priority: Minor > Fix For: wls_1.0.0.Alpha3 > > > The javaHome property in the {{CommonWebLogicConfiguration}} class is and never was utilized by the container. Remove the property to avoid confusing users of it's purpose. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:32:30 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:32:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1172) Implement an embedded WebLogic Server container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1172. ------------------------------ > Implement an embedded WebLogic Server container > ----------------------------------------------- > > Key: ARQ-1172 > URL: https://issues.jboss.org/browse/ARQ-1172 > Project: Arquillian > Issue Type: Feature Request > Components: WebLogic Containers > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Priority: Minor > Fix For: wls_1.0.0.Alpha3 > > > WebLogic Server 12c supports EJB 3.1 and is hence expected to support testing of EJBs in an embedded container, at a minimum. > This feature request is to investigate implementation of the embedded Arquillian container for WLS 12c in particular. Support for an embedded mode of operation for WLS 10.3.x is to be investigated, and may be implemented if supported by Oracle (as documentated APIs or similar). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:32:30 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:32:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1183) Allow the use of non-blocking random number generators for deployments against WebLogic Servers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1183. ------------------------------ > Allow the use of non-blocking random number generators for deployments against WebLogic Servers > ----------------------------------------------------------------------------------------------- > > Key: ARQ-1183 > URL: https://issues.jboss.org/browse/ARQ-1183 > Project: Arquillian > Issue Type: Enhancement > Components: WebLogic Containers > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Priority: Minor > Fix For: wls_1.0.0.Alpha3 > > > The WLS container adapter forks a {{weblogic.Deployer}} task that runs in a separate JVM. This may result in timeouts on Unix/Linux machines where /dev/random does not provide sufficient entropy in a limited period of time. This eventually results in random and inexplicable failures during deployment or undeployment of archives when connecting to an AdminServer through a SSL channel. The stacktraces usually contain errors with the message "java.io.IOException: Stream closed.; No available router to destination". > Allow for configuring /dev/urandom as a PRNG source. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:32:30 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:32:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1760) Replace the WebLogic.Deployer deployment mechanism with JMX for WLS 12.1.2 and higher In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1760. ------------------------------ > Replace the WebLogic.Deployer deployment mechanism with JMX for WLS 12.1.2 and higher > ------------------------------------------------------------------------------------- > > Key: ARQ-1760 > URL: https://issues.jboss.org/browse/ARQ-1760 > Project: Arquillian > Issue Type: Feature Request > Components: WebLogic Containers > Affects Versions: wls_1.0.0.Alpha2 > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: wls_1.0.0.Alpha3 > > > Replace the error prone WebLogic.Deployer based deployment mechanism with the JMX based deployer for WLS 12.1.2 (and higher version of WLS). The older deployment mechanism would however need to be in use for older versions of WLS since they do not have support for JMX based deployment of applications. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:32:31 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:32:31 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1122) ServletRuntime lookup only returns servlets of first web application found In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1122. ------------------------------ > ServletRuntime lookup only returns servlets of first web application found > -------------------------------------------------------------------------- > > Key: ARQ-1122 > URL: https://issues.jboss.org/browse/ARQ-1122 > Project: Arquillian > Issue Type: Enhancement > Components: WebLogic Containers > Affects Versions: 1.0.2.Final > Environment: Weblogic 12c > Reporter: Ralph Abbink > Assignee: Vineet Reynolds > Priority: Minor > Fix For: wls_1.0.0.Alpha3 > > > After enriching our regular maven built .ear i noticed the following exception: {noformat}ArquillianServletRunner not found. Could not determine ContextRoot from ProtocolMetadata, please contact DeployableContainer developer.{noformat} > It appears the lookup for servletRuntimes only returns the servlets of the first web application in the deployment. In our .ear we have several web modules and the first one found wasn't the module i enriched using Arquillian. > {code:title=WebLogicJMXClient.java} > private ObjectName[] findServletRuntimes(ObjectName wlServerRuntime, String deploymentName) throws Exception > { > ObjectName[] applicationRuntimes = (ObjectName[]) connection.getAttribute(wlServerRuntime, "ApplicationRuntimes"); > for(ObjectName applicationRuntime: applicationRuntimes) > { > String applicationName = (String) connection.getAttribute(applicationRuntime, "Name"); > if(applicationName.equals(deploymentName)) > { > ObjectName[] componentRuntimes = (ObjectName[]) connection.getAttribute(applicationRuntime, "ComponentRuntimes"); > for(ObjectName componentRuntime : componentRuntimes) > { > String componentType = (String) connection.getAttribute(componentRuntime, "Type"); > if (componentType.toString().equals("WebAppComponentRuntime")) > { > ObjectName[] servletRuntimes = (ObjectName[]) connection.getAttribute(componentRuntime, "Servlets"); > return servletRuntimes; > } > } > } > } > throw new DeploymentException( > "The deployment details were not found in the MBean Server. Possible causes include:\n" > + "1. The deployment failed. Review the admin server and the target's log files.\n" > + "2. The deployment succeeded partially. The deployment must be the Active state. Instead, it might be in the 'New' state.\n" > + " Verify that the the admin server can connect to the target(s), and that no firewall rules are blocking the traffic on the admin channel."); > } > {code} > {code:title="Returning all servlets found" WebLogicJMXClient.java} > private List findServletRuntimes(ObjectName wlServerRuntime, String deploymentName) throws Exception > { > ObjectName[] applicationRuntimes = (ObjectName[]) connection.getAttribute(wlServerRuntime, "ApplicationRuntimes"); > for(ObjectName applicationRuntime: applicationRuntimes) > { > String applicationName = (String) connection.getAttribute(applicationRuntime, "Name"); > if(applicationName.equals(deploymentName)) > { > List servletRuntimes = new ArrayList(); > ObjectName[] componentRuntimes = (ObjectName[]) connection.getAttribute(applicationRuntime, "ComponentRuntimes"); > for(ObjectName componentRuntime : componentRuntimes) > { > String componentType = (String) connection.getAttribute(componentRuntime, "Type"); > if (componentType.toString().equals("WebAppComponentRuntime")) > { > servletRuntimes.addAll(Arrays.asList((ObjectName[]) connection.getAttribute(componentRuntime, "Servlets"))); > } > } > return servletRuntimes; > } > } > throw new DeploymentException( > "The deployment details were not found in the MBean Server. Possible causes include:\n" > + "1. The deployment failed. Review the admin server and the target's log files.\n" > + "2. The deployment succeeded partially. The deployment must be the Active state. Instead, it might be in the 'New' state.\n" > + " Verify that the the admin server can connect to the target(s), and that no firewall rules are blocking the traffic on the admin channel."); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:32:31 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:32:31 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-785) Implement a managed WebLogic Server container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-785. ----------------------------- > Implement a managed WebLogic Server container > --------------------------------------------- > > Key: ARQ-785 > URL: https://issues.jboss.org/browse/ARQ-785 > Project: Arquillian > Issue Type: Feature Request > Components: WebLogic Containers > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Priority: Minor > Fix For: wls_1.0.0.Alpha3 > > > Currently, we have support for remote WebLogic Server containers. We ought to explore the possibility of bringing in support for managed WebLogic Server containers, via the use of startWebLogic/startManagedWebLogic and stopWebLogic/stopManagedWebLogic scripts. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:32:31 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:32:31 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1184) Use wljmxclient.jar instead of weblogic.jar in the searchpath of the WebLogic JMX client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1184. ------------------------------ > Use wljmxclient.jar instead of weblogic.jar in the searchpath of the WebLogic JMX client > ---------------------------------------------------------------------------------------- > > Key: ARQ-1184 > URL: https://issues.jboss.org/browse/ARQ-1184 > Project: Arquillian > Issue Type: Enhancement > Components: WebLogic Containers > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: wls_1.0.0.Alpha3 > > > The {{WebLogicJMXLibClassLoader}} currently loads classes from weblogic.jar instead of using the documented. This was done during resolution of ARQ-725 to avoid initialization of a Java SecurityManager, but this is a bad idea in retrospect considering that the use of weblogic.jar may be unsupported and that internal details of WebLogic Server may change in the future. > Therefore, the default search path for the {{WebLogicJMXLibClassLoader}} would be changed from weblogic.jar to wljmxclient.jar. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 9 06:32:31 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Jan 2015 06:32:31 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1133) Upgrade to Arquillian core 1.0.2.Final for WebLogic Containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1133. ------------------------------ > Upgrade to Arquillian core 1.0.2.Final for WebLogic Containers > --------------------------------------------------------------- > > Key: ARQ-1133 > URL: https://issues.jboss.org/browse/ARQ-1133 > Project: Arquillian > Issue Type: Component Upgrade > Components: WebLogic Containers > Affects Versions: wls_1.0.0.Alpha2 > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: wls_1.0.0.Alpha3 > > > Update the WebLogic containers to Arquillian Core 1.0.2.Final. > This is more to ensure that the tests for the container adapter can use the {{Testable}} API to define the archive to test. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 11 15:56:49 2015 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Sun, 11 Jan 2015 15:56:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1889) CDI Injection not working in WebSphere Containers (V8) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031615#comment-13031615 ] Gerhard Poul commented on ARQ-1889: ----------------------------------- As part of ARQ-1488 I added a unit test for this: https://github.com/arquillian/arquillian-container-was/blob/master/was-remote-8/src/test/java/org/jboss/arquillian/container/was/remote_8/WebSphereClassInjectionTestCase.java - Is this working for you? - Would you be able to provide a test case that reproduces your issue? - Are you able to open PMRs with IBM in case we need one to progress this? > CDI Injection not working in WebSphere Containers (V8) > ------------------------------------------------------ > > Key: ARQ-1889 > URL: https://issues.jboss.org/browse/ARQ-1889 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Affects Versions: was_1.0.0.Beta1 > Environment: Windows 7, IBM WebSphere Application Server (8.0.0.9), IBM RSA 8 > Reporter: Saurabh Agarwal > Priority: Blocker > > Hi, > I have gone through ARQ-1488 and it depicts the same problem what I am facing. > In my IBM WebSphere Application Server (8.0.0.9), CDI is not working and it is giving me the NP exception. > Please note I am not using MAVEN build but have all required JARS file in my web-inf/lib directory > JARS List I am having > ------------------------------ > arquillian-config-api.jar > arquillian-config-impl-base.jar > arquillian-config-spi.jar > arquillian-container-impl-base.jar > arquillian-container-spi.jar > arquillian-container-test-api.jar > arquillian-container-test-impl-base.jar > arquillian-container-test-spi.jar > arquillian-core-api.jar > arquillian-core-impl-base-1.1.5.Final.jar > arquillian-core-spi-1.1.5.Final.jar > arquillian-junit-container.jar > arquillian-junit-core.jar > arquillian-protocol-jmx-1.1.5.Final.jar > arquillian-protocol-servlet.jar > arquillian-protocol.jar > arquillian-test-api.jar > arquillian-test-impl-base.jar > arquillian-test-spi.jar > arquillian-testenricher-cdi.jar > arquillian-testenricher-ejb.jar > arquillian-testenricher-initialcontext.jar > arquillian-testenricher-resource.jar > arquillian-was-remote.jar > commons-fileupload-1.2.1.jar > commons-io-1.4.jar > deltaspike-core-api-1.0.0.jar > deltaspike-core-impl-1.0.0.jar > deltaspike-jsf-module-api-1.0.0.jar > deltaspike-jsf-module-impl-1.0.0.jar > deltaspike-security-module-api-1.0.0.jar > deltaspike-security-module-impl-1.0.0.jar > itext-1.3.jar > jsfcore.jar > junit.jar > org.hamcrest.core_1.3.0.v201303031735.jar > poi-3.8-20120326.jar > primefaces-4.0.6.jar > shrinkwrap-api.jar > shrinkwrap-descriptors-api-base.jar > shrinkwrap-descriptors-api-javaee.jar > shrinkwrap-descriptors-impl-base.jar > shrinkwrap-descriptors-impl-javaee.jar > shrinkwrap-descriptors-spi.jar > shrinkwrap-impl-base.jar > shrinkwrap-spi.jar > Code snippet > ------------------ > import javax.inject.Inject; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.spec.EnterpriseArchive; > import org.junit.Assert; > import org.junit.Test; > import org.junit.runner.RunWith; > import com.ford.jcoe.jab.inbound.booking.ui.bean.ListBookingBean; > import com.ford.jcoe.jab.inbound.booking.ui.bean.TestArquillianBean; > /** > * TODO - Place class description here > */ > @RunWith(Arquillian.class) > public class ArquillianInjectionTest extends BaseArquillianPersistenceTest { > @Inject > ListBookingBean b; > /** > * TODO - Place method description here > * > * @return > */ > @Deployment > public static EnterpriseArchive createTestArchive() { > java.net.Authenticator.setDefault(basicAuthAuthenticator); > return BaseArquillianPersistenceTest.createTestArchive("JabEAR"); > } > /** > * Unit Test Method > */ > @Test > public void testInjection() { > String stringRepresentation = null; > try { > System.out.println("Not Working Step 1"); > stringRepresentation = this.b.toString(); > System.out.println("Not Working Step 2"); > } catch (final NullPointerException npe) { > Assert.fail("Injection failed."); > } > Assert.assertNotNull(stringRepresentation); > } > } > Exception I am getting > ----------------------------- > Null Pointer exception in stringRepresentation = this.b.toString(); as b is null. > Complete stack trace > -------------------------- > java.lang.AssertionError: Injection failed. > at org.junit.Assert.fail(Assert.java:88) > at ArquillianInjectionTest.testInjection(ArquillianInjectionTest.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:301) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.protocol.local.LocalContainerMethodExecutor.invoke(LocalContainerMethodExecutor.java:50) > at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createTestContext(TestContextHandler.java:102) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createClassContext(TestContextHandler.java:84) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:294) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:269) > 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.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:66) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478) > at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:79) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:960) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1064) > at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87) > at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:914) > at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662) > at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) > at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175) > at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) > at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) > at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138) > at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) > at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) > at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) > at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1702) > Most Important Thing > ------------------------------ > I have commented out the code in WebSphereRemoteContainer.java (for WAS 8 - https://github.com/arquillian/arquillian-container-was) which is responsible for deploying and un-deploying the code. > For our requirements, the code is already deployed and all we need to run the test on PRE DEPLOYED code only. > Methods which I have modified > 1. public ProtocolMetaData deploy(final Archive archive) throws DeploymentException > 2. public void undeploy(final Archive archive) throws DeploymentException > I have just commented out the code which install / uninstall the application. > Can someone help me in getting this issue resolved. > Please let me know if I need to provide more information for debugging purpose. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 12 10:37:51 2015 From: issues at jboss.org (Petr Mensik (JIRA)) Date: Mon, 12 Jan 2015 10:37:51 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1899) Usage of this extension causes some elements not to be found In-Reply-To: References: Message-ID: Petr Mensik created ARQ-1899: -------------------------------- Summary: Usage of this extension causes some elements not to be found Key: ARQ-1899 URL: https://issues.jboss.org/browse/ARQ-1899 Project: Arquillian Issue Type: Bug Components: Extension - AngularJS Affects Versions: angularjs_1.2.0.Beta1 Environment: Fedora 20 Firefox 34 KeyCloak server Reporter: Petr Mensik Assignee: Ken Finnigan Extension seems to be somehow modifying WebDriver runtime because some locators won't work with this extension turned on. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 13 06:00:53 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Tue, 13 Jan 2015 06:00:53 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-464) @Page injection should support parameter injection In-Reply-To: References: Message-ID: Karel Piwko created ARQGRA-464: ---------------------------------- Summary: @Page injection should support parameter injection Key: ARQGRA-464 URL: https://issues.jboss.org/browse/ARQGRA-464 Project: Arquillian Graphene Issue Type: Feature Request Components: core Affects Versions: 2.1.0.Alpha1 Reporter: Karel Piwko Assignee: Karel Piwko Fix For: 2.1.0.Alpha2 Graphene should support @Page injection even for parameter injection in test methods. This would make test case much more compact. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 13 15:07:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 13 Jan 2015 15:07:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1896) Make JMX objectname configurable for JMXTestRunner and JMXMethodExecutor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1896: ------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Aslak Knutsen Fix Version/s: 1.1.6.Final Resolution: Done Pushed upstream; https://github.com/arquillian/arquillian-core/commit/0e5305fb447c5e72268b3280e53b12e6d30678ca > Make JMX objectname configurable for JMXTestRunner and JMXMethodExecutor > ------------------------------------------------------------------------ > > Key: ARQ-1896 > URL: https://issues.jboss.org/browse/ARQ-1896 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.6.Final > Reporter: John Poth > Assignee: Aslak Knutsen > Fix For: 1.1.6.Final > > > Currently, JMXTestRunner#runTestMethod(String className, String methodName) expects to find the test class and run the test method using the classloader set in the constructor. This is a problem when my tests are expected to run inside different containers (hence different classloaders). One easy work around is to publish one JMXTestRunner per container (hence unique objectname has to be provided to avoid conflict). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 13 18:10:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 13 Jan 2015 18:10:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1876) Investigate collapsable entries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned ARQ-1876: -------------------------------------- Assignee: Stefan Miklosovic > Investigate collapsable entries > ------------------------------- > > Key: ARQ-1876 > URL: https://issues.jboss.org/browse/ARQ-1876 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Beta1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Priority: Optional > Fix For: recorder_1.0.0.Beta1 > > > Only long exception stacks are done collapsable, try to do it on entry level in general. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 13 18:10:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 13 Jan 2015 18:10:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1876) Investigate collapsable entries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1876. ------------------------------------ Fix Version/s: recorder_1.0.0.Beta1 Resolution: Done > Investigate collapsable entries > ------------------------------- > > Key: ARQ-1876 > URL: https://issues.jboss.org/browse/ARQ-1876 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Beta1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Priority: Optional > Fix For: recorder_1.0.0.Beta1 > > > Only long exception stacks are done collapsable, try to do it on entry level in general. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 13 18:11:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 13 Jan 2015 18:11:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1894) Deleted videos appear in resulting report In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1894. ------------------------------------ Fix Version/s: recorder_1.0.0.Beta1 Resolution: Done > Deleted videos appear in resulting report > ----------------------------------------- > > Key: ARQ-1894 > URL: https://issues.jboss.org/browse/ARQ-1894 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Alpha4 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: recorder_1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Jan 14 09:54:49 2015 From: issues at jboss.org (Falko M. (JIRA)) Date: Wed, 14 Jan 2015 09:54:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1900) ManagedDeployableContainer tears apart javaVmArguments with quoted spaces In-Reply-To: References: Message-ID: Falko M. created ARQ-1900: ----------------------------- Summary: ManagedDeployableContainer tears apart javaVmArguments with quoted spaces Key: ARQ-1900 URL: https://issues.jboss.org/browse/ARQ-1900 Project: Arquillian Issue Type: Bug Components: JBoss AS Containers Affects Versions: 1.1.5.Final, 1.1.3.Final Environment: Apache Maven 3.0.5 Java version: 1.7.0_72 Reporter: Falko M. As of now you cannot use {{-XX:OnOutOfMemoryError="kill -3 %p"}} (or any other arguments that contains quoted spaces) in {{javaVmArguments}} of {{arquillian.xml}} because {{ManagedDeployableContainer}} uses whitespace characters as delimiters to determine the elements for the {{cmd}} list. The argument from above ends up as *three* elements in the list instead of one. Expected (list as string): {noformat}..., -XX:OnOutOfMemoryError="kill -3 %p", ...{noformat} Actual: {noformat}..., -XX:OnOutOfMemoryError="kill, -3, %p", ...{noformat} This only seems to happen on a linux system. On on a windows machine, java seems to re-join the command and therefore the server starts properly! -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 05:12:49 2015 From: issues at jboss.org (Saurabh Agarwal (JIRA)) Date: Thu, 15 Jan 2015 05:12:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1889) CDI Injection not working in WebSphere Containers (V8) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032690#comment-13032690 ] Saurabh Agarwal commented on ARQ-1889: -------------------------------------- Hi Gerhard, I have referred to ARQ-1488 before opening this issue. The test case you have mentioned in working for me in one condition and that is the code should be deployed by Arquillian framework as documented. However my setup & infrastructure is little different as 1. We are using WAS 8.5 (Not important difference I believe) 2. The code is already deployed on our servers and we don't want Arquillian should build & Deploy code before executing the test case. For point 2 above we have commented out some portion of code in https://github.com/arquillian/arquillian-container-was/blob/master/was-remote-8.5/src/main/java/org/jboss/arquillian/container/was/remote_8_5/WebSphereRemoteContainer.java I am attaching my file which depicts my test case. I am getting a null pointer exception (Assertion error) at line 65. Also I am attaching the complete stacktrace if this helps. > CDI Injection not working in WebSphere Containers (V8) > ------------------------------------------------------ > > Key: ARQ-1889 > URL: https://issues.jboss.org/browse/ARQ-1889 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Affects Versions: was_1.0.0.Beta1 > Environment: Windows 7, IBM WebSphere Application Server (8.0.0.9), IBM RSA 8 > Reporter: Saurabh Agarwal > Priority: Blocker > > Hi, > I have gone through ARQ-1488 and it depicts the same problem what I am facing. > In my IBM WebSphere Application Server (8.0.0.9), CDI is not working and it is giving me the NP exception. > Please note I am not using MAVEN build but have all required JARS file in my web-inf/lib directory > JARS List I am having > ------------------------------ > arquillian-config-api.jar > arquillian-config-impl-base.jar > arquillian-config-spi.jar > arquillian-container-impl-base.jar > arquillian-container-spi.jar > arquillian-container-test-api.jar > arquillian-container-test-impl-base.jar > arquillian-container-test-spi.jar > arquillian-core-api.jar > arquillian-core-impl-base-1.1.5.Final.jar > arquillian-core-spi-1.1.5.Final.jar > arquillian-junit-container.jar > arquillian-junit-core.jar > arquillian-protocol-jmx-1.1.5.Final.jar > arquillian-protocol-servlet.jar > arquillian-protocol.jar > arquillian-test-api.jar > arquillian-test-impl-base.jar > arquillian-test-spi.jar > arquillian-testenricher-cdi.jar > arquillian-testenricher-ejb.jar > arquillian-testenricher-initialcontext.jar > arquillian-testenricher-resource.jar > arquillian-was-remote.jar > commons-fileupload-1.2.1.jar > commons-io-1.4.jar > deltaspike-core-api-1.0.0.jar > deltaspike-core-impl-1.0.0.jar > deltaspike-jsf-module-api-1.0.0.jar > deltaspike-jsf-module-impl-1.0.0.jar > deltaspike-security-module-api-1.0.0.jar > deltaspike-security-module-impl-1.0.0.jar > itext-1.3.jar > jsfcore.jar > junit.jar > org.hamcrest.core_1.3.0.v201303031735.jar > poi-3.8-20120326.jar > primefaces-4.0.6.jar > shrinkwrap-api.jar > shrinkwrap-descriptors-api-base.jar > shrinkwrap-descriptors-api-javaee.jar > shrinkwrap-descriptors-impl-base.jar > shrinkwrap-descriptors-impl-javaee.jar > shrinkwrap-descriptors-spi.jar > shrinkwrap-impl-base.jar > shrinkwrap-spi.jar > Code snippet > ------------------ > import javax.inject.Inject; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.spec.EnterpriseArchive; > import org.junit.Assert; > import org.junit.Test; > import org.junit.runner.RunWith; > import com.ford.jcoe.jab.inbound.booking.ui.bean.ListBookingBean; > import com.ford.jcoe.jab.inbound.booking.ui.bean.TestArquillianBean; > /** > * TODO - Place class description here > */ > @RunWith(Arquillian.class) > public class ArquillianInjectionTest extends BaseArquillianPersistenceTest { > @Inject > ListBookingBean b; > /** > * TODO - Place method description here > * > * @return > */ > @Deployment > public static EnterpriseArchive createTestArchive() { > java.net.Authenticator.setDefault(basicAuthAuthenticator); > return BaseArquillianPersistenceTest.createTestArchive("JabEAR"); > } > /** > * Unit Test Method > */ > @Test > public void testInjection() { > String stringRepresentation = null; > try { > System.out.println("Not Working Step 1"); > stringRepresentation = this.b.toString(); > System.out.println("Not Working Step 2"); > } catch (final NullPointerException npe) { > Assert.fail("Injection failed."); > } > Assert.assertNotNull(stringRepresentation); > } > } > Exception I am getting > ----------------------------- > Null Pointer exception in stringRepresentation = this.b.toString(); as b is null. > Complete stack trace > -------------------------- > java.lang.AssertionError: Injection failed. > at org.junit.Assert.fail(Assert.java:88) > at ArquillianInjectionTest.testInjection(ArquillianInjectionTest.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:301) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.protocol.local.LocalContainerMethodExecutor.invoke(LocalContainerMethodExecutor.java:50) > at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createTestContext(TestContextHandler.java:102) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createClassContext(TestContextHandler.java:84) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:294) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:269) > 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.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:66) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478) > at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:79) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:960) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1064) > at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87) > at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:914) > at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662) > at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) > at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175) > at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) > at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) > at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138) > at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) > at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) > at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) > at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1702) > Most Important Thing > ------------------------------ > I have commented out the code in WebSphereRemoteContainer.java (for WAS 8 - https://github.com/arquillian/arquillian-container-was) which is responsible for deploying and un-deploying the code. > For our requirements, the code is already deployed and all we need to run the test on PRE DEPLOYED code only. > Methods which I have modified > 1. public ProtocolMetaData deploy(final Archive archive) throws DeploymentException > 2. public void undeploy(final Archive archive) throws DeploymentException > I have just commented out the code which install / uninstall the application. > Can someone help me in getting this issue resolved. > Please let me know if I need to provide more information for debugging purpose. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 05:13:49 2015 From: issues at jboss.org (Saurabh Agarwal (JIRA)) Date: Thu, 15 Jan 2015 05:13:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1889) CDI Injection not working in WebSphere Containers (V8) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saurabh Agarwal updated ARQ-1889: --------------------------------- Attachment: ArquillianInjectionTest.java StackTrace.txt > CDI Injection not working in WebSphere Containers (V8) > ------------------------------------------------------ > > Key: ARQ-1889 > URL: https://issues.jboss.org/browse/ARQ-1889 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Affects Versions: was_1.0.0.Beta1 > Environment: Windows 7, IBM WebSphere Application Server (8.0.0.9), IBM RSA 8 > Reporter: Saurabh Agarwal > Priority: Blocker > Attachments: ArquillianInjectionTest.java, StackTrace.txt > > > Hi, > I have gone through ARQ-1488 and it depicts the same problem what I am facing. > In my IBM WebSphere Application Server (8.0.0.9), CDI is not working and it is giving me the NP exception. > Please note I am not using MAVEN build but have all required JARS file in my web-inf/lib directory > JARS List I am having > ------------------------------ > arquillian-config-api.jar > arquillian-config-impl-base.jar > arquillian-config-spi.jar > arquillian-container-impl-base.jar > arquillian-container-spi.jar > arquillian-container-test-api.jar > arquillian-container-test-impl-base.jar > arquillian-container-test-spi.jar > arquillian-core-api.jar > arquillian-core-impl-base-1.1.5.Final.jar > arquillian-core-spi-1.1.5.Final.jar > arquillian-junit-container.jar > arquillian-junit-core.jar > arquillian-protocol-jmx-1.1.5.Final.jar > arquillian-protocol-servlet.jar > arquillian-protocol.jar > arquillian-test-api.jar > arquillian-test-impl-base.jar > arquillian-test-spi.jar > arquillian-testenricher-cdi.jar > arquillian-testenricher-ejb.jar > arquillian-testenricher-initialcontext.jar > arquillian-testenricher-resource.jar > arquillian-was-remote.jar > commons-fileupload-1.2.1.jar > commons-io-1.4.jar > deltaspike-core-api-1.0.0.jar > deltaspike-core-impl-1.0.0.jar > deltaspike-jsf-module-api-1.0.0.jar > deltaspike-jsf-module-impl-1.0.0.jar > deltaspike-security-module-api-1.0.0.jar > deltaspike-security-module-impl-1.0.0.jar > itext-1.3.jar > jsfcore.jar > junit.jar > org.hamcrest.core_1.3.0.v201303031735.jar > poi-3.8-20120326.jar > primefaces-4.0.6.jar > shrinkwrap-api.jar > shrinkwrap-descriptors-api-base.jar > shrinkwrap-descriptors-api-javaee.jar > shrinkwrap-descriptors-impl-base.jar > shrinkwrap-descriptors-impl-javaee.jar > shrinkwrap-descriptors-spi.jar > shrinkwrap-impl-base.jar > shrinkwrap-spi.jar > Code snippet > ------------------ > import javax.inject.Inject; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.spec.EnterpriseArchive; > import org.junit.Assert; > import org.junit.Test; > import org.junit.runner.RunWith; > import com.ford.jcoe.jab.inbound.booking.ui.bean.ListBookingBean; > import com.ford.jcoe.jab.inbound.booking.ui.bean.TestArquillianBean; > /** > * TODO - Place class description here > */ > @RunWith(Arquillian.class) > public class ArquillianInjectionTest extends BaseArquillianPersistenceTest { > @Inject > ListBookingBean b; > /** > * TODO - Place method description here > * > * @return > */ > @Deployment > public static EnterpriseArchive createTestArchive() { > java.net.Authenticator.setDefault(basicAuthAuthenticator); > return BaseArquillianPersistenceTest.createTestArchive("JabEAR"); > } > /** > * Unit Test Method > */ > @Test > public void testInjection() { > String stringRepresentation = null; > try { > System.out.println("Not Working Step 1"); > stringRepresentation = this.b.toString(); > System.out.println("Not Working Step 2"); > } catch (final NullPointerException npe) { > Assert.fail("Injection failed."); > } > Assert.assertNotNull(stringRepresentation); > } > } > Exception I am getting > ----------------------------- > Null Pointer exception in stringRepresentation = this.b.toString(); as b is null. > Complete stack trace > -------------------------- > java.lang.AssertionError: Injection failed. > at org.junit.Assert.fail(Assert.java:88) > at ArquillianInjectionTest.testInjection(ArquillianInjectionTest.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:301) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.protocol.local.LocalContainerMethodExecutor.invoke(LocalContainerMethodExecutor.java:50) > at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createTestContext(TestContextHandler.java:102) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createClassContext(TestContextHandler.java:84) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:294) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:269) > 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.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:66) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478) > at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:79) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:960) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1064) > at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87) > at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:914) > at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662) > at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) > at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175) > at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) > at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) > at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138) > at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) > at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) > at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) > at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1702) > Most Important Thing > ------------------------------ > I have commented out the code in WebSphereRemoteContainer.java (for WAS 8 - https://github.com/arquillian/arquillian-container-was) which is responsible for deploying and un-deploying the code. > For our requirements, the code is already deployed and all we need to run the test on PRE DEPLOYED code only. > Methods which I have modified > 1. public ProtocolMetaData deploy(final Archive archive) throws DeploymentException > 2. public void undeploy(final Archive archive) throws DeploymentException > I have just commented out the code which install / uninstall the application. > Can someone help me in getting this issue resolved. > Please let me know if I need to provide more information for debugging purpose. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 05:20:49 2015 From: issues at jboss.org (Saurabh Agarwal (JIRA)) Date: Thu, 15 Jan 2015 05:20:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1889) CDI Injection not working in WebSphere Containers (V8) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032693#comment-13032693 ] Saurabh Agarwal commented on ARQ-1889: -------------------------------------- Just one more query - Though we are in research phase only so not sure if Arquillian (current build) supports DI for PRE_DEPLOYED code. I mean Arquillian does support Build, Deploy, Test, UnDeploy, Stop server etc. tasks in order but if I want to skip all but Test, Does DI work then? > CDI Injection not working in WebSphere Containers (V8) > ------------------------------------------------------ > > Key: ARQ-1889 > URL: https://issues.jboss.org/browse/ARQ-1889 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Affects Versions: was_1.0.0.Beta1 > Environment: Windows 7, IBM WebSphere Application Server (8.0.0.9), IBM RSA 8 > Reporter: Saurabh Agarwal > Priority: Blocker > Attachments: ArquillianInjectionTest.java, StackTrace.txt > > > Hi, > I have gone through ARQ-1488 and it depicts the same problem what I am facing. > In my IBM WebSphere Application Server (8.0.0.9), CDI is not working and it is giving me the NP exception. > Please note I am not using MAVEN build but have all required JARS file in my web-inf/lib directory > JARS List I am having > ------------------------------ > arquillian-config-api.jar > arquillian-config-impl-base.jar > arquillian-config-spi.jar > arquillian-container-impl-base.jar > arquillian-container-spi.jar > arquillian-container-test-api.jar > arquillian-container-test-impl-base.jar > arquillian-container-test-spi.jar > arquillian-core-api.jar > arquillian-core-impl-base-1.1.5.Final.jar > arquillian-core-spi-1.1.5.Final.jar > arquillian-junit-container.jar > arquillian-junit-core.jar > arquillian-protocol-jmx-1.1.5.Final.jar > arquillian-protocol-servlet.jar > arquillian-protocol.jar > arquillian-test-api.jar > arquillian-test-impl-base.jar > arquillian-test-spi.jar > arquillian-testenricher-cdi.jar > arquillian-testenricher-ejb.jar > arquillian-testenricher-initialcontext.jar > arquillian-testenricher-resource.jar > arquillian-was-remote.jar > commons-fileupload-1.2.1.jar > commons-io-1.4.jar > deltaspike-core-api-1.0.0.jar > deltaspike-core-impl-1.0.0.jar > deltaspike-jsf-module-api-1.0.0.jar > deltaspike-jsf-module-impl-1.0.0.jar > deltaspike-security-module-api-1.0.0.jar > deltaspike-security-module-impl-1.0.0.jar > itext-1.3.jar > jsfcore.jar > junit.jar > org.hamcrest.core_1.3.0.v201303031735.jar > poi-3.8-20120326.jar > primefaces-4.0.6.jar > shrinkwrap-api.jar > shrinkwrap-descriptors-api-base.jar > shrinkwrap-descriptors-api-javaee.jar > shrinkwrap-descriptors-impl-base.jar > shrinkwrap-descriptors-impl-javaee.jar > shrinkwrap-descriptors-spi.jar > shrinkwrap-impl-base.jar > shrinkwrap-spi.jar > Code snippet > ------------------ > import javax.inject.Inject; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.spec.EnterpriseArchive; > import org.junit.Assert; > import org.junit.Test; > import org.junit.runner.RunWith; > import com.ford.jcoe.jab.inbound.booking.ui.bean.ListBookingBean; > import com.ford.jcoe.jab.inbound.booking.ui.bean.TestArquillianBean; > /** > * TODO - Place class description here > */ > @RunWith(Arquillian.class) > public class ArquillianInjectionTest extends BaseArquillianPersistenceTest { > @Inject > ListBookingBean b; > /** > * TODO - Place method description here > * > * @return > */ > @Deployment > public static EnterpriseArchive createTestArchive() { > java.net.Authenticator.setDefault(basicAuthAuthenticator); > return BaseArquillianPersistenceTest.createTestArchive("JabEAR"); > } > /** > * Unit Test Method > */ > @Test > public void testInjection() { > String stringRepresentation = null; > try { > System.out.println("Not Working Step 1"); > stringRepresentation = this.b.toString(); > System.out.println("Not Working Step 2"); > } catch (final NullPointerException npe) { > Assert.fail("Injection failed."); > } > Assert.assertNotNull(stringRepresentation); > } > } > Exception I am getting > ----------------------------- > Null Pointer exception in stringRepresentation = this.b.toString(); as b is null. > Complete stack trace > -------------------------- > java.lang.AssertionError: Injection failed. > at org.junit.Assert.fail(Assert.java:88) > at ArquillianInjectionTest.testInjection(ArquillianInjectionTest.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:301) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.protocol.local.LocalContainerMethodExecutor.invoke(LocalContainerMethodExecutor.java:50) > at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createTestContext(TestContextHandler.java:102) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createClassContext(TestContextHandler.java:84) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:294) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:269) > 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.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:66) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478) > at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:79) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:960) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1064) > at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87) > at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:914) > at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662) > at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) > at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175) > at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) > at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) > at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138) > at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) > at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) > at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) > at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1702) > Most Important Thing > ------------------------------ > I have commented out the code in WebSphereRemoteContainer.java (for WAS 8 - https://github.com/arquillian/arquillian-container-was) which is responsible for deploying and un-deploying the code. > For our requirements, the code is already deployed and all we need to run the test on PRE DEPLOYED code only. > Methods which I have modified > 1. public ProtocolMetaData deploy(final Archive archive) throws DeploymentException > 2. public void undeploy(final Archive archive) throws DeploymentException > I have just commented out the code which install / uninstall the application. > Can someone help me in getting this issue resolved. > Please let me know if I need to provide more information for debugging purpose. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 07:05:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Thu, 15 Jan 2015 07:05:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1838) Add message to taken screenshot and video for documentation purposes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1838. ---------------------------------- > Add message to taken screenshot and video for documentation purposes > -------------------------------------------------------------------- > > Key: ARQ-1838 > URL: https://issues.jboss.org/browse/ARQ-1838 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Alpha4 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: recorder_1.0.0.Beta1 > > > https://github.com/arquillian/arquillian-recorder/issues/6 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 07:06:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Thu, 15 Jan 2015 07:06:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1877) PropertyEntry.getProperties doesn't seem to be rendered recursivly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1877. ---------------------------------- > PropertyEntry.getProperties doesn't seem to be rendered recursivly > ------------------------------------------------------------------ > > Key: ARQ-1877 > URL: https://issues.jboss.org/browse/ARQ-1877 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Beta1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: recorder_1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 07:06:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Thu, 15 Jan 2015 07:06:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1894) Deleted videos appear in resulting report In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1894. ---------------------------------- > Deleted videos appear in resulting report > ----------------------------------------- > > Key: ARQ-1894 > URL: https://issues.jboss.org/browse/ARQ-1894 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Alpha4 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: recorder_1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 07:06:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Thu, 15 Jan 2015 07:06:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1876) Investigate collapsable entries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1876. ---------------------------------- > Investigate collapsable entries > ------------------------------- > > Key: ARQ-1876 > URL: https://issues.jboss.org/browse/ARQ-1876 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Beta1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Priority: Optional > Fix For: recorder_1.0.0.Beta1 > > > Only long exception stacks are done collapsable, try to do it on entry level in general. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 07:06:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Thu, 15 Jan 2015 07:06:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1878) Introduce TableEntry In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic closed ARQ-1878. ---------------------------------- > Introduce TableEntry > -------------------- > > Key: ARQ-1878 > URL: https://issues.jboss.org/browse/ARQ-1878 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Beta1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Priority: Optional > Fix For: recorder_1.0.0.Beta1 > > > TableEntry should have header, rows and cells. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 12:37:49 2015 From: issues at jboss.org (Richard Achmatowicz (JIRA)) Date: Thu, 15 Jan 2015 12:37:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1901) Allow Arquillian to specify a timeout value for the Wildfly clean shutdown mechanism when shutting down a server. In-Reply-To: References: Message-ID: Richard Achmatowicz created ARQ-1901: ---------------------------------------- Summary: Allow Arquillian to specify a timeout value for the Wildfly clean shutdown mechanism when shutting down a server. Key: ARQ-1901 URL: https://issues.jboss.org/browse/ARQ-1901 Project: Arquillian Issue Type: Feature Request Components: JBoss AS Containers Reporter: Richard Achmatowicz Wildfly has a clean shutdown mechanism which can be used to shutdown a server from the command line so that requests active at the time of shutdown get a chance to complete: {code} [standalone at localhost:9990 /] :shutdown(timeout=5) {"outcome" => "success"} {code} Provide access to this feature from an Arquillian test case so that test cases may test with or without clean shutdown enabled. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 12:41:49 2015 From: issues at jboss.org (Richard Achmatowicz (JIRA)) Date: Thu, 15 Jan 2015 12:41:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1901) Allow Arquillian to specify a timeout value for the Wildfly clean shutdown mechanism when shutting down a server. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032857#comment-13032857 ] Richard Achmatowicz commented on ARQ-1901: ------------------------------------------ I wanted to assign this to Radoslav Husar, but it seems that assignment of a new assignee is disabled. (???) > Allow Arquillian to specify a timeout value for the Wildfly clean shutdown mechanism when shutting down a server. > ----------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1901 > URL: https://issues.jboss.org/browse/ARQ-1901 > Project: Arquillian > Issue Type: Feature Request > Components: JBoss AS Containers > Reporter: Richard Achmatowicz > > Wildfly has a clean shutdown mechanism which can be used to shutdown a server from the command line so that requests active at the time of shutdown get a chance to complete: > {code} > [standalone at localhost:9990 /] :shutdown(timeout=5) > {"outcome" => "success"} > {code} > Provide access to this feature from an Arquillian test case so that test cases may test with or without clean shutdown enabled. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 12:44:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 15 Jan 2015 12:44:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1901) Allow Arquillian to specify a timeout value for the Wildfly clean shutdown mechanism when shutting down a server. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1901: ------------------------------- Reporter: Radoslav Husar (was: Richard Achmatowicz) > Allow Arquillian to specify a timeout value for the Wildfly clean shutdown mechanism when shutting down a server. > ----------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1901 > URL: https://issues.jboss.org/browse/ARQ-1901 > Project: Arquillian > Issue Type: Feature Request > Components: JBoss AS Containers > Reporter: Radoslav Husar > > Wildfly has a clean shutdown mechanism which can be used to shutdown a server from the command line so that requests active at the time of shutdown get a chance to complete: > {code} > [standalone at localhost:9990 /] :shutdown(timeout=5) > {"outcome" => "success"} > {code} > Provide access to this feature from an Arquillian test case so that test cases may test with or without clean shutdown enabled. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 15 12:44:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 15 Jan 2015 12:44:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1901) Allow Arquillian to specify a timeout value for the Wildfly clean shutdown mechanism when shutting down a server. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1901: ------------------------------- Reporter: Richard Achmatowicz (was: Radoslav Husar) > Allow Arquillian to specify a timeout value for the Wildfly clean shutdown mechanism when shutting down a server. > ----------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1901 > URL: https://issues.jboss.org/browse/ARQ-1901 > Project: Arquillian > Issue Type: Feature Request > Components: JBoss AS Containers > Reporter: Richard Achmatowicz > > Wildfly has a clean shutdown mechanism which can be used to shutdown a server from the command line so that requests active at the time of shutdown get a chance to complete: > {code} > [standalone at localhost:9990 /] :shutdown(timeout=5) > {"outcome" => "success"} > {code} > Provide access to this feature from an Arquillian test case so that test cases may test with or without clean shutdown enabled. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sat Jan 17 12:11:49 2015 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Sat, 17 Jan 2015 12:11:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1889) CDI Injection not working in WebSphere Containers (V8) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033328#comment-13033328 ] Gerhard Poul commented on ARQ-1889: ----------------------------------- As long as you build the same thing that Arquillian builds (and we're saving the EAR to disk anyway to deploy it remotely into WAS) I don't think there should be any difference, but again; I would test this with the testcase I referred to above. Deploy it manually and try whether you can make it work. Leaving the Deploy/Undeploy out won't make any difference; the only potential thing that you could have done wrong is to leave stuff out of your build that might be required. I would do the following: 1) Run the test case I mentioned above; use the EAR that is generated by it to deploy it manually and test whether you can get it working as you want; I'm pretty sure it well. 2) Figure out what the difference is between the test you performed and the EAR file you deployed and verified working. - Although I'm not sure how easy that is going to be Hope it helps! > CDI Injection not working in WebSphere Containers (V8) > ------------------------------------------------------ > > Key: ARQ-1889 > URL: https://issues.jboss.org/browse/ARQ-1889 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Affects Versions: was_1.0.0.Beta1 > Environment: Windows 7, IBM WebSphere Application Server (8.0.0.9), IBM RSA 8 > Reporter: Saurabh Agarwal > Priority: Blocker > Attachments: ArquillianInjectionTest.java, StackTrace.txt > > > Hi, > I have gone through ARQ-1488 and it depicts the same problem what I am facing. > In my IBM WebSphere Application Server (8.0.0.9), CDI is not working and it is giving me the NP exception. > Please note I am not using MAVEN build but have all required JARS file in my web-inf/lib directory > JARS List I am having > ------------------------------ > arquillian-config-api.jar > arquillian-config-impl-base.jar > arquillian-config-spi.jar > arquillian-container-impl-base.jar > arquillian-container-spi.jar > arquillian-container-test-api.jar > arquillian-container-test-impl-base.jar > arquillian-container-test-spi.jar > arquillian-core-api.jar > arquillian-core-impl-base-1.1.5.Final.jar > arquillian-core-spi-1.1.5.Final.jar > arquillian-junit-container.jar > arquillian-junit-core.jar > arquillian-protocol-jmx-1.1.5.Final.jar > arquillian-protocol-servlet.jar > arquillian-protocol.jar > arquillian-test-api.jar > arquillian-test-impl-base.jar > arquillian-test-spi.jar > arquillian-testenricher-cdi.jar > arquillian-testenricher-ejb.jar > arquillian-testenricher-initialcontext.jar > arquillian-testenricher-resource.jar > arquillian-was-remote.jar > commons-fileupload-1.2.1.jar > commons-io-1.4.jar > deltaspike-core-api-1.0.0.jar > deltaspike-core-impl-1.0.0.jar > deltaspike-jsf-module-api-1.0.0.jar > deltaspike-jsf-module-impl-1.0.0.jar > deltaspike-security-module-api-1.0.0.jar > deltaspike-security-module-impl-1.0.0.jar > itext-1.3.jar > jsfcore.jar > junit.jar > org.hamcrest.core_1.3.0.v201303031735.jar > poi-3.8-20120326.jar > primefaces-4.0.6.jar > shrinkwrap-api.jar > shrinkwrap-descriptors-api-base.jar > shrinkwrap-descriptors-api-javaee.jar > shrinkwrap-descriptors-impl-base.jar > shrinkwrap-descriptors-impl-javaee.jar > shrinkwrap-descriptors-spi.jar > shrinkwrap-impl-base.jar > shrinkwrap-spi.jar > Code snippet > ------------------ > import javax.inject.Inject; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.spec.EnterpriseArchive; > import org.junit.Assert; > import org.junit.Test; > import org.junit.runner.RunWith; > import com.ford.jcoe.jab.inbound.booking.ui.bean.ListBookingBean; > import com.ford.jcoe.jab.inbound.booking.ui.bean.TestArquillianBean; > /** > * TODO - Place class description here > */ > @RunWith(Arquillian.class) > public class ArquillianInjectionTest extends BaseArquillianPersistenceTest { > @Inject > ListBookingBean b; > /** > * TODO - Place method description here > * > * @return > */ > @Deployment > public static EnterpriseArchive createTestArchive() { > java.net.Authenticator.setDefault(basicAuthAuthenticator); > return BaseArquillianPersistenceTest.createTestArchive("JabEAR"); > } > /** > * Unit Test Method > */ > @Test > public void testInjection() { > String stringRepresentation = null; > try { > System.out.println("Not Working Step 1"); > stringRepresentation = this.b.toString(); > System.out.println("Not Working Step 2"); > } catch (final NullPointerException npe) { > Assert.fail("Injection failed."); > } > Assert.assertNotNull(stringRepresentation); > } > } > Exception I am getting > ----------------------------- > Null Pointer exception in stringRepresentation = this.b.toString(); as b is null. > Complete stack trace > -------------------------- > java.lang.AssertionError: Injection failed. > at org.junit.Assert.fail(Assert.java:88) > at ArquillianInjectionTest.testInjection(ArquillianInjectionTest.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:301) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.protocol.local.LocalContainerMethodExecutor.invoke(LocalContainerMethodExecutor.java:50) > at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createTestContext(TestContextHandler.java:102) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createClassContext(TestContextHandler.java:84) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:294) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:269) > 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.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:66) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478) > at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:79) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:960) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1064) > at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87) > at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:914) > at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662) > at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) > at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175) > at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) > at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) > at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138) > at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) > at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) > at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) > at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1702) > Most Important Thing > ------------------------------ > I have commented out the code in WebSphereRemoteContainer.java (for WAS 8 - https://github.com/arquillian/arquillian-container-was) which is responsible for deploying and un-deploying the code. > For our requirements, the code is already deployed and all we need to run the test on PRE DEPLOYED code only. > Methods which I have modified > 1. public ProtocolMetaData deploy(final Archive archive) throws DeploymentException > 2. public void undeploy(final Archive archive) throws DeploymentException > I have just commented out the code which install / uninstall the application. > Can someone help me in getting this issue resolved. > Please let me know if I need to provide more information for debugging purpose. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sat Jan 17 12:15:50 2015 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Sat, 17 Jan 2015 12:15:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1889) CDI Injection not working in WebSphere Containers (V8) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033328#comment-13033328 ] Gerhard Poul edited comment on ARQ-1889 at 1/17/15 12:15 PM: ------------------------------------------------------------- As long as you build the same thing that Arquillian builds (and we're saving the EAR to disk anyway to deploy it remotely into WAS) I don't think there should be any difference, but again; I would test this with the testcase I referred to above. Deploy it manually and try whether you can make it work. Leaving the Deploy/Undeploy out won't make any difference; the only potential thing that you could have done wrong is to leave stuff out of your build that might be required. I would do the following: 1) Run the test case I mentioned above; use the EAR that is generated by it to deploy it manually and test whether you can get it working as you want 2) Figure out what the difference is between the test you performed and the EAR file you deployed and verified working. - Although I'm not sure how easy that is going to be Hope it helps! was (Author: gpoul): As long as you build the same thing that Arquillian builds (and we're saving the EAR to disk anyway to deploy it remotely into WAS) I don't think there should be any difference, but again; I would test this with the testcase I referred to above. Deploy it manually and try whether you can make it work. Leaving the Deploy/Undeploy out won't make any difference; the only potential thing that you could have done wrong is to leave stuff out of your build that might be required. I would do the following: 1) Run the test case I mentioned above; use the EAR that is generated by it to deploy it manually and test whether you can get it working as you want; I'm pretty sure it well. 2) Figure out what the difference is between the test you performed and the EAR file you deployed and verified working. - Although I'm not sure how easy that is going to be Hope it helps! > CDI Injection not working in WebSphere Containers (V8) > ------------------------------------------------------ > > Key: ARQ-1889 > URL: https://issues.jboss.org/browse/ARQ-1889 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Affects Versions: was_1.0.0.Beta1 > Environment: Windows 7, IBM WebSphere Application Server (8.0.0.9), IBM RSA 8 > Reporter: Saurabh Agarwal > Priority: Blocker > Attachments: ArquillianInjectionTest.java, StackTrace.txt > > > Hi, > I have gone through ARQ-1488 and it depicts the same problem what I am facing. > In my IBM WebSphere Application Server (8.0.0.9), CDI is not working and it is giving me the NP exception. > Please note I am not using MAVEN build but have all required JARS file in my web-inf/lib directory > JARS List I am having > ------------------------------ > arquillian-config-api.jar > arquillian-config-impl-base.jar > arquillian-config-spi.jar > arquillian-container-impl-base.jar > arquillian-container-spi.jar > arquillian-container-test-api.jar > arquillian-container-test-impl-base.jar > arquillian-container-test-spi.jar > arquillian-core-api.jar > arquillian-core-impl-base-1.1.5.Final.jar > arquillian-core-spi-1.1.5.Final.jar > arquillian-junit-container.jar > arquillian-junit-core.jar > arquillian-protocol-jmx-1.1.5.Final.jar > arquillian-protocol-servlet.jar > arquillian-protocol.jar > arquillian-test-api.jar > arquillian-test-impl-base.jar > arquillian-test-spi.jar > arquillian-testenricher-cdi.jar > arquillian-testenricher-ejb.jar > arquillian-testenricher-initialcontext.jar > arquillian-testenricher-resource.jar > arquillian-was-remote.jar > commons-fileupload-1.2.1.jar > commons-io-1.4.jar > deltaspike-core-api-1.0.0.jar > deltaspike-core-impl-1.0.0.jar > deltaspike-jsf-module-api-1.0.0.jar > deltaspike-jsf-module-impl-1.0.0.jar > deltaspike-security-module-api-1.0.0.jar > deltaspike-security-module-impl-1.0.0.jar > itext-1.3.jar > jsfcore.jar > junit.jar > org.hamcrest.core_1.3.0.v201303031735.jar > poi-3.8-20120326.jar > primefaces-4.0.6.jar > shrinkwrap-api.jar > shrinkwrap-descriptors-api-base.jar > shrinkwrap-descriptors-api-javaee.jar > shrinkwrap-descriptors-impl-base.jar > shrinkwrap-descriptors-impl-javaee.jar > shrinkwrap-descriptors-spi.jar > shrinkwrap-impl-base.jar > shrinkwrap-spi.jar > Code snippet > ------------------ > import javax.inject.Inject; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.spec.EnterpriseArchive; > import org.junit.Assert; > import org.junit.Test; > import org.junit.runner.RunWith; > import com.ford.jcoe.jab.inbound.booking.ui.bean.ListBookingBean; > import com.ford.jcoe.jab.inbound.booking.ui.bean.TestArquillianBean; > /** > * TODO - Place class description here > */ > @RunWith(Arquillian.class) > public class ArquillianInjectionTest extends BaseArquillianPersistenceTest { > @Inject > ListBookingBean b; > /** > * TODO - Place method description here > * > * @return > */ > @Deployment > public static EnterpriseArchive createTestArchive() { > java.net.Authenticator.setDefault(basicAuthAuthenticator); > return BaseArquillianPersistenceTest.createTestArchive("JabEAR"); > } > /** > * Unit Test Method > */ > @Test > public void testInjection() { > String stringRepresentation = null; > try { > System.out.println("Not Working Step 1"); > stringRepresentation = this.b.toString(); > System.out.println("Not Working Step 2"); > } catch (final NullPointerException npe) { > Assert.fail("Injection failed."); > } > Assert.assertNotNull(stringRepresentation); > } > } > Exception I am getting > ----------------------------- > Null Pointer exception in stringRepresentation = this.b.toString(); as b is null. > Complete stack trace > -------------------------- > java.lang.AssertionError: Injection failed. > at org.junit.Assert.fail(Assert.java:88) > at ArquillianInjectionTest.testInjection(ArquillianInjectionTest.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:301) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.protocol.local.LocalContainerMethodExecutor.invoke(LocalContainerMethodExecutor.java:50) > at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createTestContext(TestContextHandler.java:102) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.createClassContext(TestContextHandler.java:84) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > 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:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:294) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:269) > 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.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:66) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779) > at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478) > at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136) > at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:79) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:960) > at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1064) > at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87) > at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:914) > at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662) > at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306) > at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) > at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) > at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175) > at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) > at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) > at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138) > at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) > at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) > at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) > at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1702) > Most Important Thing > ------------------------------ > I have commented out the code in WebSphereRemoteContainer.java (for WAS 8 - https://github.com/arquillian/arquillian-container-was) which is responsible for deploying and un-deploying the code. > For our requirements, the code is already deployed and all we need to run the test on PRE DEPLOYED code only. > Methods which I have modified > 1. public ProtocolMetaData deploy(final Archive archive) throws DeploymentException > 2. public void undeploy(final Archive archive) throws DeploymentException > I have just commented out the code which install / uninstall the application. > Can someone help me in getting this issue resolved. > Please let me know if I need to provide more information for debugging purpose. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 20 04:49:49 2015 From: issues at jboss.org (Pavel Jelinek (JIRA)) Date: Tue, 20 Jan 2015 04:49: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: Pavel Jelinek created ARQGRA-465: ------------------------------------ Summary: 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 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 Beta1-SNAPSHOT to 1.0.0.Final-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 20 04:51:49 2015 From: issues at jboss.org (Pavel Jelinek (JIRA)) Date: Tue, 20 Jan 2015 04:51: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 ] Pavel Jelinek updated ARQGRA-465: --------------------------------- Description: 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 was: 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 Beta1-SNAPSHOT to 1.0.0.Final-SNAPSHOT > 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 > > 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 Tue Jan 20 05:05:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 20 Jan 2015 05:05: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:comment-tabpanel&focusedCommentId=13033770#comment-13033770 ] Stefan Miklosovic commented on ARQGRA-465: ------------------------------------------ This "bug" will be autoresolved once Graphene 2.1.0.Alpha2 is released having below PR merged. https://github.com/arquillian/arquillian-graphene/pull/125. > 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 > > 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 Tue Jan 20 05:06:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 20 Jan 2015 05:06: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:comment-tabpanel&focusedCommentId=13033770#comment-13033770 ] Stefan Miklosovic edited comment on ARQGRA-465 at 1/20/15 5:06 AM: ------------------------------------------------------------------- This "bug" will be autoresolved once Graphene 2.1.0.Alpha2 is released having below PR merged. Release of 2.1.0.Alpha2 is planned in the very near future (I strongly hope less then a week, maybe till the end of this one). https://github.com/arquillian/arquillian-graphene/pull/125. was (Author: smikloso): This "bug" will be autoresolved once Graphene 2.1.0.Alpha2 is released having below PR merged. https://github.com/arquillian/arquillian-graphene/pull/125. > 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 > > 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 Tue Jan 20 12:02:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 20 Jan 2015 12:02:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1902) Provide SPI for conditional execution of test methods In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1902: -------------------------------------- Summary: Provide SPI for conditional execution of test methods Key: ARQ-1902 URL: https://issues.jboss.org/browse/ARQ-1902 Project: Arquillian Issue Type: Feature Request Components: Base Implementation Affects Versions: 1.1.5.Final Reporter: Stefan Miklosovic [~aslak] Let me explain. We want to do this: {code} @RunWith(Arquillian.class) @RunAsClient public class TestCase { @Test @Jira("ARQ-1") public void test() { // this test method will be executed // because Aslak created EJB Jar archive (JIRA status = done) } @Test @Jira("ARQ-xyz") public void test() { // this methods will NOT be executed (will be skipped) // becase lets say that its status is "open / unresolved" } } {/code} While looking into the code, it seems these classes are most important (1), (2). So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider on class path in custom extension. (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 20 12:02:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 20 Jan 2015 12:02:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1902) Provide SPI for conditional execution of test methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1902: ----------------------------------- Description: [~aslak] Let me explain. We want to do this: {code} @RunWith(Arquillian.class) @RunAsClient public class TestCase { @Test @Jira("ARQ-1") public void test() { // this test method will be executed // because Aslak created EJB Jar archive (JIRA status = done) } @Test @Jira("ARQ-xyz") public void test() { // this methods will NOT be executed (will be skipped) // becase lets say that its status is "open / unresolved" } } {code} While looking into the code, it seems these classes are most important (1), (2). So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider on class path in custom extension. (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 was: [~aslak] Let me explain. We want to do this: {code} @RunWith(Arquillian.class) @RunAsClient public class TestCase { @Test @Jira("ARQ-1") public void test() { // this test method will be executed // because Aslak created EJB Jar archive (JIRA status = done) } @Test @Jira("ARQ-xyz") public void test() { // this methods will NOT be executed (will be skipped) // becase lets say that its status is "open / unresolved" } } {/code} While looking into the code, it seems these classes are most important (1), (2). So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider on class path in custom extension. (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 > Provide SPI for conditional execution of test methods > ----------------------------------------------------- > > Key: ARQ-1902 > URL: https://issues.jboss.org/browse/ARQ-1902 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.5.Final > Reporter: Stefan Miklosovic > > [~aslak] > Let me explain. > We want to do this: > {code} > @RunWith(Arquillian.class) > @RunAsClient > public class TestCase > { > @Test > @Jira("ARQ-1") > public void test() { > // this test method will be executed > // because Aslak created EJB Jar archive (JIRA status = done) > } > @Test > @Jira("ARQ-xyz") > public void test() { > // this methods will NOT be executed (will be skipped) > // becase lets say that its status is "open / unresolved" > } > } > {code} > While looking into the code, it seems these classes are most important (1), (2). > So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. > In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. > Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider on class path in custom extension. > (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 > (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 20 12:05:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 20 Jan 2015 12:05:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1902) Provide SPI for conditional execution of test methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1902: ----------------------------------- Description: [~aslak] Let me explain. We want to do this: {code} @RunWith(Arquillian.class) @RunAsClient public class TestCase { @Test @Jira("ARQ-1") public void test() { // this test method will be executed // because Aslak created EJB Jar archive (JIRA status = done) } @Test @Jira("ARQ-xyz") public void test() { // this methods will NOT be executed (will be skipped) // becase lets say that its status is "open / unresolved" } } {code} While looking into the code, it seems these classes are most important (1), (2). So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider and whole JIRA api on class path in my custom extension. (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 was: [~aslak] Let me explain. We want to do this: {code} @RunWith(Arquillian.class) @RunAsClient public class TestCase { @Test @Jira("ARQ-1") public void test() { // this test method will be executed // because Aslak created EJB Jar archive (JIRA status = done) } @Test @Jira("ARQ-xyz") public void test() { // this methods will NOT be executed (will be skipped) // becase lets say that its status is "open / unresolved" } } {code} While looking into the code, it seems these classes are most important (1), (2). So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider on class path in custom extension. (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 > Provide SPI for conditional execution of test methods > ----------------------------------------------------- > > Key: ARQ-1902 > URL: https://issues.jboss.org/browse/ARQ-1902 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.5.Final > Reporter: Stefan Miklosovic > > [~aslak] > Let me explain. > We want to do this: > {code} > @RunWith(Arquillian.class) > @RunAsClient > public class TestCase > { > @Test > @Jira("ARQ-1") > public void test() { > // this test method will be executed > // because Aslak created EJB Jar archive (JIRA status = done) > } > @Test > @Jira("ARQ-xyz") > public void test() { > // this methods will NOT be executed (will be skipped) > // becase lets say that its status is "open / unresolved" > } > } > {code} > While looking into the code, it seems these classes are most important (1), (2). > So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. > In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. > Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider and whole JIRA api on class path in my custom extension. > (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 > (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 20 12:34:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 20 Jan 2015 12:34:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1902) Provide SPI for conditional execution of test methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033904#comment-13033904 ] Aslak Knutsen commented on ARQ-1902: ------------------------------------ I assume you would want to skip the whole Before|Test|After phase? Not just Test? Do you want it 'marked' as Skipped in report? > Provide SPI for conditional execution of test methods > ----------------------------------------------------- > > Key: ARQ-1902 > URL: https://issues.jboss.org/browse/ARQ-1902 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.5.Final > Reporter: Stefan Miklosovic > > [~aslak] > Let me explain. > We want to do this: > {code} > @RunWith(Arquillian.class) > @RunAsClient > public class TestCase > { > @Test > @Jira("ARQ-1") > public void test() { > // this test method will be executed > // because Aslak created EJB Jar archive (JIRA status = done) > } > @Test > @Jira("ARQ-xyz") > public void test() { > // this methods will NOT be executed (will be skipped) > // becase lets say that its status is "open / unresolved" > } > } > {code} > While looking into the code, it seems these classes are most important (1), (2). > So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. > In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. > Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider and whole JIRA api on class path in my custom extension. > (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 > (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Jan 21 05:57:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 21 Jan 2015 05:57:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1902) Provide SPI for conditional execution of test methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034049#comment-13034049 ] Stefan Miklosovic commented on ARQ-1902: ---------------------------------------- Good catch, I guess that excluding Before and After from execution would be necessary as well. I see reporting as a marginal problem, I do not want to fire property events in Core. Core has to be clean of all extensions / apis. However, my "jira" extension could fire them on its own and mark it as skipped. I need to look at this more closely. I do not know right now how to skip whole before / test / after lifecycle. > Provide SPI for conditional execution of test methods > ----------------------------------------------------- > > Key: ARQ-1902 > URL: https://issues.jboss.org/browse/ARQ-1902 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.5.Final > Reporter: Stefan Miklosovic > > [~aslak] > Let me explain. > We want to do this: > {code} > @RunWith(Arquillian.class) > @RunAsClient > public class TestCase > { > @Test > @Jira("ARQ-1") > public void test() { > // this test method will be executed > // because Aslak created EJB Jar archive (JIRA status = done) > } > @Test > @Jira("ARQ-xyz") > public void test() { > // this methods will NOT be executed (will be skipped) > // becase lets say that its status is "open / unresolved" > } > } > {code} > While looking into the code, it seems these classes are most important (1), (2). > So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. > In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. > Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider and whole JIRA api on class path in my custom extension. > (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 > (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Jan 21 06:16:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 21 Jan 2015 06:16:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1902) Provide SPI for conditional execution of test methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034051#comment-13034051 ] Aslak Knutsen commented on ARQ-1902: ------------------------------------ With 'skip in report' I'm referring to the normal JUnit outcome (regardless of what Arq Reporter does).. You can't skip 'the whole before/test/after' phase. You'll have to skip them individually. > Provide SPI for conditional execution of test methods > ----------------------------------------------------- > > Key: ARQ-1902 > URL: https://issues.jboss.org/browse/ARQ-1902 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.5.Final > Reporter: Stefan Miklosovic > > [~aslak] > Let me explain. > We want to do this: > {code} > @RunWith(Arquillian.class) > @RunAsClient > public class TestCase > { > @Test > @Jira("ARQ-1") > public void test() { > // this test method will be executed > // because Aslak created EJB Jar archive (JIRA status = done) > } > @Test > @Jira("ARQ-xyz") > public void test() { > // this methods will NOT be executed (will be skipped) > // becase lets say that its status is "open / unresolved" > } > } > {code} > While looking into the code, it seems these classes are most important (1), (2). > So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. > In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. > Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider and whole JIRA api on class path in my custom extension. > (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 > (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Jan 21 10:12:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 21 Jan 2015 10:12:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1902) Provide SPI for conditional execution of test methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned ARQ-1902: -------------------------------------- Assignee: Stefan Miklosovic > Provide SPI for conditional execution of test methods > ----------------------------------------------------- > > Key: ARQ-1902 > URL: https://issues.jboss.org/browse/ARQ-1902 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.5.Final > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > > [~aslak] > Let me explain. > We want to do this: > {code} > @RunWith(Arquillian.class) > @RunAsClient > public class TestCase > { > @Test > @Jira("ARQ-1") > public void test() { > // this test method will be executed > // because Aslak created EJB Jar archive (JIRA status = done) > } > @Test > @Jira("ARQ-xyz") > public void test() { > // this methods will NOT be executed (will be skipped) > // becase lets say that its status is "open / unresolved" > } > } > {code} > While looking into the code, it seems these classes are most important (1), (2). > So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. > In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. > Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider and whole JIRA api on class path in my custom extension. > (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 > (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Jan 21 10:13:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 21 Jan 2015 10:13:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1902) Provide SPI for conditional execution of test methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1902: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/76 > Provide SPI for conditional execution of test methods > ----------------------------------------------------- > > Key: ARQ-1902 > URL: https://issues.jboss.org/browse/ARQ-1902 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.5.Final > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > > [~aslak] > Let me explain. > We want to do this: > {code} > @RunWith(Arquillian.class) > @RunAsClient > public class TestCase > { > @Test > @Jira("ARQ-1") > public void test() { > // this test method will be executed > // because Aslak created EJB Jar archive (JIRA status = done) > } > @Test > @Jira("ARQ-xyz") > public void test() { > // this methods will NOT be executed (will be skipped) > // becase lets say that its status is "open / unresolved" > } > } > {code} > While looking into the code, it seems these classes are most important (1), (2). > So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. > In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. > Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider and whole JIRA api on class path in my custom extension. > (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 > (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Jan 21 19:42:49 2015 From: issues at jboss.org (Nishant B (JIRA)) Date: Wed, 21 Jan 2015 19:42:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-466) Graphene guardAjax() does not work and gives RequestGuardException In-Reply-To: References: Message-ID: Nishant B created ARQGRA-466: -------------------------------- Summary: Graphene guardAjax() does not work and gives RequestGuardException Key: ARQGRA-466 URL: https://issues.jboss.org/browse/ARQGRA-466 Project: Arquillian Graphene Issue Type: Bug Components: core Affects Versions: 2.1.0.Alpha1 Environment: Windows 7, Google Chrome Reporter: Nishant B Priority: Critical I am getting RequestGuardException when I am trying to use AjaxGuard() method of Graphene class with JSF 2 f:ajax tag. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Jan 21 19:51:49 2015 From: issues at jboss.org (Nishant B (JIRA)) Date: Wed, 21 Jan 2015 19:51:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-466) Graphene guardAjax() does not work and gives RequestGuardException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nishant B updated ARQGRA-466: ----------------------------- Labels: Graphene, guardAjax, (was: ) > Graphene guardAjax() does not work and gives RequestGuardException > ------------------------------------------------------------------ > > Key: ARQGRA-466 > URL: https://issues.jboss.org/browse/ARQGRA-466 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.1.0.Alpha1 > Environment: Windows 7, Google Chrome > Reporter: Nishant B > Priority: Critical > Labels: Graphene,, guardAjax, > > I am getting RequestGuardException when I am trying to use AjaxGuard() method of Graphene class with JSF 2 f:ajax tag. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 22 07:24:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 22 Jan 2015 07:24:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1845) BeforeSuite and AfterSuite events triggered for every class in Eclipse since ARQ-1803 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1845. -------------------------------- Assignee: Aslak Knutsen Resolution: Done Pushed upstream https://github.com/arquillian/arquillian-core/commit/7af8c0cc6ea717147ddbdf4bd99c9e35749d8687 > BeforeSuite and AfterSuite events triggered for every class in Eclipse since ARQ-1803 > ------------------------------------------------------------------------------------- > > Key: ARQ-1845 > URL: https://issues.jboss.org/browse/ARQ-1845 > Project: Arquillian > Issue Type: Bug > Components: Test Harness Integration > Affects Versions: 1.1.5.Final > Reporter: Emond Papegaaij > Assignee: Aslak Knutsen > Fix For: 1.1.6.Final > > > The change made in ARQ-1803 broke the Eclipse hack that should prevent Before- and AfterSuite events for every class. Eclipse creates an Arquillian instance for every class to be tested before the tests are actually started. The State.runnerStarted() was placed in the constructor to count the number of tests created, so only the last test would fire AfterSuite. See the comment in org.jboss.arquillian.junit.State for more info. > This is a major regression for us, as we depend on the arquillian-suite-extension to only deploy the application once. Deploying the application takes over a minute, adding significant time to our test runs under Eclipse. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Jan 22 09:28:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 22 Jan 2015 09:28:49 -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 ] Luk?? Fry? updated ARQGRA-374: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 2.1.0.Alpha2 (was: 2.1-Tracking) Resolution: Done > 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 Fri Jan 23 01:48:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 23 Jan 2015 01:48: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 ] Luk?? Fry? updated ARQGRA-465: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/125 > 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 > 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 Fri Jan 23 01:48:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 23 Jan 2015 01:48: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 ] Luk?? Fry? updated ARQGRA-465: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 2.1.0.Alpha2 Resolution: Done > 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 > 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 Fri Jan 23 01:48:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 23 Jan 2015 01:48: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 ] Luk?? Fry? reassigned ARQGRA-465: --------------------------------- Assignee: Stefan Miklosovic > 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 Fri Jan 23 01:48:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 23 Jan 2015 01:48: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:comment-tabpanel&focusedCommentId=13034531#comment-13034531 ] Luk?? Fry? commented on ARQGRA-465: ----------------------------------- Fixed in master > 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 Fri Jan 23 01:52:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 23 Jan 2015 01:52:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-466) Graphene guardAjax() does not work and gives RequestGuardException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-466: ------------------------------ Steps to Reproduce: Jsf code usage PageA {code}

{code} Test Code Inside test method inside the Arquillian test class {code} @Test @RunAsClient public void genericTest() throws Exception { ---- @FindBy(id="submitAjaxPageA") private GrapheneElement submitAjaxPageA; guardAjax(submitAjaxPageA).click(); //this gives error } {code} Error Error Details {code} org.jboss.arquillian.graphene.request.RequestGuardException: Request type 'XHR' was expected, but type 'HTTP' was done instead at org.jboss.arquillian.graphene.guard.RequestGuardFactory$1.intercept(RequestGuardFactory.java:110) at org.jboss.arquillian.graphene.proxy.InvocationContextImpl.invoke(InvocationContextImpl.java:87) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$2.call(GrapheneContextualHandler.java:213) at org.jboss.arquillian.graphene.context.BrowserActions.performAction(BrowserActions.java:62) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:209) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:233) at org.jboss.arquillian.graphene.GrapheneElementImpl$$EnhancerByGraphene$$630b8764.click() at com.intueor.arquilliantest.test.SamplePageObjectPageA.clickAjaxOnPageA(SamplePageObjectPageA.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.arquillian.graphene.proxy.GrapheneProxyHandler.invokeReal(GrapheneProxyHandler.java:130) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$1.invoke(GrapheneContextualHandler.java:163) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$2.call(GrapheneContextualHandler.java:213) at org.jboss.arquillian.graphene.context.BrowserActions.performAction(BrowserActions.java:62) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:209) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:233) at com.intueor.arquilliantest.test.SamplePageObjectPageA$$EnhancerByGraphene$$6a06d366.clickAjaxOnPageA() at com.intueor.arquilliantest.test.SampleTest.genericTest(SampleTest.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:301) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.createTestContext(TestContextHandler.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.createClassContext(TestContextHandler.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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:145) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:294) 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.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) {code} was: Jsf code usage PageA

Test Code Inside test method inside the Arquillian test class @Test @RunAsClient public void genericTest() throws Exception { ---- @FindBy(id="submitAjaxPageA") private GrapheneElement submitAjaxPageA; guardAjax(submitAjaxPageA).click(); //this gives error } Error Error Details org.jboss.arquillian.graphene.request.RequestGuardException: Request type 'XHR' was expected, but type 'HTTP' was done instead at org.jboss.arquillian.graphene.guard.RequestGuardFactory$1.intercept(RequestGuardFactory.java:110) at org.jboss.arquillian.graphene.proxy.InvocationContextImpl.invoke(InvocationContextImpl.java:87) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$2.call(GrapheneContextualHandler.java:213) at org.jboss.arquillian.graphene.context.BrowserActions.performAction(BrowserActions.java:62) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:209) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:233) at org.jboss.arquillian.graphene.GrapheneElementImpl$$EnhancerByGraphene$$630b8764.click() at com.intueor.arquilliantest.test.SamplePageObjectPageA.clickAjaxOnPageA(SamplePageObjectPageA.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.arquillian.graphene.proxy.GrapheneProxyHandler.invokeReal(GrapheneProxyHandler.java:130) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$1.invoke(GrapheneContextualHandler.java:163) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$2.call(GrapheneContextualHandler.java:213) at org.jboss.arquillian.graphene.context.BrowserActions.performAction(BrowserActions.java:62) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:209) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:233) at com.intueor.arquilliantest.test.SamplePageObjectPageA$$EnhancerByGraphene$$6a06d366.clickAjaxOnPageA() at com.intueor.arquilliantest.test.SampleTest.genericTest(SampleTest.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:301) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.createTestContext(TestContextHandler.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.createClassContext(TestContextHandler.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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:145) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:294) 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.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) > Graphene guardAjax() does not work and gives RequestGuardException > ------------------------------------------------------------------ > > Key: ARQGRA-466 > URL: https://issues.jboss.org/browse/ARQGRA-466 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.1.0.Alpha1 > Environment: Windows 7, Google Chrome > Reporter: Nishant B > Priority: Critical > Labels: Graphene,, guardAjax, > > I am getting RequestGuardException when I am trying to use AjaxGuard() method of Graphene class with JSF 2 f:ajax tag. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Jan 23 02:02:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 23 Jan 2015 02:02:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-466) Graphene guardAjax() does not work and gives RequestGuardException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034533#comment-13034533 ] Luk?? Fry? commented on ARQGRA-466: ----------------------------------- [~nishb] I guess the link you are clicking on is expected to do AJAX request, but it may do a full page reguest instead. Could you check in Chrome Developer Console (or similar) what type of request the button actually makes? > Graphene guardAjax() does not work and gives RequestGuardException > ------------------------------------------------------------------ > > Key: ARQGRA-466 > URL: https://issues.jboss.org/browse/ARQGRA-466 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.1.0.Alpha1 > Environment: Windows 7, Google Chrome > Reporter: Nishant B > Priority: Critical > Labels: Graphene,, guardAjax, > > I am getting RequestGuardException when I am trying to use AjaxGuard() method of Graphene class with JSF 2 f:ajax tag. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 25 07:44:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 07:44:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1902) Provide SPI for conditional execution of test methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1902: ------------------------------- Fix Version/s: 1.1.6.Final > Provide SPI for conditional execution of test methods > ----------------------------------------------------- > > Key: ARQ-1902 > URL: https://issues.jboss.org/browse/ARQ-1902 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.5.Final > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: 1.1.6.Final > > > [~aslak] > Let me explain. > We want to do this: > {code} > @RunWith(Arquillian.class) > @RunAsClient > public class TestCase > { > @Test > @Jira("ARQ-1") > public void test() { > // this test method will be executed > // because Aslak created EJB Jar archive (JIRA status = done) > } > @Test > @Jira("ARQ-xyz") > public void test() { > // this methods will NOT be executed (will be skipped) > // becase lets say that its status is "open / unresolved" > } > } > {code} > While looking into the code, it seems these classes are most important (1), (2). > So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. > In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. > Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider and whole JIRA api on class path in my custom extension. > (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 > (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 25 07:45:50 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 07:45:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1902) Provide SPI for conditional execution of test methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1902: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/f4fef41f8fe812af73762f389d4f3ed31f5e47ac > Provide SPI for conditional execution of test methods > ----------------------------------------------------- > > Key: ARQ-1902 > URL: https://issues.jboss.org/browse/ARQ-1902 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.5.Final > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: 1.1.6.Final > > > [~aslak] > Let me explain. > We want to do this: > {code} > @RunWith(Arquillian.class) > @RunAsClient > public class TestCase > { > @Test > @Jira("ARQ-1") > public void test() { > // this test method will be executed > // because Aslak created EJB Jar archive (JIRA status = done) > } > @Test > @Jira("ARQ-xyz") > public void test() { > // this methods will NOT be executed (will be skipped) > // becase lets say that its status is "open / unresolved" > } > } > {code} > While looking into the code, it seems these classes are most important (1), (2). > So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped. > In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly. > Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider and whole JIRA api on class path in my custom extension. > (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/ClientTestExecuter.java#L44 > (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/LocalTestExecuter.java#L55 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 25 11:06:48 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 11:06:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1903) Support exploded deployments in WebLogic In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1903: ---------------------------------- Summary: Support exploded deployments in WebLogic Key: ARQ-1903 URL: https://issues.jboss.org/browse/ARQ-1903 Project: Arquillian Issue Type: Feature Request Components: WebLogic Containers Affects Versions: wls_1.0.0.Alpha3 Reporter: Aslak Knutsen Assignee: Vineet Reynolds -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 25 11:06:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 11:06:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1903) Support exploded deployments in WebLogic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen reassigned ARQ-1903: ---------------------------------- Assignee: Aslak Knutsen (was: Vineet Reynolds) > Support exploded deployments in WebLogic > ---------------------------------------- > > Key: ARQ-1903 > URL: https://issues.jboss.org/browse/ARQ-1903 > Project: Arquillian > Issue Type: Feature Request > Components: WebLogic Containers > Affects Versions: wls_1.0.0.Alpha3 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 25 11:07:48 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 11:07:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1903) Support exploded deployments in WebLogic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1903: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-wls/pull/16 > Support exploded deployments in WebLogic > ---------------------------------------- > > Key: ARQ-1903 > URL: https://issues.jboss.org/browse/ARQ-1903 > Project: Arquillian > Issue Type: Feature Request > Components: WebLogic Containers > Affects Versions: wls_1.0.0.Alpha3 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 25 11:11:48 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 11:11:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1903) Support exploded deployments in WebLogic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1903: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: wls_1.0.0.next Resolution: Done pushed upstream https://github.com/arquillian/arquillian-container-wls/commit/e0847b16028f7327f5bbcb7d36c4d4357b131445 > Support exploded deployments in WebLogic > ---------------------------------------- > > Key: ARQ-1903 > URL: https://issues.jboss.org/browse/ARQ-1903 > Project: Arquillian > Issue Type: Feature Request > Components: WebLogic Containers > Affects Versions: wls_1.0.0.Alpha3 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: wls_1.0.0.next > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 25 16:37:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 16:37:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1904) ShrinkWrap Resolver upgrade 2.1.1 In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1904: ---------------------------------- Summary: ShrinkWrap Resolver upgrade 2.1.1 Key: ARQ-1904 URL: https://issues.jboss.org/browse/ARQ-1904 Project: Arquillian Issue Type: Enhancement Components: Base Implementation Reporter: Aslak Knutsen Fix For: 1.1.6.Final -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 25 16:37:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 16:37:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1904) ShrinkWrap Resolver upgrade 2.1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen reassigned ARQ-1904: ---------------------------------- Assignee: Aslak Knutsen > ShrinkWrap Resolver upgrade 2.1.1 > --------------------------------- > > Key: ARQ-1904 > URL: https://issues.jboss.org/browse/ARQ-1904 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.6.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 25 16:37:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 16:37:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1905) ShrinkWrap Descriptors upgrade 2.0.0-alpha-6 In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1905: ---------------------------------- Summary: ShrinkWrap Descriptors upgrade 2.0.0-alpha-6 Key: ARQ-1905 URL: https://issues.jboss.org/browse/ARQ-1905 Project: Arquillian Issue Type: Enhancement Components: Base Implementation Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.1.6.Final -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 25 17:07:48 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 17:07: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 updated ARQ-1818: ------------------------------- Fix Version/s: 1.1.7.Final (was: 1.1.6.Final) > 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 Sun Jan 25 17:07:48 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 17:07: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 updated ARQ-1818: ------------------------------- Affects Version/s: 1.1.6.Final > 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 Sun Jan 25 17:08:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 17:08:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1904) ShrinkWrap Resolver upgrade 2.1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1904. -------------------------------- Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/65da6a81584b68a9e80b2b8ba7da774f28abdff2 > ShrinkWrap Resolver upgrade 2.1.1 > --------------------------------- > > Key: ARQ-1904 > URL: https://issues.jboss.org/browse/ARQ-1904 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.6.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Jan 25 17:08:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 25 Jan 2015 17:08:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1905) ShrinkWrap Descriptors upgrade 2.0.0-alpha-6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1905. -------------------------------- Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/3373e06a9271af8c0885135321f8eecdc04ff325 > ShrinkWrap Descriptors upgrade 2.0.0-alpha-6 > -------------------------------------------- > > Key: ARQ-1905 > URL: https://issues.jboss.org/browse/ARQ-1905 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.6.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 08:07:50 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 08:07:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1897) Converting to time unit from miliseconds for CountDownWatch#timeLeft() is not necessary In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko closed ARQ-1897. ---------------------------- > Converting to time unit from miliseconds for CountDownWatch#timeLeft() is not necessary > --------------------------------------------------------------------------------------- > > Key: ARQ-1897 > URL: https://issues.jboss.org/browse/ARQ-1897 > Project: Arquillian > Issue Type: Bug > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha3 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: spacelift_1.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 08:07:50 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 08:07:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1898) Provide ExecutionServiceFactory instance by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko closed ARQ-1898. ---------------------------- > Provide ExecutionServiceFactory instance by default > --------------------------------------------------- > > Key: ARQ-1898 > URL: https://issues.jboss.org/browse/ARQ-1898 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha3 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: spacelift_1.0.0.Alpha4 > > > ExecutionServiceFactory should be instantiated by default. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 08:09:51 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 08:09:51 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1340) Drone webdriver is not created during @BeforeClass In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1340: ----------------------------- Fix Version/s: drone_2.0.0.Alpha4 (was: drone_2.0.0.Alpha3) > Drone webdriver is not created during @BeforeClass > -------------------------------------------------- > > Key: ARQ-1340 > URL: https://issues.jboss.org/browse/ARQ-1340 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_1.1.1.Final > Environment: Arquillian JUnit Container 1.0.3.Final > Arquillian Graphene Webdriver 2.0.0.Alpha3 > Arquillian Drone dependencies and Selenium dependencies 1.1.1.Final > Arquillian Core dependencies 1.0.3.Final > junit 4.8.1 > jdk 1.6 > Reporter: Alex Okrushko > Fix For: drone_2.0.0.Alpha4 > > > Drone webdriver is not created during @BeforeClass, however *is created during @Before or if called by GrapheneContext.getProxy()* > The following does NOT work: > {code:java} > @RunWith(Arquillian.class) > public class TestDroneLogin { > @Drone > private static WebDriver driver; > > @BeforeClass > public static void setup(){ > //GrapheneContext.getProxy().navigate().to("http://google.com"); > driver.navigate().to("http://google.com"); > } > > @Test > public void testInput(){ > driver.findElement(By.cssSelector("input#gbqfq")); > } > } > {code} > However, if I use {{GrapheneContext.getProxy()}} instead of {{driver}}, everything works as expected: > {code:java} > @BeforeClass > public static void setup(){ > GrapheneContext.getProxy().navigate().to("http://google.com"); > } > {code} > ALSO, if {{@Before}} is used then Drone webdriver is created as expected, so this problem is specific to {{@BeforeClass}} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 08:09:51 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 08:09:51 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1008) Can't use reusable remote driver with opera In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1008: ----------------------------- Fix Version/s: drone_2.0.0.Alpha4 (was: drone_2.0.0.Alpha3) > Can't use reusable remote driver with opera > ------------------------------------------- > > Key: ARQ-1008 > URL: https://issues.jboss.org/browse/ARQ-1008 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_1.1.0.CR2 > Reporter: Jan Papousek > Assignee: Jan Papousek > Fix For: drone_2.0.0.Alpha4 > > > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.arquillian.drone.webdriver.example.WebDriverTestCase > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.303 sec <<< FAILURE! > org.jboss.arquillian.drone.webdriver.example.WebDriverTestCase Time elapsed: 0 sec <<< ERROR! > org.openqa.selenium.WebDriverException: Address already in use > Command duration or timeout: 1.50 seconds > Build info: version: '2.24.1', revision: '17205', time: '2012-06-19 15:28:49' > System info: os.name: 'Linux', os.arch: 'amd64', os.version: '2.6.43.8-1.fc15.x86_64', java.version: '1.7.0_04' > Driver info: driver.version: RemoteWebDriver > Session ID: > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:525) > at org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:188) > at org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:145) > at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:472) > at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:155) > at org.openqa.selenium.remote.RemoteWebDriver.(RemoteWebDriver.java:107) > at org.openqa.selenium.remote.RemoteWebDriver.(RemoteWebDriver.java:115) > at org.jboss.arquillian.drone.webdriver.factory.RemoteWebDriverFactory.createRemoteDriver(RemoteWebDriverFactory.java:135) > at org.jboss.arquillian.drone.webdriver.factory.RemoteWebDriverFactory.createReusableDriver(RemoteWebDriverFactory.java:162) > at org.jboss.arquillian.drone.webdriver.factory.RemoteWebDriverFactory.createInstance(RemoteWebDriverFactory.java:95) > at org.jboss.arquillian.drone.webdriver.factory.RemoteWebDriverFactory.createInstance(RemoteWebDriverFactory.java:49) > at org.jboss.arquillian.drone.webdriver.factory.WebDriverFactory.createInstance(WebDriverFactory.java:129) > at org.jboss.arquillian.drone.webdriver.factory.WebDriverFactory.createInstance(WebDriverFactory.java:43) > at org.jboss.arquillian.drone.impl.DroneCreator.createWebTestBrowser(DroneCreator.java:71) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > 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:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.drone.impl.DroneConfigurator.configureDrone(DroneConfigurator.java:116) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > 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:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > Caused by: java.net.BindException: Address already in use > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:344) > at sun.nio.ch.Net.bind(Net.java:336) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:199) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67) > at com.opera.core.systems.scope.stp.StpConnectionListener.start(StpConnectionListener.java:95) > at com.opera.core.systems.scope.stp.StpConnectionListener.(StpConnectionListener.java:58) > at com.opera.core.systems.scope.stp.StpThread.(StpThread.java:46) > at com.opera.core.systems.ScopeServices.(ScopeServices.java:112) > at com.opera.core.systems.OperaDriver.createScopeServices(OperaDriver.java:251) > at com.opera.core.systems.OperaDriver.init(OperaDriver.java:197) > at com.opera.core.systems.OperaDriver.start(OperaDriver.java:186) > at com.opera.core.systems.OperaDriver.(OperaDriver.java:178) > at com.opera.core.systems.OperaDriver.(OperaDriver.java:160) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:525) > at org.openqa.selenium.remote.server.DefaultDriverFactory.callConstructor(DefaultDriverFactory.java:57) > at org.openqa.selenium.remote.server.DefaultDriverFactory.newInstance(DefaultDriverFactory.java:51) > at org.openqa.selenium.remote.server.DefaultSession$BrowserCreator.call(DefaultSession.java:196) > at org.openqa.selenium.remote.server.DefaultSession$BrowserCreator.call(DefaultSession.java:1) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at org.openqa.selenium.remote.server.DefaultSession$1.run(DefaultSession.java:150) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 08:09:51 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 08:09:51 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1692) Factories should not bring runtime dependencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1692: ----------------------------- Fix Version/s: drone_2.0.0.Alpha4 (was: drone_2.0.0.Alpha3) > Factories should not bring runtime dependencies > ----------------------------------------------- > > Key: ARQ-1692 > URL: https://issues.jboss.org/browse/ARQ-1692 > Project: Arquillian > Issue Type: Task > Components: Extension - Drone > Reporter: Karel Piwko > Fix For: drone_2.0.0.Alpha4 > > > DroneFactories should fail graciously in case that Drone type they are trying to instantiate are not on classpath. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 08:09:53 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 08:09:53 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1077) Persistence Plugin does not work with Drone/Graphene In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1077: ----------------------------- Fix Version/s: drone_2.0.0.Alpha4 (was: drone_2.0.0.Alpha3) > Persistence Plugin does not work with Drone/Graphene > ---------------------------------------------------- > > Key: ARQ-1077 > URL: https://issues.jboss.org/browse/ARQ-1077 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone, Extension - Persistence > Environment: JBoss AS 7 Container > Reporter: Bryan Saunders > Assignee: Bartosz Majsak > Labels: drone, persistence > Fix For: drone_2.0.0.Alpha4 > > > Persistence Extension does not execute when being used with the Drone/Graphene extensions. When you run the tests in Client Mode the @UsingDataSet annotations do not trigger and populate the database. @ApplyScriptBefore also does not work. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 08:09:53 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 08:09:53 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1690) Provide and API/SPI to solve backward compatibility In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1690: ----------------------------- Fix Version/s: drone_2.0.0.Alpha4 (was: drone_2.0.0.Alpha3) > Provide and API/SPI to solve backward compatibility > --------------------------------------------------- > > Key: ARQ-1690 > URL: https://issues.jboss.org/browse/ARQ-1690 > Project: Arquillian > Issue Type: Task > Components: Extension - Drone > Reporter: Karel Piwko > Fix For: drone_2.0.0.Alpha4 > > > For extension relying on Drone 1.2.x, migration to 2.0.0 should be smooth. Identify what API/SPI needs to be supported based on existing extensions: > These are at least: > * Graphene 2 > * Warp > * JBehave > * CukeSpace > * APE > * SauceLabs > Note, likely we won't be able to support backwards compatibility 100%. We rather need to make sure major extensions using Drone stay compatible or provide a very easy migration path, e.g. Drone compatibility package. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 08:09:53 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 08:09:53 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1743) Merge configuration and callable creation together In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1743: ----------------------------- Fix Version/s: drone_2.0.0.Alpha4 (was: drone_2.0.0.Alpha3) > Merge configuration and callable creation together > -------------------------------------------------- > > Key: ARQ-1743 > URL: https://issues.jboss.org/browse/ARQ-1743 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Affects Versions: drone_2.0.0.Alpha1 > Reporter: Karel Piwko > Fix For: drone_2.0.0.Alpha4 > > > There should be just one event and either both or none of the object should be present. > This mean that callable and configuration should be created at the same time. This would make usage of Drone much easier. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 08:09:54 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 08:09:54 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1882) NPE in ConfigurationMapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko closed ARQ-1882. ---------------------------- Assignee: Karel Piwko > NPE in ConfigurationMapper > -------------------------- > > Key: ARQ-1882 > URL: https://issues.jboss.org/browse/ARQ-1882 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_2.0.0.Alpha2, drone_1.3.1.Final > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: drone_2.0.0.Alpha3, drone_1.3.2.Final > > > If there is no name property in Drone configuration, configuration mapper tries to convert null value from dot-syntax to camel case syntax -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 11:54:49 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 11:54:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1888) IE driver 2.43+ fails to start due to missing capabilities type mapping In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1888: ----------------------------- Affects Version/s: drone_2.0.0.Alpha3 > IE driver 2.43+ fails to start due to missing capabilities type mapping > ----------------------------------------------------------------------- > > Key: ARQ-1888 > URL: https://issues.jboss.org/browse/ARQ-1888 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_2.0.0.Alpha3, drone_1.3.1.Final > Reporter: Jiri Locker > Priority: Critical > > IE driver became sensitive to capabilities data types in version 2.43.0. If a capability has an unexpected type (e.g. Boolean capability with String value "true"), the driver will fail on the first command, which is obviously an absolute show stopper. > [Issue 8160|https://code.google.com/p/selenium/issues/detail?id=8160] has been filed in Selenium project. A fix has been made on master which prevents IE driver from crashing but wrongly typed capabilities will fall back to default values. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 11:55:49 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 11:55:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1906) IE driver 2.43+ fails to start due to missing capabilities type mapping In-Reply-To: References: Message-ID: Karel Piwko created ARQ-1906: -------------------------------- Summary: IE driver 2.43+ fails to start due to missing capabilities type mapping Key: ARQ-1906 URL: https://issues.jboss.org/browse/ARQ-1906 Project: Arquillian Issue Type: Bug Components: Extension - Drone Affects Versions: drone_2.0.0.Alpha3, drone_1.3.1.Final Reporter: Jiri Locker Priority: Critical IE driver became sensitive to capabilities data types in version 2.43.0. If a capability has an unexpected type (e.g. Boolean capability with String value "true"), the driver will fail on the first command, which is obviously an absolute show stopper. [Issue 8160|https://code.google.com/p/selenium/issues/detail?id=8160] has been filed in Selenium project. A fix has been made on master which prevents IE driver from crashing but wrongly typed capabilities will fall back to default values. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 11:56:49 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 11:56:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1888) IE driver 2.43+ fails to start due to missing capabilities type mapping In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1888: ----------------------------- Affects Version/s: (was: drone_2.0.0.Alpha3) > IE driver 2.43+ fails to start due to missing capabilities type mapping > ----------------------------------------------------------------------- > > Key: ARQ-1888 > URL: https://issues.jboss.org/browse/ARQ-1888 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_1.3.1.Final > Reporter: Jiri Locker > Priority: Critical > Fix For: drone_2.0.0.Alpha3 > > > IE driver became sensitive to capabilities data types in version 2.43.0. If a capability has an unexpected type (e.g. Boolean capability with String value "true"), the driver will fail on the first command, which is obviously an absolute show stopper. > [Issue 8160|https://code.google.com/p/selenium/issues/detail?id=8160] has been filed in Selenium project. A fix has been made on master which prevents IE driver from crashing but wrongly typed capabilities will fall back to default values. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 11:56:49 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 11:56:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1888) IE driver 2.43+ fails to start due to missing capabilities type mapping In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1888: ----------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Jiri Locker Fix Version/s: drone_2.0.0.Alpha3 Resolution: Done > IE driver 2.43+ fails to start due to missing capabilities type mapping > ----------------------------------------------------------------------- > > Key: ARQ-1888 > URL: https://issues.jboss.org/browse/ARQ-1888 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_1.3.1.Final > Reporter: Jiri Locker > Assignee: Jiri Locker > Priority: Critical > Fix For: drone_2.0.0.Alpha3 > > > IE driver became sensitive to capabilities data types in version 2.43.0. If a capability has an unexpected type (e.g. Boolean capability with String value "true"), the driver will fail on the first command, which is obviously an absolute show stopper. > [Issue 8160|https://code.google.com/p/selenium/issues/detail?id=8160] has been filed in Selenium project. A fix has been made on master which prevents IE driver from crashing but wrongly typed capabilities will fall back to default values. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 11:56:49 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 11:56:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1888) IE driver 2.43+ fails to start due to missing capabilities type mapping In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko closed ARQ-1888. ---------------------------- Pushed upstream and released in 2.x stream. Thanks! > IE driver 2.43+ fails to start due to missing capabilities type mapping > ----------------------------------------------------------------------- > > Key: ARQ-1888 > URL: https://issues.jboss.org/browse/ARQ-1888 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_1.3.1.Final > Reporter: Jiri Locker > Assignee: Jiri Locker > Priority: Critical > Fix For: drone_2.0.0.Alpha3 > > > IE driver became sensitive to capabilities data types in version 2.43.0. If a capability has an unexpected type (e.g. Boolean capability with String value "true"), the driver will fail on the first command, which is obviously an absolute show stopper. > [Issue 8160|https://code.google.com/p/selenium/issues/detail?id=8160] has been filed in Selenium project. A fix has been made on master which prevents IE driver from crashing but wrongly typed capabilities will fall back to default values. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 11:58:49 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 11:58:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1906) IE driver 2.43+ fails to start due to missing capabilities type mapping In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1906: ----------------------------- Affects Version/s: (was: drone_2.0.0.Alpha3) > IE driver 2.43+ fails to start due to missing capabilities type mapping > ----------------------------------------------------------------------- > > Key: ARQ-1906 > URL: https://issues.jboss.org/browse/ARQ-1906 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_1.3.1.Final > Reporter: Jiri Locker > Priority: Critical > Fix For: drone_1.3.2.Final > > > IE driver became sensitive to capabilities data types in version 2.43.0. If a capability has an unexpected type (e.g. Boolean capability with String value "true"), the driver will fail on the first command, which is obviously an absolute show stopper. > [Issue 8160|https://code.google.com/p/selenium/issues/detail?id=8160] has been filed in Selenium project. A fix has been made on master which prevents IE driver from crashing but wrongly typed capabilities will fall back to default values. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 11:58:49 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 26 Jan 2015 11:58:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1906) IE driver 2.43+ fails to start due to missing capabilities type mapping In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1906: ----------------------------- Fix Version/s: drone_1.3.2.Final > IE driver 2.43+ fails to start due to missing capabilities type mapping > ----------------------------------------------------------------------- > > Key: ARQ-1906 > URL: https://issues.jboss.org/browse/ARQ-1906 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_1.3.1.Final > Reporter: Jiri Locker > Priority: Critical > Fix For: drone_1.3.2.Final > > > IE driver became sensitive to capabilities data types in version 2.43.0. If a capability has an unexpected type (e.g. Boolean capability with String value "true"), the driver will fail on the first command, which is obviously an absolute show stopper. > [Issue 8160|https://code.google.com/p/selenium/issues/detail?id=8160] has been filed in Selenium project. A fix has been made on master which prevents IE driver from crashing but wrongly typed capabilities will fall back to default values. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 15:01:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 26 Jan 2015 15:01:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1907) Close this issue by Arquillian Jira Decoder extension In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1907: -------------------------------------- Summary: Close this issue by Arquillian Jira Decoder extension Key: ARQ-1907 URL: https://issues.jboss.org/browse/ARQ-1907 Project: Arquillian Issue Type: Task Reporter: Stefan Miklosovic -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 17:31:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 26 Jan 2015 17:31:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1907) Close this issue by Arquillian Jira Decoder extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1907. ------------------------------------ Resolution: Done This JIRA issue was automatically closed by smikloso with Arquillian Jira Decoder extension. > Close this issue by Arquillian Jira Decoder extension > ----------------------------------------------------- > > Key: ARQ-1907 > URL: https://issues.jboss.org/browse/ARQ-1907 > Project: Arquillian > Issue Type: Task > Reporter: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 17:31:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 26 Jan 2015 17:31:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1907) Close this issue by Arquillian Jira Decoder extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035183#comment-13035183 ] Stefan Miklosovic commented on ARQ-1907: ---------------------------------------- [~aslak] yeah :D > Close this issue by Arquillian Jira Decoder extension > ----------------------------------------------------- > > Key: ARQ-1907 > URL: https://issues.jboss.org/browse/ARQ-1907 > Project: Arquillian > Issue Type: Task > Reporter: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Jan 26 17:42:49 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 26 Jan 2015 17:42:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1907) Close this issue by Arquillian Jira Decoder extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035184#comment-13035184 ] Aslak Knutsen commented on ARQ-1907: ------------------------------------ :D > Close this issue by Arquillian Jira Decoder extension > ----------------------------------------------------- > > Key: ARQ-1907 > URL: https://issues.jboss.org/browse/ARQ-1907 > Project: Arquillian > Issue Type: Task > Reporter: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 27 08:39:49 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 27 Jan 2015 08:39:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1907) Close this issue by Arquillian Jira Decoder extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035326#comment-13035326 ] Stefan Miklosovic commented on ARQ-1907: ---------------------------------------- For everybody else, you can autoclose your own JIRAs from your Arquillian test in a similar manner by this extension https://github.com/arquillian/arquillian-showcase/tree/master/extensions/arquillian-decoder > Close this issue by Arquillian Jira Decoder extension > ----------------------------------------------------- > > Key: ARQ-1907 > URL: https://issues.jboss.org/browse/ARQ-1907 > Project: Arquillian > Issue Type: Task > Reporter: Stefan Miklosovic > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 27 09:33:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 27 Jan 2015 09:33:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-467) Screenshooter: Tests fail when no Drone contexts exist In-Reply-To: References: Message-ID: Luk?? Fry? created ARQGRA-467: --------------------------------- Summary: 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 Tue Jan 27 10:55:49 2015 From: issues at jboss.org (=?UTF-8?Q?Galder_Zamarre=C3=B1o_=28JIRA=29?=) Date: Tue, 27 Jan 2015 10:55:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-271) TestEnricher should be called in @BeforeClass In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035410#comment-13035410 ] Galder Zamarre?o commented on ARQ-271: -------------------------------------- Any updates? I believe this is required to achieve what's suggested in https://github.com/infinispan/infinispan-arquillian-container/issues/33 > TestEnricher should be called in @BeforeClass > --------------------------------------------- > > Key: ARQ-271 > URL: https://issues.jboss.org/browse/ARQ-271 > Project: Arquillian > Issue Type: Feature Request > Components: Runtime Enricher SPI, Test Harness Integration > Reporter: Thomas Diesler > Assignee: Aslak Knutsen > > The TestEnricher API could be extended such that static fields can be initialized. > @Inject > public static BundleContext context; > > @BeforeClass > public static void beforeClass() > { > System.out.println("BeforeClass: " + context); > } > There would be two calls to TestEnricher. > #1 After test class load, but before a call to @BeforeClass. > #2 After instantiation of the test class, but before a call to @Before > (#2 is the current behaviour) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 27 11:37:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 27 Jan 2015 11:37:49 -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 ] Luk?? Fry? updated ARQGRA-440: ------------------------------ Summary: Upgrade Drone to 2.0.0.Alpha3 and Arquillian Core to 1.1.5 (was: Upgrade Drone to 2.0.0.Alpha1 and Arquillian core to 1.1.4) > 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 > 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 Tue Jan 27 11:37:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 27 Jan 2015 11:37:49 -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 ] Luk?? Fry? reassigned ARQGRA-440: --------------------------------- Assignee: Stefan Miklosovic > 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 Tue Jan 27 11:37:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 27 Jan 2015 11:37:49 -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 ] Luk?? Fry? resolved ARQGRA-440. ------------------------------- Resolution: Done > 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 Tue Jan 27 11:38:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 27 Jan 2015 11:38:49 -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 ] Luk?? Fry? resolved ARQGRA-463. ------------------------------- Assignee: Luk?? Fry? Resolution: Done > 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 Tue Jan 27 11:42:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 27 Jan 2015 11:42:49 -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:comment-tabpanel&focusedCommentId=13035422#comment-13035422 ] Luk?? Fry? commented on ARQGRA-467: ----------------------------------- Fixed here: https://github.com/arquillian/arquillian-graphene/commit/f210b6d75c401046fb54fc0d585e68fbed74a29f > 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 Tue Jan 27 11:42:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 27 Jan 2015 11:42:49 -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 ] Luk?? Fry? resolved ARQGRA-467. ------------------------------- Resolution: Done > 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 Tue Jan 27 11:43:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 27 Jan 2015 11:43:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-86) Support XHR Halter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-86: ----------------------------- Fix Version/s: 2.1-Tracking (was: 2.1.0.Alpha2) > Support XHR Halter > ------------------ > > Key: ARQGRA-86 > URL: https://issues.jboss.org/browse/ARQGRA-86 > Project: Arquillian Graphene > Issue Type: Epic > Reporter: Luk?? Fry? > Assignee: Juraj H?ska > Fix For: 2.1-Tracking > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 27 11:43:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 27 Jan 2015 11:43:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-464) @Page injection should support parameter injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-464: ------------------------------ Fix Version/s: 2.1-Tracking (was: 2.1.0.Alpha2) > @Page injection should support parameter injection > -------------------------------------------------- > > Key: ARQGRA-464 > URL: https://issues.jboss.org/browse/ARQGRA-464 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.1.0.Alpha1 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.1-Tracking > > > Graphene should support @Page injection even for parameter injection in test methods. This would make test case much more compact. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 27 11:46:48 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 27 Jan 2015 11:46:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-464) @Page injection should support parameter injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035423#comment-13035423 ] Luk?? Fry? commented on ARQGRA-464: ----------------------------------- In theory it is sufficient to implement [TestEnrich#resolve(Method)|https://github.com/arquillian/arquillian-core/blob/master/test/spi/src/main/java/org/jboss/arquillian/test/spi/TestEnricher.java#L51] equivalent for [SearchContextTestEnricher|https://github.com/arquillian/arquillian-graphene/blob/master/spi/src/main/java/org/jboss/arquillian/graphene/spi/enricher/SearchContextTestEnricher.java], but I'm not sure where to take SearchContext here: https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/enricher/GrapheneEnricher.java#L55 > @Page injection should support parameter injection > -------------------------------------------------- > > Key: ARQGRA-464 > URL: https://issues.jboss.org/browse/ARQGRA-464 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.1.0.Alpha1 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.1-Tracking > > > Graphene should support @Page injection even for parameter injection in test methods. This would make test case much more compact. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Jan 27 11:56:49 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 27 Jan 2015 11:56: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 ] Luk?? Fry? updated ARQGRA-457: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done Thanks [~ppitonak] > 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 Wed Jan 28 10:49:50 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 28 Jan 2015 10:49:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-271) TestEnricher should be called in @BeforeClass In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035913#comment-13035913 ] Stefan Miklosovic commented on ARQ-271: --------------------------------------- This extension solves static injection of ContainerController for [~galder.zamarreno] https://github.com/arquillian/arquillian-showcase/tree/master/extensions/arquillian-static-container-controller > TestEnricher should be called in @BeforeClass > --------------------------------------------- > > Key: ARQ-271 > URL: https://issues.jboss.org/browse/ARQ-271 > Project: Arquillian > Issue Type: Feature Request > Components: Runtime Enricher SPI, Test Harness Integration > Reporter: Thomas Diesler > Assignee: Aslak Knutsen > > The TestEnricher API could be extended such that static fields can be initialized. > @Inject > public static BundleContext context; > > @BeforeClass > public static void beforeClass() > { > System.out.println("BeforeClass: " + context); > } > There would be two calls to TestEnricher. > #1 After test class load, but before a call to @BeforeClass. > #2 After instantiation of the test class, but before a call to @Before > (#2 is the current behaviour) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Jan 28 11:37:49 2015 From: issues at jboss.org (Vladislav Mikerin (JIRA)) Date: Wed, 28 Jan 2015 11:37:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1908) Test functions called N^2 times for a N-sized "where:" block In-Reply-To: References: Message-ID: Vladislav Mikerin created ARQ-1908: -------------------------------------- Summary: Test functions called N^2 times for a N-sized "where:" block Key: ARQ-1908 URL: https://issues.jboss.org/browse/ARQ-1908 Project: Arquillian Issue Type: Bug Components: Spock TestRunner Affects Versions: spock_1.0.0.Beta3 Environment: Linux, JBoss 6.3 EAP, Arquillian 1.1.5.Final Reporter: Vladislav Mikerin Assignee: Bartosz Majsak Priority: Minor Test functions called N^2 times for a "where:" spock block, where N is a size of the "where:" block. I think the framework iterates twice over the "where: " block. First on a client side and then in a container (for each iteration on the client side). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Jan 28 11:38:49 2015 From: issues at jboss.org (Vladislav Mikerin (JIRA)) Date: Wed, 28 Jan 2015 11:38:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1908) Test functions called N^2 times for a N-sized "where:" block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Mikerin updated ARQ-1908: ----------------------------------- Steps to Reproduce: Here is a simple example: @RunWith(ArquillianSputnik) class MySpec extends Specification{ @Deployment public static Archive "create deployment"() { return ShrinkWrap.create(WebArchive.class, "test.war") .addPackage(MySpec.class.getPackage()) .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml"); } def test() { when: println i; then: i == 1; where: i << (1..2); } } Output: 13:01:14,287 INFO stdout 1 13:01:14,350 INFO stdout 2 13:01:14,689 INFO stdout 1 13:01:14,778 INFO stdout 2 was: Here is a simple example: @RunWith(ArquillianSputnik) class MySpec extends Specification{ @Deployment public static Archive "create deployment"() { return ShrinkWrap.create(WebArchive.class, "test.war") .addPackage(MySpec.class.getPackage()) .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml"); } def test() { when: println i then: i == 1 where: i << (1..2) } } Output: 13:01:14,287 INFO stdout 1 13:01:14,350 INFO stdout 2 13:01:14,689 INFO stdout 1 13:01:14,778 INFO stdout 2 > Test functions called N^2 times for a N-sized "where:" block > ------------------------------------------------------------ > > Key: ARQ-1908 > URL: https://issues.jboss.org/browse/ARQ-1908 > Project: Arquillian > Issue Type: Bug > Components: Spock TestRunner > Affects Versions: spock_1.0.0.Beta3 > Environment: Linux, JBoss 6.3 EAP, Arquillian 1.1.5.Final > Reporter: Vladislav Mikerin > Assignee: Bartosz Majsak > Priority: Minor > > Test functions called N^2 times for a "where:" spock block, > where N is a size of the "where:" block. > I think the framework iterates twice over the "where: " block. > First on a client side and then in a container (for each iteration on the client side). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Jan 28 11:38:49 2015 From: issues at jboss.org (Vladislav Mikerin (JIRA)) Date: Wed, 28 Jan 2015 11:38:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1908) Test functions called N^2 times for a N-sized "where:" block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Mikerin updated ARQ-1908: ----------------------------------- Steps to Reproduce: Here is a simple example: @RunWith(ArquillianSputnik) class MySpec extends Specification{ @Deployment public static Archive "create deployment"() { return ShrinkWrap.create(WebArchive.class, "test.war") .addPackage(MySpec.class.getPackage()) .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml"); } def test() { when: println i; then: i == i; where: i << (1..2); } } Output: 13:01:14,287 INFO stdout 1 13:01:14,350 INFO stdout 2 13:01:14,689 INFO stdout 1 13:01:14,778 INFO stdout 2 was: Here is a simple example: @RunWith(ArquillianSputnik) class MySpec extends Specification{ @Deployment public static Archive "create deployment"() { return ShrinkWrap.create(WebArchive.class, "test.war") .addPackage(MySpec.class.getPackage()) .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml"); } def test() { when: println i; then: i == 1; where: i << (1..2); } } Output: 13:01:14,287 INFO stdout 1 13:01:14,350 INFO stdout 2 13:01:14,689 INFO stdout 1 13:01:14,778 INFO stdout 2 > Test functions called N^2 times for a N-sized "where:" block > ------------------------------------------------------------ > > Key: ARQ-1908 > URL: https://issues.jboss.org/browse/ARQ-1908 > Project: Arquillian > Issue Type: Bug > Components: Spock TestRunner > Affects Versions: spock_1.0.0.Beta3 > Environment: Linux, JBoss 6.3 EAP, Arquillian 1.1.5.Final > Reporter: Vladislav Mikerin > Assignee: Bartosz Majsak > Priority: Minor > > Test functions called N^2 times for a "where:" spock block, > where N is a size of the "where:" block. > I think the framework iterates twice over the "where: " block. > First on a client side and then in a container (for each iteration on the client side). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Jan 28 14:46:49 2015 From: issues at jboss.org (Nishant B (JIRA)) Date: Wed, 28 Jan 2015 14:46:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-466) Graphene guardAjax() does not work and gives RequestGuardException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035984#comment-13035984 ] Nishant B commented on ARQGRA-466: ---------------------------------- Thanks Lukas! Actually this was the issue on the JSF code side as we were sending regular request even though we used ajax button ( due to not been able to get jsf.js). And the fix was to have correct url mapping for our web,xml file. New Corrected URL pattern inside web.xml which works for this in my code Faces Servlet *.xhtml /javax.faces.resource/ /faces *.jsf Please close this issue. > Graphene guardAjax() does not work and gives RequestGuardException > ------------------------------------------------------------------ > > Key: ARQGRA-466 > URL: https://issues.jboss.org/browse/ARQGRA-466 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.1.0.Alpha1 > Environment: Windows 7, Google Chrome > Reporter: Nishant B > Priority: Critical > Labels: Graphene,, guardAjax, > > I am getting RequestGuardException when I am trying to use AjaxGuard() method of Graphene class with JSF 2 f:ajax tag. -- This message was sent by Atlassian JIRA (v6.3.11#6341)