From issues at jboss.org Thu Sep 1 01:50:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 1 Sep 2016 01:50:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2037) Support additional browser capabilities for Chrome In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2037: -------------------------------- Fix Version/s: (was: drone_2.1.0.Final) > Support additional browser capabilities for Chrome > --------------------------------------------------- > > Key: ARQ-2037 > URL: https://issues.jboss.org/browse/ARQ-2037 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Affects Versions: drone_2.0.0.Final > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > Support additional browser capabilities for Chrome & remove obsolete solution that uses chrome.switches https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/factory/ChromeDriverFactory.java#L86 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 01:51:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 1 Sep 2016 01:51:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2037) Support additional browser capabilities for Chrome In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2037: -------------------------------- Fix Version/s: drone_2.0.1.Final > Support additional browser capabilities for Chrome > --------------------------------------------------- > > Key: ARQ-2037 > URL: https://issues.jboss.org/browse/ARQ-2037 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Affects Versions: drone_2.0.0.Final > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.1.Final > > > Support additional browser capabilities for Chrome & remove obsolete solution that uses chrome.switches https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/factory/ChromeDriverFactory.java#L86 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 03:44:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 1 Sep 2016 03:44:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2039) The Weld Arquillian embedded adapter should not load classes that are excluded in beans.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated ARQ-2039: ----------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: weld_2.0.0.Beta3 Resolution: Done > The Weld Arquillian embedded adapter should not load classes that are excluded in beans.xml > ------------------------------------------------------------------------------------------- > > Key: ARQ-2039 > URL: https://issues.jboss.org/browse/ARQ-2039 > Project: Arquillian > Issue Type: Enhancement > Components: Weld Containers > Affects Versions: 2.0.0.Beta1 > Reporter: Antonin Stefanutti > Assignee: Tomas Remes > Fix For: weld_2.0.0.Beta3 > > > In some use cases, like the Camel CDI extension, some classes are excluded in the beans.xml and may not be in the class path. In that case, that leads to having a {{ClassNotFoundException}} thrown by the adapter that tries to load the bean classes regardless the exclusions from the bean archive descriptor: > https://github.com/arquillian/arquillian-container-weld/blob/d8f69bed899ed027ab271ba1c83a07ea51f58eb8/src/main/java/org/jboss/arquillian/container/weld/embedded/Utils.java#L151-L160 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 2 08:05:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Fri, 2 Sep 2016 08:05:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2037) Support additional browser capabilities for Chrome In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2037: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/65 > Support additional browser capabilities for Chrome > --------------------------------------------------- > > Key: ARQ-2037 > URL: https://issues.jboss.org/browse/ARQ-2037 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Affects Versions: drone_2.0.0.Final > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.1.Final > > > Support additional browser capabilities for Chrome & remove obsolete solution that uses chrome.switches https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/factory/ChromeDriverFactory.java#L86 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 2 09:06:01 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Fri, 2 Sep 2016 09:06:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-814) Should support injection of EJBs (as CDI Beans) in Weld Embedded In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288143#comment-13288143 ] Matous Jobanek commented on ARQ-814: ------------------------------------ WDYT [~tremes]? > Should support injection of EJBs (as CDI Beans) in Weld Embedded > ---------------------------------------------------------------- > > Key: ARQ-814 > URL: https://issues.jboss.org/browse/ARQ-814 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Affects Versions: weld_1.0.0.CR3 > Reporter: Anthony O. > Assignee: Marko Luk?a > Attachments: EJBTest.java > > > As seen in [this post on the Arquillian forum|https://community.jboss.org/message/723563], we cannot test that simple class as an NPE is thrown from {{org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.MockEjBServices}} which seems to be a copy of Weld code as [Aslak Knutsen|https://community.jboss.org/people/aslak] said. > {code} > @RunWith(Arquillian.class) > public class EJBTest { > @Deployment > public static JavaArchive createTestArchive() { > return ShrinkWrap > .create(JavaArchive.class, "test.jar") > .addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")); > } > @Stateless > public static class SomeService { > public String someMethod() { > return "test"; > } > } > @Inject > SomeService someService; > @Test > public void testStatelessCall() { > Assert.assertEquals("test", someService.someMethod()); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 2 09:24:01 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 2 Sep 2016 09:24:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-814) Should support injection of EJBs (as CDI Beans) in Weld Embedded In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288154#comment-13288154 ] Tomas Remes commented on ARQ-814: --------------------------------- [~mjobanek] Someone needs to take a look at the ancient PR and rebase it to current master then we can likely proceeed. > Should support injection of EJBs (as CDI Beans) in Weld Embedded > ---------------------------------------------------------------- > > Key: ARQ-814 > URL: https://issues.jboss.org/browse/ARQ-814 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Affects Versions: weld_1.0.0.CR3 > Reporter: Anthony O. > Assignee: Marko Luk?a > Attachments: EJBTest.java > > > As seen in [this post on the Arquillian forum|https://community.jboss.org/message/723563], we cannot test that simple class as an NPE is thrown from {{org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.MockEjBServices}} which seems to be a copy of Weld code as [Aslak Knutsen|https://community.jboss.org/people/aslak] said. > {code} > @RunWith(Arquillian.class) > public class EJBTest { > @Deployment > public static JavaArchive createTestArchive() { > return ShrinkWrap > .create(JavaArchive.class, "test.jar") > .addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")); > } > @Stateless > public static class SomeService { > public String someMethod() { > return "test"; > } > } > @Inject > SomeService someService; > @Test > public void testStatelessCall() { > Assert.assertEquals("test", someService.someMethod()); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 2 09:26:01 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 2 Sep 2016 09:26:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-814) Should support injection of EJBs (as CDI Beans) in Weld Embedded In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288154#comment-13288154 ] Tomas Remes edited comment on ARQ-814 at 9/2/16 9:25 AM: --------------------------------------------------------- [~mjobanek] Someone needs to take a look at the ancient PR and rebase it to current master then we can likely proceeed but as stated by Aslak it seems that the PR is not working correctly in all cases. Hopefully I can take a look sometimes.... was (Author: tremes): [~mjobanek] Someone needs to take a look at the ancient PR and rebase it to current master then we can likely proceeed. > Should support injection of EJBs (as CDI Beans) in Weld Embedded > ---------------------------------------------------------------- > > Key: ARQ-814 > URL: https://issues.jboss.org/browse/ARQ-814 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Affects Versions: weld_1.0.0.CR3 > Reporter: Anthony O. > Assignee: Marko Luk?a > Attachments: EJBTest.java > > > As seen in [this post on the Arquillian forum|https://community.jboss.org/message/723563], we cannot test that simple class as an NPE is thrown from {{org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.MockEjBServices}} which seems to be a copy of Weld code as [Aslak Knutsen|https://community.jboss.org/people/aslak] said. > {code} > @RunWith(Arquillian.class) > public class EJBTest { > @Deployment > public static JavaArchive createTestArchive() { > return ShrinkWrap > .create(JavaArchive.class, "test.jar") > .addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")); > } > @Stateless > public static class SomeService { > public String someMethod() { > return "test"; > } > } > @Inject > SomeService someService; > @Test > public void testStatelessCall() { > Assert.assertEquals("test", someService.someMethod()); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 04:05:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 5 Sep 2016 04:05:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-358) Should be able to disable specific Enrichers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288472#comment-13288472 ] Matous Jobanek commented on ARQ-358: ------------------------------------ I think that this is possible even with the current implementation - creating a dummy enricher and overwriting that one you want to disable with this new one. But I agree that this can be a little bit clumsy. > Should be able to disable specific Enrichers > -------------------------------------------- > > Key: ARQ-358 > URL: https://issues.jboss.org/browse/ARQ-358 > Project: Arquillian > Issue Type: Feature Request > Components: Runtime Enricher SPI > Affects Versions: 1.0.0.Alpha4 > Reporter: Aslak Knutsen > > In some cases you don't want the other enrichers to jump in and resolve things. > e.g. in a CDI test suite, @EJB injections should only be handled by CDI, not the EJBEnricher as well if CDI fails (that might be the test) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 07:10:00 2016 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Sep 2016 07:10:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2027) JDK 8 with wildfly failing for integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288586#comment-13288586 ] Bartosz Majsak commented on ARQ-2027: ------------------------------------- It's the issue with bridge methods being treated as part of the observer, as explained here: http://discuss.arquillian.org/t/moving-from-persistence-impl-to-persistence-dbunit-with-openejb-embedded-4/294/7 > JDK 8 with wildfly failing for integration tests > ------------------------------------------------ > > Key: ARQ-2027 > URL: https://issues.jboss.org/browse/ARQ-2027 > Project: Arquillian > Issue Type: Bug > Components: Extension - Persistence > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > > More details on discuss > http://discuss.arquillian.org/t/help-running-arquillian-persistence-int-tests/307/9 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 07:44:00 2016 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Sep 2016 07:44:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2042) Bridge methods treated as observer methods in JDK8 In-Reply-To: References: Message-ID: Bartosz Majsak created ARQ-2042: ----------------------------------- Summary: Bridge methods treated as observer methods in JDK8 Key: ARQ-2042 URL: https://issues.jboss.org/browse/ARQ-2042 Project: Arquillian Issue Type: Bug Components: Base Implementation Affects Versions: 1.1.11.Final Environment: JDK 8 Reporter: Bartosz Majsak The Java Compiler was changed with regards to synthetic methods and Annotations. Before, annotations on parameters of the original generic methods were NOT copied on to the synthetic bridge method. Now, the original annotation is present in 2 places: the generic method (with the actual type replaced in place of the type parameter) and the synthetic method. When it comes to the @Observes annotation, Arquillian will try to call the synthetic method (which receives Object) with any kind of event, leading to a ClassCastException (because the bridge method does an implicit cast to the actual type and calls the real generic method) The commit makes Arquillian ignore synthetic methods when searching for potential event listeners. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 07:44:00 2016 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Sep 2016 07:44:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2042) Bridge methods treated as observer methods in JDK8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak reassigned ARQ-2042: ----------------------------------- Assignee: Bartosz Majsak > Bridge methods treated as observer methods in JDK8 > -------------------------------------------------- > > Key: ARQ-2042 > URL: https://issues.jboss.org/browse/ARQ-2042 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation > Affects Versions: 1.1.11.Final > Environment: JDK 8 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > > The Java Compiler was changed with regards to synthetic methods and Annotations. > Before, annotations on parameters of the original generic methods were NOT copied on to the synthetic bridge method. > Now, the original annotation is present in 2 places: the generic method (with the actual type replaced in place of the type parameter) and the synthetic method. > When it comes to the @Observes annotation, Arquillian will try to call the synthetic method (which receives Object) with any kind of event, leading to a ClassCastException (because the bridge method does an implicit cast to the actual type and calls the real generic method) > The commit makes Arquillian ignore synthetic methods when searching for potential event listeners. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 07:45:01 2016 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Sep 2016 07:45:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2042) Bridge methods treated as observer methods in JDK8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2042: -------------------------------- Description: The Java Compiler was changed with regards to synthetic methods and Annotations. Before, annotations on parameters of the original generic methods were NOT copied on to the synthetic bridge method. Now, the original annotation is present in 2 places: the generic method (with the actual type replaced in place of the type parameter) and the synthetic method. When it comes to the @Observes annotation, Arquillian will try to call the synthetic method (which receives Object) with any kind of event, leading to a ClassCastException (because the bridge method does an implicit cast to the actual type and calls the real generic method) The commit makes Arquillian ignore synthetic methods when searching for potential event listeners. Discussion: http://discuss.arquillian.org/t/moving-from-persistence-impl-to-persistence-dbunit-with-openejb-embedded-4/294/7 See following bugs for details: * http://bugs.java.com/view_bug.do?bug_id=6695379 * http://bugs.java.com/view_bug.do?bug_id=8072365 was: The Java Compiler was changed with regards to synthetic methods and Annotations. Before, annotations on parameters of the original generic methods were NOT copied on to the synthetic bridge method. Now, the original annotation is present in 2 places: the generic method (with the actual type replaced in place of the type parameter) and the synthetic method. When it comes to the @Observes annotation, Arquillian will try to call the synthetic method (which receives Object) with any kind of event, leading to a ClassCastException (because the bridge method does an implicit cast to the actual type and calls the real generic method) The commit makes Arquillian ignore synthetic methods when searching for potential event listeners. > Bridge methods treated as observer methods in JDK8 > -------------------------------------------------- > > Key: ARQ-2042 > URL: https://issues.jboss.org/browse/ARQ-2042 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation > Affects Versions: 1.1.11.Final > Environment: JDK 8 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > > The Java Compiler was changed with regards to synthetic methods and Annotations. > Before, annotations on parameters of the original generic methods were NOT copied on to the synthetic bridge method. > Now, the original annotation is present in 2 places: the generic method (with the actual type replaced in place of the type parameter) and the synthetic method. > When it comes to the @Observes annotation, Arquillian will try to call the synthetic method (which receives Object) with any kind of event, leading to a ClassCastException (because the bridge method does an implicit cast to the actual type and calls the real generic method) > The commit makes Arquillian ignore synthetic methods when searching for potential event listeners. > Discussion: > http://discuss.arquillian.org/t/moving-from-persistence-impl-to-persistence-dbunit-with-openejb-embedded-4/294/7 > > See following bugs for details: > > * http://bugs.java.com/view_bug.do?bug_id=6695379 > * http://bugs.java.com/view_bug.do?bug_id=8072365 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 07:45:01 2016 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Sep 2016 07:45:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2042) Bridge methods treated as observer methods in JDK8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-2042 started by Bartosz Majsak. ------------------------------------------- > Bridge methods treated as observer methods in JDK8 > -------------------------------------------------- > > Key: ARQ-2042 > URL: https://issues.jboss.org/browse/ARQ-2042 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation > Affects Versions: 1.1.11.Final > Environment: JDK 8 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > > The Java Compiler was changed with regards to synthetic methods and Annotations. > Before, annotations on parameters of the original generic methods were NOT copied on to the synthetic bridge method. > Now, the original annotation is present in 2 places: the generic method (with the actual type replaced in place of the type parameter) and the synthetic method. > When it comes to the @Observes annotation, Arquillian will try to call the synthetic method (which receives Object) with any kind of event, leading to a ClassCastException (because the bridge method does an implicit cast to the actual type and calls the real generic method) > The commit makes Arquillian ignore synthetic methods when searching for potential event listeners. > Discussion: > http://discuss.arquillian.org/t/moving-from-persistence-impl-to-persistence-dbunit-with-openejb-embedded-4/294/7 > > See following bugs for details: > > * http://bugs.java.com/view_bug.do?bug_id=6695379 > * http://bugs.java.com/view_bug.do?bug_id=8072365 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 08:03:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 5 Sep 2016 08:03:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2043) Upgrade Selenium to 2.53.1 In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-2043: ----------------------------------- Summary: Upgrade Selenium to 2.53.1 Key: ARQ-2043 URL: https://issues.jboss.org/browse/ARQ-2043 Project: Arquillian Issue Type: Component Upgrade Components: Extension - Drone Affects Versions: drone_2.0.0.Final Reporter: Matous Jobanek Assignee: Matous Jobanek Fix For: drone_2.0.1.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 08:05:00 2016 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Sep 2016 08:05:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2042) Bridge methods treated as observer methods in JDK8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-2042 stopped by Bartosz Majsak. ------------------------------------------- > Bridge methods treated as observer methods in JDK8 > -------------------------------------------------- > > Key: ARQ-2042 > URL: https://issues.jboss.org/browse/ARQ-2042 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation > Affects Versions: 1.1.11.Final > Environment: JDK 8 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > > The Java Compiler was changed with regards to synthetic methods and Annotations. > Before, annotations on parameters of the original generic methods were NOT copied on to the synthetic bridge method. > Now, the original annotation is present in 2 places: the generic method (with the actual type replaced in place of the type parameter) and the synthetic method. > When it comes to the @Observes annotation, Arquillian will try to call the synthetic method (which receives Object) with any kind of event, leading to a ClassCastException (because the bridge method does an implicit cast to the actual type and calls the real generic method) > The commit makes Arquillian ignore synthetic methods when searching for potential event listeners. > Discussion: > http://discuss.arquillian.org/t/moving-from-persistence-impl-to-persistence-dbunit-with-openejb-embedded-4/294/7 > > See following bugs for details: > > * http://bugs.java.com/view_bug.do?bug_id=6695379 > * http://bugs.java.com/view_bug.do?bug_id=8072365 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 08:06:00 2016 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Sep 2016 08:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2042) Bridge methods treated as observer methods in JDK8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak resolved ARQ-2042. --------------------------------- Resolution: Done Pushed upstream * https://github.com/arquillian/arquillian-core/commit/b174cdb974f7420694af39e868e5de58dca23625 * https://github.com/arquillian/arquillian-core/commit/beeff29d45e4f2651d9840a64c06d822899902a8 > Bridge methods treated as observer methods in JDK8 > -------------------------------------------------- > > Key: ARQ-2042 > URL: https://issues.jboss.org/browse/ARQ-2042 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation > Affects Versions: 1.1.11.Final > Environment: JDK 8 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > > The Java Compiler was changed with regards to synthetic methods and Annotations. > Before, annotations on parameters of the original generic methods were NOT copied on to the synthetic bridge method. > Now, the original annotation is present in 2 places: the generic method (with the actual type replaced in place of the type parameter) and the synthetic method. > When it comes to the @Observes annotation, Arquillian will try to call the synthetic method (which receives Object) with any kind of event, leading to a ClassCastException (because the bridge method does an implicit cast to the actual type and calls the real generic method) > The commit makes Arquillian ignore synthetic methods when searching for potential event listeners. > Discussion: > http://discuss.arquillian.org/t/moving-from-persistence-impl-to-persistence-dbunit-with-openejb-embedded-4/294/7 > > See following bugs for details: > > * http://bugs.java.com/view_bug.do?bug_id=6695379 > * http://bugs.java.com/view_bug.do?bug_id=8072365 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 08:25:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 5 Sep 2016 08:25:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2044) Expose logic that creates browser capabilities In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-2044: ----------------------------------- Summary: Expose logic that creates browser capabilities Key: ARQ-2044 URL: https://issues.jboss.org/browse/ARQ-2044 Project: Arquillian Issue Type: Feature Request Components: Extension - Drone Affects Versions: drone_2.0.0.Final Reporter: Matous Jobanek Assignee: Matous Jobanek Fix For: drone_2.0.1.Final Create a public method there in every driver factory class, that returns DesiredCapabilities containing parsed and set capabilities. This can be easily used by other developers. Real use case is a usage in an integration Cube with Drone: https://github.com/arquillian/arquillian-cube/commit/3ef2d2f1c247b37c60f76bfdb060ca6a6999ac93 Do not implement by changing SPI as it is targeted in a minor release. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 09:57:02 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 5 Sep 2016 09:57:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2044) Expose logic that creates browser capabilities In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2044: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/67 > Expose logic that creates browser capabilities > ---------------------------------------------- > > Key: ARQ-2044 > URL: https://issues.jboss.org/browse/ARQ-2044 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Affects Versions: drone_2.0.0.Final > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.1.Final > > > Create a public method there in every driver factory class, that returns DesiredCapabilities containing parsed and set capabilities. This can be easily used by other developers. > Real use case is a usage in an integration Cube with Drone: https://github.com/arquillian/arquillian-cube/commit/3ef2d2f1c247b37c60f76bfdb060ca6a6999ac93 > Do not implement by changing SPI as it is targeted in a minor release. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 09:58:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 5 Sep 2016 09:58:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2043) Upgrade Selenium to 2.53.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2043: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/66 > Upgrade Selenium to 2.53.1 > -------------------------- > > Key: ARQ-2043 > URL: https://issues.jboss.org/browse/ARQ-2043 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Affects Versions: drone_2.0.0.Final > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.1.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 02:48:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 7 Sep 2016 02:48:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2041) Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated ARQ-2041: ----------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: weld_2.0.0.Beta3 Resolution: Done > Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider > ---------------------------------------------------------------------------------- > > Key: ARQ-2041 > URL: https://issues.jboss.org/browse/ARQ-2041 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Reporter: Martin Kouba > Assignee: Tomas Remes > Fix For: weld_2.0.0.Beta3 > > > {{org.jboss.weld.servlet.StaticWeldProvider}} is not used in Weld since 2.2.5.Final. Actually, the class was removed from master branch (Weld 3) and 2.4 branch (soon current stable). > The adapter should probably implement its own {{CDIProvider}} to support the simulated environments properly. > Affects 2.0.0.Beta2 and 1.0.0.CR9. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 14 08:20:02 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 14 Sep 2016 08:20:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2045) Add possibility to define firefox driver binary to support FF48 In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-2045: ----------------------------------- Summary: Add possibility to define firefox driver binary to support FF48 Key: ARQ-2045 URL: https://issues.jboss.org/browse/ARQ-2045 Project: Arquillian Issue Type: Feature Request Components: Extension - Drone Affects Versions: drone_2.0.0.Final Reporter: Matous Jobanek Assignee: Matous Jobanek Fix For: drone_2.0.1.Final ??Mozilla is changing the internals of Firefox in a way that makes it more stable and secure, but which also makes the community-provided Firefox Driver no longer work. As such, if you use Firefox for your testing, you'll need to use the geckodriver, which is an executable similar to the chromedriver and MS's edgedriver. You'll need to start using geckodriver even if you're using Selenium 2?? https://saucelabs.com/blog/selenium-3-is-coming -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 15 06:43:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 15 Sep 2016 06:43:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2044) Expose logic that creates browser capabilities In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-2044. ------------------------------- Resolution: Done Pushed upstream in https://github.com/arquillian/arquillian-extension-drone/commit/738c45b132ae1a05ee3d6d0002c482665919ca94 > Expose logic that creates browser capabilities > ---------------------------------------------- > > Key: ARQ-2044 > URL: https://issues.jboss.org/browse/ARQ-2044 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Affects Versions: drone_2.0.0.Final > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.1.Final > > > Create a public method there in every driver factory class, that returns DesiredCapabilities containing parsed and set capabilities. This can be easily used by other developers. > Real use case is a usage in an integration Cube with Drone: https://github.com/arquillian/arquillian-cube/commit/3ef2d2f1c247b37c60f76bfdb060ca6a6999ac93 > Do not implement by changing SPI as it is targeted in a minor release. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 15 06:44:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 15 Sep 2016 06:44:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2045) Add possibility to define firefox driver binary to support FF48 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-2045. ------------------------------- Resolution: Done Pushed upstream in https://github.com/arquillian/arquillian-extension-drone/commit/98843a2923acf201edb02738ba1113ec1ad74b32 > Add possibility to define firefox driver binary to support FF48 > --------------------------------------------------------------- > > Key: ARQ-2045 > URL: https://issues.jboss.org/browse/ARQ-2045 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Affects Versions: drone_2.0.0.Final > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.1.Final > > > ??Mozilla is changing the internals of Firefox in a way that makes it more stable and secure, but which also makes the community-provided Firefox Driver no longer work. As such, if you use Firefox for your testing, you'll need to use the geckodriver, which is an executable similar to the chromedriver and MS's edgedriver. You'll need to start using geckodriver even if you're using Selenium 2?? > https://saucelabs.com/blog/selenium-3-is-coming -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 15 06:45:01 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 15 Sep 2016 06:45:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2037) Support additional browser capabilities for Chrome In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-2037. ------------------------------- Resolution: Done Pushed upstream in https://github.com/arquillian/arquillian-extension-drone/commit/a1d3e46b7134dd0f6cf2425f1d204977416b7651 > Support additional browser capabilities for Chrome > --------------------------------------------------- > > Key: ARQ-2037 > URL: https://issues.jboss.org/browse/ARQ-2037 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Affects Versions: drone_2.0.0.Final > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.1.Final > > > Support additional browser capabilities for Chrome & remove obsolete solution that uses chrome.switches https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/factory/ChromeDriverFactory.java#L86 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 15 06:46:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 15 Sep 2016 06:46:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2043) Upgrade Selenium to 2.53.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-2043. ------------------------------- Resolution: Done Pushed upstream in https://github.com/arquillian/arquillian-extension-drone/commit/d09db831bfd1f295ca660358d75e3566076af02d > Upgrade Selenium to 2.53.1 > -------------------------- > > Key: ARQ-2043 > URL: https://issues.jboss.org/browse/ARQ-2043 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Affects Versions: drone_2.0.0.Final > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.1.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Sep 17 15:37:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Sat, 17 Sep 2016 15:37:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2041) Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294802#comment-13294802 ] John Ament commented on ARQ-2041: --------------------------------- The original that I reported still seems to be an issue, even after making this change. It seems to be alittle different though. Either I have logging off, or the repeated errors are gone. Easiest way to reproduce is to run https://github.com/hammock-project/hammock/blob/master/rest-spark/pom.xml#L93 . {{mvn clean install -Ptomcat-test}}. From debugging, it seems like tomcat never completes loading. I do see it going in a loop though. > Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider > ---------------------------------------------------------------------------------- > > Key: ARQ-2041 > URL: https://issues.jboss.org/browse/ARQ-2041 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Reporter: Martin Kouba > Assignee: Tomas Remes > Fix For: weld_2.0.0.Beta3 > > > {{org.jboss.weld.servlet.StaticWeldProvider}} is not used in Weld since 2.2.5.Final. Actually, the class was removed from master branch (Weld 3) and 2.4 branch (soon current stable). > The adapter should probably implement its own {{CDIProvider}} to support the simulated environments properly. > Affects 2.0.0.Beta2 and 1.0.0.CR9. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 19 03:49:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 19 Sep 2016 03:49:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2041) Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294881#comment-13294881 ] Tomas Remes commented on ARQ-2041: ---------------------------------- [~meetoblivion] Hi, well it's a synchronization problem, but I don't think it's a Weld or Arquillian problem. It's quite clear if you look at following jstack output (picked only the interesting part): {noformat} "localhost-startStop-1" #22 daemon prio=5 os_prio=0 tid=0x00007f8970004000 nid=0x4c83 waiting for monitor entry [0x00007f89c4d46000] java.lang.Thread.State: BLOCKED (on object monitor) at org.jboss.weld.servlet.HttpContextLifecycle.contextInitialized(HttpContextLifecycle.java:143) - waiting to lock <0x0000000709bc25d8> (a org.jboss.weld.Container) at org.jboss.weld.servlet.WeldInitialListener.contextInitialized(WeldInitialListener.java:105) at org.jboss.weld.servlet.api.helpers.ForwardingServletListener.contextInitialized(ForwardingServletListener.java:34) at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:122) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4727) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5189) - locked <0x0000000709bc3b10> (a org.apache.catalina.core.StandardContext) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) - locked <0x0000000709bc3b10> (a org.apache.catalina.core.StandardContext) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1403) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "main" #1 prio=5 os_prio=0 tid=0x00007f89f800b000 nid=0x4c22 waiting on condition [0x00007f8a00de2000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x0000000783c825e8> (a java.util.concurrent.FutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:911) - locked <0x0000000709bc37f8> (a org.apache.catalina.core.StandardEngine) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) - locked <0x0000000709bc37f8> (a org.apache.catalina.core.StandardEngine) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) - locked <0x0000000709bc37f8> (a org.apache.catalina.core.StandardEngine) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:422) - locked <0x0000000709bc37f8> (a org.apache.catalina.core.StandardEngine) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) - locked <0x0000000709bc2d48> (a org.apache.catalina.core.StandardService) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:791) - locked <0x0000000709bc6ae0> (a java.lang.Object) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) - locked <0x0000000709bc2920> (a org.apache.catalina.core.StandardServer) at org.apache.catalina.startup.Tomcat.start(Tomcat.java:356) at ws.ament.hammock.web.tomcat.TomcatWebServer.start(TomcatWebServer.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) at ws.ament.hammock.web.spi.WebServer$557810379$Proxy$_$$_WeldClientProxy.start(Unknown Source) at ws.ament.hammock.web.spi.StartWebServer.init(StartWebServer.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) at org.jboss.weld.injection.MethodInvocationStrategy$SpecialParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) - locked <0x0000000709bc25d8> (a org.jboss.weld.Container) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:277) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:255) at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:269) at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:258) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:154) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:148) at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53) at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35) at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28) at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:458) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90) - locked <0x0000000709c46b70> (a org.jboss.weld.bootstrap.WeldBootstrap) at org.jboss.arquillian.container.weld.embedded.mock.TestContainer.startContainer(TestContainer.java:240) at org.jboss.arquillian.container.weld.embedded.WeldMockContainer.deploy(WeldMockContainer.java:115) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) 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.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) 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.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) 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.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) 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.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) 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.ContainerEventController.execute(ContainerEventController.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) 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:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) 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.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) {noformat} TestContainer starts initialization and you start your {{WebServer}} (in this case Tomcat) during {{AfterDeploymentValidation}}. In this moment weld-servlet comes to the game, but please note the first TestContainer has not finished initialization yet. I don't consider this as a valid usage. As CDI spec states (for {{AfterDeploymentValidation}} event): {quote} The container must not allow any request to be processed by the deployment until all observers of this event return. {quote} > Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider > ---------------------------------------------------------------------------------- > > Key: ARQ-2041 > URL: https://issues.jboss.org/browse/ARQ-2041 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Reporter: Martin Kouba > Assignee: Tomas Remes > Fix For: weld_2.0.0.Beta3 > > > {{org.jboss.weld.servlet.StaticWeldProvider}} is not used in Weld since 2.2.5.Final. Actually, the class was removed from master branch (Weld 3) and 2.4 branch (soon current stable). > The adapter should probably implement its own {{CDIProvider}} to support the simulated environments properly. > Affects 2.0.0.Beta2 and 1.0.0.CR9. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 19 08:39:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 19 Sep 2016 08:39:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2041) Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295059#comment-13295059 ] John Ament commented on ARQ-2041: --------------------------------- Hmm if that were the case, I would expect the same behavior for all three (Tomcat, Jetty, Undertow). This issue only occurs with Tomcat. > Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider > ---------------------------------------------------------------------------------- > > Key: ARQ-2041 > URL: https://issues.jboss.org/browse/ARQ-2041 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Reporter: Martin Kouba > Assignee: Tomas Remes > Fix For: weld_2.0.0.Beta3 > > > {{org.jboss.weld.servlet.StaticWeldProvider}} is not used in Weld since 2.2.5.Final. Actually, the class was removed from master branch (Weld 3) and 2.4 branch (soon current stable). > The adapter should probably implement its own {{CDIProvider}} to support the simulated environments properly. > Affects 2.0.0.Beta2 and 1.0.0.CR9. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 08:35:01 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 20 Sep 2016 08:35:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2041) Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295657#comment-13295657 ] Tomas Remes commented on ARQ-2041: ---------------------------------- I realized that it basically means starting of 2 Weld/CDI containers (this means to set different ids to containers otherwise it's not supported). Anyway it's irrelevant to this issue so please feel free to file another one. > Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider > ---------------------------------------------------------------------------------- > > Key: ARQ-2041 > URL: https://issues.jboss.org/browse/ARQ-2041 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Reporter: Martin Kouba > Assignee: Tomas Remes > Fix For: weld_2.0.0.Beta3 > > > {{org.jboss.weld.servlet.StaticWeldProvider}} is not used in Weld since 2.2.5.Final. Actually, the class was removed from master branch (Weld 3) and 2.4 branch (soon current stable). > The adapter should probably implement its own {{CDIProvider}} to support the simulated environments properly. > Affects 2.0.0.Beta2 and 1.0.0.CR9. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 05:21:00 2016 From: issues at jboss.org (S Haster (JIRA)) Date: Tue, 27 Sep 2016 05:21:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2046) CDI Injection in methods should only inject @Inject parameters In-Reply-To: References: Message-ID: S Haster created ARQ-2046: ----------------------------- Summary: CDI Injection in methods should only inject @Inject parameters Key: ARQ-2046 URL: https://issues.jboss.org/browse/ARQ-2046 Project: Arquillian Issue Type: Bug Components: Runtime Enricher SPI Affects Versions: 1.1.11.Final Environment: git bash (mingw64) or eclipse, on windows 10 Reporter: S Haster Attachments: testcase.tar.gz The CDIInjectionEnricher should only inject method parameters annotated with @Inject, as is the spec and as it does with instance variables. The current implementation, which treats every method parameter as an injection point, conflicts with custom test enrichers. If my project is a beanarchive with bean-discovery-mode=all then every class is counted as a bean. If I have a testmethod where a custom enricher supplies one of the parameters the CDIInjectionEnricher also provides that parameter but by calling it's default parameter and not setting any other configuration, resulting in faulty testdata. Even worse, because the ordering of TestEnrichers as used in LocalTestExecutor#enrichArguments is not defined, sometimes the bean provided by the custom enricher will be used, and sometimes the one provided by CDIInjectionEnricher, leading to a testcase that will only fail *sometimes*. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 11:55:00 2016 From: issues at jboss.org (=?UTF-8?Q?Bj=C3=B6rn_Kautler_=28JIRA=29?=) Date: Tue, 27 Sep 2016 11:55:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2034) Test enrichment and JUnit @Rule do not harmonize In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13299252#comment-13299252 ] Bj?rn Kautler commented on ARQ-2034: ------------------------------------ [~mjobanek] Are you sure? As far as I remember what I have looked at in Arquillian code you copied some code from the {{BlockJUnit4ClassRunner}}, having own instances of {{withBefore}}, {{withAfter}} and so on, but calling the {{BlockJUnit4ClassRunner}}s {{withRules}} method via reflection. In the {{withRules}} you should also have a test available already I think, as that probably is the code that sets the instance fields that are annotated with {{@Rule}} to the actual rule instances. So I guess you have to change that you not hook into {{withBefore}} but already into {{withRules}} to do the enriching before the rules. > Test enrichment and JUnit @Rule do not harmonize > ------------------------------------------------ > > Key: ARQ-2034 > URL: https://issues.jboss.org/browse/ARQ-2034 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation > Affects Versions: 1.1.11.Final > Environment: junit 4.11 > arquillian-junit-container 1.1.11.Final > wildfly-arquillian-container-remote 8.1.0.Final > Reporter: Bj?rn Kautler > Assignee: Matous Jobanek > > We are starting with Arquillian tests on a remote WildFly instance. > I tried to write a JUnit {{@Rule}}, that can be used to make a login call for all test methods automatically, but I was not yet able to make it work, as I need an injected {{@Ejb}} instance for this. > I tried to add {{@EJB private InterfaceLoginManagement interfaceLoginManagement;}} to the {{TestRule}} implementation, but it stays {{null}}. I've read at ARQ-1954 that this should probably work, but unfortunately it is not, at least not with the remote container runner. {{org.jboss.arquillian.junit.extension.JUnitCoreExtension}} that should register {{org.jboss.arquillian.junit.extension.UpdateTestResultBeforeAfter}} and {{org.jboss.arquillian.junit.RulesEnricher}} is not even loaded on the container side. Maybe the {{META-INF/services/}} file is missing? > Then I tried to simply give the injected instance to the rule from the test class like > {code} > @EJB private InterfaceLoginManagement interfaceLoginManagement; > @Rule private LoginRule loginRule = new LoginRule(interfaceLoginManagement); > {code} > or even > {code} > @EJB private InterfaceLoginManagement interfaceLoginManagement; > @Rule public LoginRule getLoginRule() { > return new LoginRule(() -> { > return interfaceLoginManagement; > }); > } > {code} > with the {{LoginRule}} receiving a {{Supplier}} and call it as late as possible, i. e. in the rules {{apply()}} method. But even this is still too early as the EJB is still {{null}} and the test enrichers are only run between the {{@Rule}} applying and {{@Before}} methods. > So I'd like to suggest two things: > # Fix the implementation of ARQ-1954 if it should work on container side which I assume it should > # Make the test enrichments earlier in the lifecycle, i. e. before the {{@Rule}} s are being applied, or rather even before the {{@Rule}} methods are called, so that you at least can use the injected instances in the {{@Rule}} annotated methods to forward them to a rule. This is necessary even if top 1 is taken care of, because you might want to use a 3rd Party rule the code of which you cannot change. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 04:00:01 2016 From: issues at jboss.org (Colin Thorburn (JIRA)) Date: Fri, 30 Sep 2016 04:00:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2047) Use of Java 8 lambdas by injected class causes injection to fail silently In-Reply-To: References: Message-ID: Colin Thorburn created ARQ-2047: ----------------------------------- Summary: Use of Java 8 lambdas by injected class causes injection to fail silently Key: ARQ-2047 URL: https://issues.jboss.org/browse/ARQ-2047 Project: Arquillian Issue Type: Feature Request Components: Base Implementation Affects Versions: 1.1.11.Final Environment: Eclipse Neon, Windows Reporter: Colin Thorburn Have seen this bug elsewhere marked as resolved but it clearly isn't. To reproduce simply create a Junit 4 Arquiliian test in which EntityManager and UserTransaction fields are annontated for injection. Devise an @Test method contriving the use of (say) Runnable. Call a method in another class using the Runnable as a parameter Code using an anonymous inner class idiom; everything works fine. Code it as a lambda expression and, bizarrely, only the EntityManager is not injected (utx is OK!). No hint of anything awry in the log, no exception thrown, field is simply left null. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 09:35:01 2016 From: issues at jboss.org (Ken Finnigan (JIRA)) Date: Fri, 30 Sep 2016 09:35:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1857) Extract JavaScript in AngularJSDroneExtension to separete file for better maintainability In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Finnigan reassigned ARQ-1857: --------------------------------- Assignee: (was: Ken Finnigan) > Extract JavaScript in AngularJSDroneExtension to separete file for better maintainability > ----------------------------------------------------------------------------------------- > > Key: ARQ-1857 > URL: https://issues.jboss.org/browse/ARQ-1857 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - AngularJS > Affects Versions: angularjs_1.2.0.Alpha1 > Reporter: Stefan Miklosovic > Priority: Optional > > https://github.com/arquillian/arquillian-extension-angularjs/blob/master/graphene/impl/src/main/java/org/jboss/arquillian/graphene/angular/AngularJSDroneExtension.java#L107-L111 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 09:35:01 2016 From: issues at jboss.org (Ken Finnigan (JIRA)) Date: Fri, 30 Sep 2016 09:35:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1899) Usage of this extension causes some elements not to be found In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Finnigan reassigned ARQ-1899: --------------------------------- Assignee: (was: Ken Finnigan) > 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 > > 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.4.11#64026)