From issues at jboss.org Tue Mar 1 03:09:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 03:09:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2014) When warp is on classpath then o any non-warp arquillian test fails In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-2014: ----------------------------------- Summary: When warp is on classpath then o any non-warp arquillian test fails Key: ARQ-2014 URL: https://issues.jboss.org/browse/ARQ-2014 Project: Arquillian Issue Type: Bug Components: Extension - Warp Affects Versions: warp_1.0.0.Alpha7 Reporter: Matous Jobanek -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 03:10:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 03:10:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2014) When warp is on classpath then almost any non-warp arquillian test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2014: -------------------------------- Summary: When warp is on classpath then almost any non-warp arquillian test fails (was: When warp is on classpath then o any non-warp arquillian test fails) > When warp is on classpath then almost any non-warp arquillian test fails > ------------------------------------------------------------------------ > > Key: ARQ-2014 > URL: https://issues.jboss.org/browse/ARQ-2014 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Matous Jobanek > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 03:10:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 03:10:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2014) When warp is on classpath then almost any non-warp arquillian test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-2014: ----------------------------------- Assignee: Matous Jobanek > When warp is on classpath then almost any non-warp arquillian test fails > ------------------------------------------------------------------------ > > Key: ARQ-2014 > URL: https://issues.jboss.org/browse/ARQ-2014 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 03:15:01 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 03:15:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2014) When warp is on classpath then almost any non-warp arquillian test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2014: -------------------------------- Description: Consider a test suite that contains a warp test (so you need to have the warp dependency on your classpath) and some other non-warp arquillian test. Then the non-warp tests fails with various exceptions depending on the type of the test. > When warp is on classpath then almost any non-warp arquillian test fails > ------------------------------------------------------------------------ > > Key: ARQ-2014 > URL: https://issues.jboss.org/browse/ARQ-2014 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > Consider a test suite that contains a warp test (so you need to have the warp dependency on your classpath) and some other non-warp arquillian test. Then the non-warp tests fails with various exceptions depending on the type of the test. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 06:26:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 06:26:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170051#comment-13170051 ] Matous Jobanek commented on ARQGRA-483: --------------------------------------- Hi, there is also a problem when you have the Warp dependency on classpath and run non-warp arquillian test. See: https://issues.jboss.org/browse/ARQ-2014 > @Location might use the Wrong URL when used with Warp > ------------------------------------------------------ > > Key: ARQGRA-483 > URL: https://issues.jboss.org/browse/ARQGRA-483 > Project: Arquillian Graphene > Issue Type: Bug > Components: integration > Affects Versions: 2.1.0.Alpha2 > Reporter: Aslak Knutsen > Fix For: 2.1-Tracking > > > Both Graphene and Warp attempt to override the default Core URLResourceProvider. > Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. > When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. > Technically the two URLs used here could be different: > {code} > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > } > {code} > BaseURL could be proxied and the URL used by InitialPage not, or the other way around. > Graphene sets up it's ContextRootStore with which ever URL was provided last; > https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L54 > Core will do the opposite, which ever comes first. > When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. > This seems to be a good test case currently: > {code} > @Drone > private WebDriver driver; > > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort()); > } > {code} > Currently one will show 'proxy-port' and the other '8080'. > This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 06:27:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 06:27:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170052#comment-13170052 ] Matous Jobanek commented on ARQGRA-483: --------------------------------------- PRs: https://github.com/arquillian/arquillian-graphene/pull/153 https://github.com/arquillian/arquillian-extension-warp/pull/33 > @Location might use the Wrong URL when used with Warp > ------------------------------------------------------ > > Key: ARQGRA-483 > URL: https://issues.jboss.org/browse/ARQGRA-483 > Project: Arquillian Graphene > Issue Type: Bug > Components: integration > Affects Versions: 2.1.0.Alpha2 > Reporter: Aslak Knutsen > Fix For: 2.1-Tracking > > > Both Graphene and Warp attempt to override the default Core URLResourceProvider. > Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. > When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. > Technically the two URLs used here could be different: > {code} > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > } > {code} > BaseURL could be proxied and the URL used by InitialPage not, or the other way around. > Graphene sets up it's ContextRootStore with which ever URL was provided last; > https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L54 > Core will do the opposite, which ever comes first. > When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. > This seems to be a good test case currently: > {code} > @Drone > private WebDriver driver; > > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort()); > } > {code} > Currently one will show 'proxy-port' and the other '8080'. > This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 06:27:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 06:27:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2014) When warp is on classpath then almost any non-warp arquillian test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170053#comment-13170053 ] Matous Jobanek commented on ARQ-2014: ------------------------------------- PR: https://github.com/arquillian/arquillian-extension-warp/pull/33 > When warp is on classpath then almost any non-warp arquillian test fails > ------------------------------------------------------------------------ > > Key: ARQ-2014 > URL: https://issues.jboss.org/browse/ARQ-2014 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > Consider a test suite that contains a warp test (so you need to have the warp dependency on your classpath) and some other non-warp arquillian test. Then the non-warp tests fails with various exceptions depending on the type of the test. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 06:27:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 06:27:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2014) When warp is on classpath then almost every non-warp arquillian test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2014: -------------------------------- Summary: When warp is on classpath then almost every non-warp arquillian test fails (was: When warp is on classpath then almost any non-warp arquillian test fails) > When warp is on classpath then almost every non-warp arquillian test fails > -------------------------------------------------------------------------- > > Key: ARQ-2014 > URL: https://issues.jboss.org/browse/ARQ-2014 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > Consider a test suite that contains a warp test (so you need to have the warp dependency on your classpath) and some other non-warp arquillian test. Then the non-warp tests fails with various exceptions depending on the type of the test. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 07:07:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 07:07:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170079#comment-13170079 ] Matous Jobanek commented on ARQGRA-454: --------------------------------------- This depends on: https://github.com/arquillian/arquillian-graphene/pull/145 containing upgrade to arquilian-core 1.1.11.Final > NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final > -------------------------------------------------------------- > > Key: ARQGRA-454 > URL: https://issues.jboss.org/browse/ARQGRA-454 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Juergen Zimmermann > Assignee: Luk?? Fry? > Fix For: 2.0.4.Final, 2.1-Tracking > > > I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final. > The stacktrace: > {code} > org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException: > Error while initializing: class de.shop.util.IndexPage > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120) > at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291) > at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.lang.NullPointerException > at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73) > at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97) > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76) > ... 34 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 07:41:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 07:41:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2014) When warp is on classpath then almost every non-warp arquillian test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2014: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-extension-warp/pull/33 > When warp is on classpath then almost every non-warp arquillian test fails > -------------------------------------------------------------------------- > > Key: ARQ-2014 > URL: https://issues.jboss.org/browse/ARQ-2014 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > Consider a test suite that contains a warp test (so you need to have the warp dependency on your classpath) and some other non-warp arquillian test. Then the non-warp tests fails with various exceptions depending on the type of the test. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 07:42:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 07:42:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2013) Update Arquillian, Drone, Resolver, JaCoCo and JUnit to newer version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170105#comment-13170105 ] Matous Jobanek commented on ARQ-2013: ------------------------------------- PR: https://github.com/arquillian/arquillian-extension-warp/pull/32 Contains updates: Arquillian-core 1.1.11.Final Drone 2.0.0.Beta1 Resolver 2.2.2 Arquillian JaCoCo 1.0.0.Alpha8 JaCoCo 0.7.4.201502262128 (to use the same implementation as Arquillian-jacoco does) JUnit 4.12 > Update Arquillian, Drone, Resolver, JaCoCo and JUnit to newer version > --------------------------------------------------------------------- > > Key: ARQ-2013 > URL: https://issues.jboss.org/browse/ARQ-2013 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > Please update to newer versions to use the latest and greatest implementations. > In case of JaCoCo - the current version {{0.6.0.201210061924}} is not compatible with JDK8 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 08:04:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 08:04:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170129#comment-13170129 ] Matous Jobanek commented on ARQGRA-483: --------------------------------------- Just found out that there is already a Jira for this issue: https://issues.jboss.org/browse/ARQ-1952 > @Location might use the Wrong URL when used with Warp > ------------------------------------------------------ > > Key: ARQGRA-483 > URL: https://issues.jboss.org/browse/ARQGRA-483 > Project: Arquillian Graphene > Issue Type: Bug > Components: integration > Affects Versions: 2.1.0.Alpha2 > Reporter: Aslak Knutsen > Fix For: 2.1-Tracking > > > Both Graphene and Warp attempt to override the default Core URLResourceProvider. > Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. > When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. > Technically the two URLs used here could be different: > {code} > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > } > {code} > BaseURL could be proxied and the URL used by InitialPage not, or the other way around. > Graphene sets up it's ContextRootStore with which ever URL was provided last; > https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L54 > Core will do the opposite, which ever comes first. > When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. > This seems to be a good test case currently: > {code} > @Drone > private WebDriver driver; > > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort()); > } > {code} > Currently one will show 'proxy-port' and the other '8080'. > This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 08:13:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 08:13:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1923) Cannot build Warp 1.0.0.Alpha7 with OpenJDK 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170138#comment-13170138 ] Matous Jobanek commented on ARQ-1923: ------------------------------------- PR: https://github.com/arquillian/arquillian-extension-warp/pull/31 > Cannot build Warp 1.0.0.Alpha7 with OpenJDK 8 > --------------------------------------------- > > Key: ARQ-1923 > URL: https://issues.jboss.org/browse/ARQ-1923 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Pavol Pitonak > Fix For: warp_1.0.0.Beta1 > > > # git clone https://github.com/arquillian/arquillian-extension-warp.git > # mvn clean install > result: > * when launched with OpenJDK 8, one test fails TestExecutedMethod.testSerializedAnnotation > {code} > java.lang.IllegalStateException: java.lang.IllegalStateException: Error instantiating proxy for annotation. Annotation type: interface org.jboss.arquillian.warp.impl.shared.TestingAnnotation > at org.jboss.arquillian.warp.impl.shared.SerializedAnnotation.getAnnotation(SerializedAnnotation.java:61) > at org.jboss.arquillian.warp.impl.shared.TestExecutedMethod.testSerializedAnnotation(TestExecutedMethod.java:49) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: java.lang.IllegalStateException: Error instantiating proxy for annotation. Annotation type: interface org.jboss.arquillian.warp.impl.shared.TestingAnnotation > at org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider.get(AnnotationInstanceProvider.java:83) > at org.jboss.arquillian.warp.impl.shared.SerializedAnnotation.getAnnotation(SerializedAnnotation.java:59) > ... 24 more > Caused by: java.lang.IllegalAccessException: Class org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider can not access a member of class org.jboss.arquillian.warp.impl.shared.$Proxy5 with modifiers "public" > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101) > at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:295) > at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:287) > at java.lang.reflect.Constructor.newInstance(Constructor.java:398) > at org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider.get(AnnotationInstanceProvider.java:76) > ... 25 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 08:13:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 1 Mar 2016 08:13:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1923) Cannot build Warp 1.0.0.Alpha7 with OpenJDK 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-1923: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-extension-warp/pull/31 > Cannot build Warp 1.0.0.Alpha7 with OpenJDK 8 > --------------------------------------------- > > Key: ARQ-1923 > URL: https://issues.jboss.org/browse/ARQ-1923 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Pavol Pitonak > Fix For: warp_1.0.0.Beta1 > > > # git clone https://github.com/arquillian/arquillian-extension-warp.git > # mvn clean install > result: > * when launched with OpenJDK 8, one test fails TestExecutedMethod.testSerializedAnnotation > {code} > java.lang.IllegalStateException: java.lang.IllegalStateException: Error instantiating proxy for annotation. Annotation type: interface org.jboss.arquillian.warp.impl.shared.TestingAnnotation > at org.jboss.arquillian.warp.impl.shared.SerializedAnnotation.getAnnotation(SerializedAnnotation.java:61) > at org.jboss.arquillian.warp.impl.shared.TestExecutedMethod.testSerializedAnnotation(TestExecutedMethod.java:49) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: java.lang.IllegalStateException: Error instantiating proxy for annotation. Annotation type: interface org.jboss.arquillian.warp.impl.shared.TestingAnnotation > at org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider.get(AnnotationInstanceProvider.java:83) > at org.jboss.arquillian.warp.impl.shared.SerializedAnnotation.getAnnotation(SerializedAnnotation.java:59) > ... 24 more > Caused by: java.lang.IllegalAccessException: Class org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider can not access a member of class org.jboss.arquillian.warp.impl.shared.$Proxy5 with modifiers "public" > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101) > at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:295) > at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:287) > at java.lang.reflect.Constructor.newInstance(Constructor.java:398) > at org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider.get(AnnotationInstanceProvider.java:76) > ... 25 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 09:36:00 2016 From: issues at jboss.org (AbdelRahman Sinno (JIRA)) Date: Wed, 2 Mar 2016 09:36:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2015) JSF 1.2 is not supported by Warp tests, while this is not clear in documentation In-Reply-To: References: Message-ID: AbdelRahman Sinno created ARQ-2015: -------------------------------------- Summary: JSF 1.2 is not supported by Warp tests, while this is not clear in documentation Key: ARQ-2015 URL: https://issues.jboss.org/browse/ARQ-2015 Project: Arquillian Issue Type: Bug Components: Extension - Warp Reporter: AbdelRahman Sinno Arquillian Warp does not seem to support JSF 1.2 (along with RichFaces 3.3.3) based on my tests, while on the other hand nothing on the internet or any documentation mentions that this support is absent. For more information, the following exception is observed when running the unit test on a warp-managed tomcat, while the same application runs fine if deployed externally on the same tomcat: SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener java.lang.NoClassDefFoundError: javax/faces/context/FacesContextWrapper at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:791) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2818) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1159) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1647) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2404) at java.lang.Class.getConstructor0(Class.java:2714) at java.lang.Class.getConstructor(Class.java:1674) at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:558) at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:459) at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:260) at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:186) at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:131) at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:202) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:174) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4205) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4704) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:943) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:563) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1397) 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.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1500) at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:670) at org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:435) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.ClassNotFoundException: javax.faces.context.FacesContextWrapper at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1680) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526) ... 51 more -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 18:56:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 18:56:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: Steve Storck created ARQ-2016: --------------------------------- Summary: Test extensions should be separate from OSGi Container extensions Key: ARQ-2016 URL: https://issues.jboss.org/browse/ARQ-2016 Project: Arquillian Issue Type: Feature Request Components: OSGi Containers Affects Versions: osgi_2.1.0.Final Environment: Under Linux, and inside Karaf 4.x Reporter: Steve Storck Assignee: Thomas Diesler When the karaf container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 19:03:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 19:03:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the karaf container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. was: When the karaf container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the karaf container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java > {code:java} > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the proper packages are imported > public void run(RunNotifier notifier) > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > { > {code} > TestRunnerAdaptor.java > {code:java} > public static TestRunnerAdaptor build() > { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > {code} > SecurityActions.java > {code:java} > static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 19:03:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 19:03:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the karaf container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. was: When the karaf container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the karaf container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java > {code:java} > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > { > {code} > TestRunnerAdaptor.java > {code:java} > public static TestRunnerAdaptor build() > { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > {code} > SecurityActions.java > {code:java} > static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 19:16:01 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 19:16:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the karaf container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the karaf container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the karaf container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java > {code:java} > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > { > {code} > TestRunnerAdaptor.java > {code:java} > public static TestRunnerAdaptor build() > { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > {code} > SecurityActions.java > {code:java} > static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:00:01 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:00:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-osgi-container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the karaf container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-osgi-container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java > {code:java} > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > { > {code} > TestRunnerAdaptor.java > {code:java} > public static TestRunnerAdaptor build() > { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > {code} > SecurityActions.java > {code:java} > static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:00:01 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:00:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-osgi-container extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java > {code:java} > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > { > {code} > TestRunnerAdaptor.java > {code:java} > public static TestRunnerAdaptor build() > { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > {code} > SecurityActions.java > {code:java} > static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:02:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:02:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java > {code:java} > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > { > {code} > TestRunnerAdaptor.java > {code:java} > public static TestRunnerAdaptor build() > { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > {code} > SecurityActions.java > {code:java} > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:03:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:03:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java > {code:java} > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > { > {code} > TestRunnerAdaptor.java > {code:java} > public static TestRunnerAdaptor build() > { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > {code} > SecurityActions.java > {code:java} > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:04:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:04:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is omitted, of course. I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java > {code:java} > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > { > {code} > TestRunnerAdaptor.java > {code:java} > public static TestRunnerAdaptor build() > { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > {code} > SecurityActions.java > {code:java} > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:15:01 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:15:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock core) {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi) {code:java} public static TestRunnerAdaptor build() { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java (arquillian-core test/spi) {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} TestRunnerAdaptor.java {code:java} public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java (arquillian-testrunner-spock core) > {code:java} > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > { > {code} > EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi) > {code:java} > public static TestRunnerAdaptor build() > { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > {code} > SecurityActions.java (arquillian-core test/spi) > {code:java} > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:15:01 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:15:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock core) {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi) {code:java} public static TestRunnerAdaptor build() { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java (arquillian-core test/spi) {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock core) {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi) {code:java} public static TestRunnerAdaptor build() { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java (arquillian-core test/spi) {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java (arquillian-testrunner-spock core) > {code:java} > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > { > {code} > EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi) > {code:java} > public static TestRunnerAdaptor build() > { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > {code} > SecurityActions.java (arquillian-core test/spi) > {code:java} > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:25:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:25:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock) {code:java} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi) {code:java} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} SecurityActions.java (arquillian-core test/spi) {code:java} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock core) {code:java} import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity { {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi) {code:java} public static TestRunnerAdaptor build() { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } {code} SecurityActions.java (arquillian-core test/spi) {code:java} static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java (arquillian-testrunner-spock) > {code:java} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi) > {code:java} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > SecurityActions.java (arquillian-core test/spi) > {code:java} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:25:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:25:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock): {code:java} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} SecurityActions.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock) {code:java} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi) {code:java} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} SecurityActions.java (arquillian-core test/spi) {code:java} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java (arquillian-testrunner-spock): > {code:java} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): > {code:java} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > SecurityActions.java (arquillian-core test/spi): > {code:java} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:26:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:26:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock): {code:java} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} SecurityActions.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock): {code:java} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} SecurityActions.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java (arquillian-testrunner-spock): > {code:java} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): > {code:java} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > SecurityActions.java (arquillian-core test/spi): > {code:java} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) > { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:29:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:29:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock): {code:java} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} SecurityActions.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock): {code:java} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} SecurityActions.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java (arquillian-testrunner-spock): > {code:java} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): > {code:java} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > SecurityActions.java (arquillian-core test/spi): > {code:java} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:31:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:31:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock): {code:java} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} SecurityActions.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock): {code:java} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} SecurityActions.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java (arquillian-testrunner-spock): > {code:java} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): > {code:java} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > SecurityActions.java (arquillian-core test/spi): > {code:java} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:42:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:42:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171765#comment-13171765 ] Steve Storck commented on ARQ-2016: ----------------------------------- I'm sorry for all of the edits, but this is my first time submitting an issue here, and I did not realize that there was a preview button. I kept changing the code formatting and accepting the change over and over again. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > ArquillianSputnik.java (arquillian-testrunner-spock): > {code:java} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): > {code:java} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > SecurityActions.java (arquillian-core test/spi): > {code:java} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:46:01 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:46:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: ArquillianSputnik.java (arquillian-testrunner-spock): {code:java} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} SecurityActions.java (arquillian-core test/spi): {code:java} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:51:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:51:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: {code:title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} {code:title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} {code:title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 22:52:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Thu, 3 Mar 2016 22:52:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Description: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. was: When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: {code:title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} package org.jboss.arquillian.spock; public class ArquillianSputnik extends Sputnik { import org.jboss.arquillian.test.spi.TestRunnerAdaptor; import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; // Methods and fields omitted for brevity, but you can see that the // proper packages are imported public void run(RunNotifier notifier) { // Code omitted for brevity final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); // More code omitted for brevity } } {code} {code:title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} package org.jboss.arquillian.test.spi; public class TestRunnerAdaptorBuilder { private static final String DEFAULT_EXTENSION_CLASS = "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; private static final String TEST_RUNNER_IMPL_CLASS = "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; public static TestRunnerAdaptor build() { // omitted lines for brevity ManagerBuilder builder = ManagerBuilder.from() .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); return SecurityActions.newInstance( TEST_RUNNER_IMPL_CLASS, new Class[] {ManagerBuilder.class}, new Object[] {builder}, TestRunnerAdaptor.class); } } {code} {code:title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} package org.jboss.arquillian.test.spi; final class SecurityActions { static T newInstance(final String className, final Class[] argumentTypes, final Object[] arguments, final Class expectedType) { @SuppressWarnings("unchecked") Class implClass = (Class) loadClass(className); if (!expectedType.isAssignableFrom(implClass)) { throw new RuntimeException("Loaded class " + className + " is not of expected type " + expectedType); } return newInstance(implClass, argumentTypes, arguments); } } {code} I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 01:44:00 2016 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Fri, 4 Mar 2016 01:44:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171780#comment-13171780 ] Thomas Diesler commented on ARQ-2016: ------------------------------------- Perhaps you'd like to provide a PR for this > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > Assignee: Thomas Diesler > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 01:44:00 2016 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Fri, 4 Mar 2016 01:44:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler reassigned ARQ-2016: ----------------------------------- Assignee: (was: Thomas Diesler) > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 06:26:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Fri, 4 Mar 2016 06:26:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-484) Enriched element is not equal to the same element In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171901#comment-13171901 ] Matous Jobanek commented on ARQGRA-484: --------------------------------------- PR: https://github.com/arquillian/arquillian-graphene/pull/154 Could you please send your test case as a PR? Thanks. > Enriched element is not equal to the same element > ------------------------------------------------- > > Key: ARQGRA-484 > URL: https://issues.jboss.org/browse/ARQGRA-484 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha3 > Reporter: Ji?? ?tefek > > After upgrading to 2.1.0.Alpha3 from Alpha2, the following (simplified) test won't pass: > {code} > @FindBy(id="id") > private WebElement e; > @Test > private void test(){ > e.equals(e) > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 19:13:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Fri, 4 Mar 2016 19:13:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2017) Export embedded libraries in arquillian-container-osgi :: osgi-bundle In-Reply-To: References: Message-ID: Steve Storck created ARQ-2017: --------------------------------- Summary: Export embedded libraries in arquillian-container-osgi :: osgi-bundle Key: ARQ-2017 URL: https://issues.jboss.org/browse/ARQ-2017 Project: Arquillian Issue Type: Sub-task Components: OSGi Containers Affects Versions: osgi_2.1.0.Final Reporter: Steve Storck Assignee: Thomas Diesler So that test extensions other than the provided JUnit test extension can be used, more packages need to be exported for availability in the container for use by other extensions. This includes, but may not be limited to, the test SPI packages. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 19:14:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Fri, 4 Mar 2016 19:14:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Test extensions should be separate from OSGi Container extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172367#comment-13172367 ] Steve Storck commented on ARQ-2016: ----------------------------------- I don't see the "Assign to me" option in your JIRA. Is there a way that I can assign this story, and sub-tasks that I create, to myself? > Test extensions should be separate from OSGi Container extensions > ----------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 19:39:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Fri, 4 Mar 2016 19:39:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2017) Export embedded libraries in arquillian-container-osgi :: osgi-bundle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172369#comment-13172369 ] Steve Storck commented on ARQ-2017: ----------------------------------- [~thomas.diesler] : I notice that the "org.jboss.arquillian.osgi" package is listed both under and also under <_exportcontents>. I assume that you would prefer one or the other. Let me know which one is appropriate and I will remove the duplicate from the other element. I am also curious why you have declined to inline the embedded dependencies, but to embed them as jars instead. There may be classloader improvements, among other things, if they are inlined instead. Are there licensing issues that require you to embed the jars? Otherwise, I would like to try inlining them instead. Please let me know. Thanks! > Export embedded libraries in arquillian-container-osgi :: osgi-bundle > --------------------------------------------------------------------- > > Key: ARQ-2017 > URL: https://issues.jboss.org/browse/ARQ-2017 > Project: Arquillian > Issue Type: Sub-task > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > Assignee: Thomas Diesler > > So that test extensions other than the provided JUnit test extension can be used, more packages need to be exported for availability in the container for use by other extensions. This includes, but may not be limited to, the test SPI packages. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 5 10:08:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Sat, 5 Mar 2016 10:08:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) arquillian-osgi-bundle includes dependencies but does not export them In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Summary: arquillian-osgi-bundle includes dependencies but does not export them (was: Test extensions should be separate from OSGi Container extensions) > arquillian-osgi-bundle includes dependencies but does not export them > --------------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 5 12:49:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Sat, 5 Mar 2016 12:49:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2018) Upgrade Karaf to latest release for arquillian-container-karaf-managed In-Reply-To: References: Message-ID: Steve Storck created ARQ-2018: --------------------------------- Summary: Upgrade Karaf to latest release for arquillian-container-karaf-managed Key: ARQ-2018 URL: https://issues.jboss.org/browse/ARQ-2018 Project: Arquillian Issue Type: Enhancement Components: OSGi Containers Affects Versions: osgi_2.1.0.Final Reporter: Steve Storck Assignee: Thomas Diesler The current version of the managed Karaf container is 2.3.3. This was released in 2013, so it is quite outdated. The latest release is 4.0.4, which was released in early 2016. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 5 12:51:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Sat, 5 Mar 2016 12:51:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) arquillian-osgi-bundle includes dependencies but does not export them In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172448#comment-13172448 ] Steve Storck commented on ARQ-2016: ----------------------------------- When I get the container and bundle configurations sufficient to ensure the use of custom test runners, I will want to be able to test it with the latest version of Karaf. > arquillian-osgi-bundle includes dependencies but does not export them > --------------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 5 12:51:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Sat, 5 Mar 2016 12:51:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) arquillian-osgi-bundle includes dependencies but does not export them In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172448#comment-13172448 ] Steve Storck edited comment on ARQ-2016 at 3/5/16 12:50 PM: ------------------------------------------------------------ When I get the container and bundle configurations sufficient to ensure the use of custom test runners, I will want to be able to test it with the latest version of Karaf. Added link to ARQ-2018 was (Author: stevestorck): When I get the container and bundle configurations sufficient to ensure the use of custom test runners, I will want to be able to test it with the latest version of Karaf. > arquillian-osgi-bundle includes dependencies but does not export them > --------------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 5 14:19:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Sat, 5 Mar 2016 14:19:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2019) Upgrade Karaf to 4.0.4 In-Reply-To: References: Message-ID: Steve Storck created ARQ-2019: --------------------------------- Summary: Upgrade Karaf to 4.0.4 Key: ARQ-2019 URL: https://issues.jboss.org/browse/ARQ-2019 Project: Arquillian Issue Type: Sub-task Components: OSGi Containers Affects Versions: osgi_2.1.0.Final Reporter: Steve Storck Assignee: Thomas Diesler Upgrade Karaf to 4.0.4 for managed and remote. Update execution environment accordingly. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 5 14:23:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Sat, 5 Mar 2016 14:23:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2018) Upgrade Karaf to latest release for arquillian-container-karaf-managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2018: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/47 Fixed. > Upgrade Karaf to latest release for arquillian-container-karaf-managed > ---------------------------------------------------------------------- > > Key: ARQ-2018 > URL: https://issues.jboss.org/browse/ARQ-2018 > Project: Arquillian > Issue Type: Enhancement > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > Assignee: Thomas Diesler > > The current version of the managed Karaf container is 2.3.3. This was released in 2013, so it is quite outdated. The latest release is 4.0.4, which was released in early 2016. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 5 14:24:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Sat, 5 Mar 2016 14:24:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2019) Upgrade Karaf to 4.0.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2019: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/47 > Upgrade Karaf to 4.0.4 > ---------------------- > > Key: ARQ-2019 > URL: https://issues.jboss.org/browse/ARQ-2019 > Project: Arquillian > Issue Type: Sub-task > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > Assignee: Thomas Diesler > > Upgrade Karaf to 4.0.4 for managed and remote. Update execution environment accordingly. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 02:43:00 2016 From: issues at jboss.org (=?UTF-8?Q?Ji=C5=99=C3=AD_=C5=A0tefek_=28JIRA=29?=) Date: Mon, 7 Mar 2016 02:43:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-484) Enriched element is not equal to the same element In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172547#comment-13172547 ] Ji?? ?tefek commented on ARQGRA-484: ------------------------------------ PR: https://github.com/arquillian/arquillian-graphene/pull/155 > Enriched element is not equal to the same element > ------------------------------------------------- > > Key: ARQGRA-484 > URL: https://issues.jboss.org/browse/ARQGRA-484 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha3 > Reporter: Ji?? ?tefek > > After upgrading to 2.1.0.Alpha3 from Alpha2, the following (simplified) test won't pass: > {code} > @FindBy(id="id") > private WebElement e; > @Test > private void test(){ > e.equals(e) > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 03:27:00 2016 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 7 Mar 2016 03:27:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2017) Export embedded libraries in arquillian-container-osgi :: osgi-bundle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler reassigned ARQ-2017: ----------------------------------- Assignee: (was: Thomas Diesler) > Export embedded libraries in arquillian-container-osgi :: osgi-bundle > --------------------------------------------------------------------- > > Key: ARQ-2017 > URL: https://issues.jboss.org/browse/ARQ-2017 > Project: Arquillian > Issue Type: Sub-task > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > > So that test extensions other than the provided JUnit test extension can be used, more packages need to be exported for availability in the container for use by other extensions. This includes, but may not be limited to, the test SPI packages. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 03:30:01 2016 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 7 Mar 2016 03:30:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) arquillian-osgi-bundle includes dependencies but does not export them In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172564#comment-13172564 ] Thomas Diesler commented on ARQ-2016: ------------------------------------- I believe you have to sign some sort of contributor agreement to enter our JIRA system. Meanwhile, you are welcome to assign stuff to me when you want me to make the next progress step. > arquillian-osgi-bundle includes dependencies but does not export them > --------------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 03:31:00 2016 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 7 Mar 2016 03:31:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2018) Upgrade Karaf to latest release for arquillian-container-karaf-managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172565#comment-13172565 ] Thomas Diesler commented on ARQ-2018: ------------------------------------- This PR does not seem to update the KAraf version in the main pom. > Upgrade Karaf to latest release for arquillian-container-karaf-managed > ---------------------------------------------------------------------- > > Key: ARQ-2018 > URL: https://issues.jboss.org/browse/ARQ-2018 > Project: Arquillian > Issue Type: Enhancement > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > Assignee: Thomas Diesler > > The current version of the managed Karaf container is 2.3.3. This was released in 2013, so it is quite outdated. The latest release is 4.0.4, which was released in early 2016. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 03:31:01 2016 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 7 Mar 2016 03:31:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2018) Upgrade Karaf to latest release for arquillian-container-karaf-managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler reassigned ARQ-2018: ----------------------------------- Assignee: (was: Thomas Diesler) > Upgrade Karaf to latest release for arquillian-container-karaf-managed > ---------------------------------------------------------------------- > > Key: ARQ-2018 > URL: https://issues.jboss.org/browse/ARQ-2018 > Project: Arquillian > Issue Type: Enhancement > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > > The current version of the managed Karaf container is 2.3.3. This was released in 2013, so it is quite outdated. The latest release is 4.0.4, which was released in early 2016. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 03:31:01 2016 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 7 Mar 2016 03:31:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2019) Upgrade Karaf to 4.0.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler reassigned ARQ-2019: ----------------------------------- Assignee: (was: Thomas Diesler) > Upgrade Karaf to 4.0.4 > ---------------------- > > Key: ARQ-2019 > URL: https://issues.jboss.org/browse/ARQ-2019 > Project: Arquillian > Issue Type: Sub-task > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > > Upgrade Karaf to 4.0.4 for managed and remote. Update execution environment accordingly. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 10:08:00 2016 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Mon, 7 Mar 2016 10:08:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2020) wlp-remote arquillian support for wlp server assembly In-Reply-To: References: Message-ID: Gerhard Poul created ARQ-2020: --------------------------------- Summary: wlp-remote arquillian support for wlp server assembly Key: ARQ-2020 URL: https://issues.jboss.org/browse/ARQ-2020 Project: Arquillian Issue Type: Feature Request Components: WebSphere Containers Reporter: D K Assignee: Gerhard Poul Fix For: was_1.0.0.next Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: https://github.com/WASdev/ci.maven#liberty-assembly It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. https://github.com/arquillian/arquillian-container-was/tree/master/wlp-managed-8.5 This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 10:09:00 2016 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Mon, 7 Mar 2016 10:09:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2020) wlp-remote arquillian support for wlp server assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul updated ARQ-2020: ------------------------------ Git Pull Request: (was: https://github.com/gpoul/arquillian-container-was/tree/ARQ-1756) > wlp-remote arquillian support for wlp server assembly > ----------------------------------------------------- > > Key: ARQ-2020 > URL: https://issues.jboss.org/browse/ARQ-2020 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: D K > Assignee: Gerhard Poul > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 10:09:00 2016 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Mon, 7 Mar 2016 10:09:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2020) wlp-remote arquillian support for wlp server assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul updated ARQ-2020: ------------------------------ Fix Version/s: (was: was_1.0.0.next) > wlp-remote arquillian support for wlp server assembly > ----------------------------------------------------- > > Key: ARQ-2020 > URL: https://issues.jboss.org/browse/ARQ-2020 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: D K > Assignee: Gerhard Poul > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 10:09:00 2016 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Mon, 7 Mar 2016 10:09:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2020) wlp-remote arquillian support for wlp server assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul updated ARQ-2020: ------------------------------ Reporter: Gerhard Poul (was: D K) > wlp-remote arquillian support for wlp server assembly > ----------------------------------------------------- > > Key: ARQ-2020 > URL: https://issues.jboss.org/browse/ARQ-2020 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: Gerhard Poul > Assignee: Gerhard Poul > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 10:09:00 2016 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Mon, 7 Mar 2016 10:09:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2020) wlp-remote arquillian support for wlp server assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul updated ARQ-2020: ------------------------------ Description: Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: https://github.com/WASdev/ci.maven#liberty-assembly It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. was: Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: https://github.com/WASdev/ci.maven#liberty-assembly It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. https://github.com/arquillian/arquillian-container-was/tree/master/wlp-managed-8.5 This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. > wlp-remote arquillian support for wlp server assembly > ----------------------------------------------------- > > Key: ARQ-2020 > URL: https://issues.jboss.org/browse/ARQ-2020 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: D K > Assignee: Gerhard Poul > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 10:33:01 2016 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Mon, 7 Mar 2016 10:33:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1961) Exception while undeploying application in WebSphere Liberty Profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul closed ARQ-1961. ----------------------------- Resolution: Cannot Reproduce > Exception while undeploying application in WebSphere Liberty Profile > -------------------------------------------------------------------- > > Key: ARQ-1961 > URL: https://issues.jboss.org/browse/ARQ-1961 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Environment: OS: Windows 7 Professional > Arquillian: org.jboss.arquillian:arquillian-bom:1.1.6.Final > org.jboss.arquillian.container:arquillian-wlp-managed-8.5:1.0.0.Beta2 > Shrinkwrap: org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-bom:2.1.1 > WebSphere Liberty Profile: 8.5.5.4 > JUnit: 4.11 > Java: IBM Java 1.7 in 1.6 mode > Reporter: Dave Westerman > Assignee: Gerhard Poul > Attachments: DaveWesterman_arquillian-enhanced-trace.zip > > > I am trying to test my JEE application with Arquillian running under WebSphere Liberty Profile 8.5.5.4. My Arquillian tests run against an EJB and a REST service. > > All the tests run successfully. However, the JUnit test process always ends with an exception: > > org.jboss.arquillian.container.spi.client.container.DeploymentException: Exception while undeploying application. > at org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer.undeploy(WLPManagedContainer.java:419) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$4.call(ContainerDeployController.java:205) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$4.call(ContainerDeployController.java:185) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.undeploy(ContainerDeployController.java:184) > ... > Caused by: org.jboss.arquillian.container.spi.client.container.DeploymentException: Unable to delete archive from apps directory > at org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer.undeploy(WLPManagedContainer.java:405) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$4.call(ContainerDeployController.java:205) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$4.call(ContainerDeployController.java:185) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.undeploy(ContainerDeployController.java:184) > I ran this with a trace that Gerhard suggested, and here is the relevant section of the trace: > Jun 24, 2015 11:14:18 AM org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer undeploy > FINER: ENTRY > Jun 24, 2015 11:14:18 AM org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer getServerXML > FINER: server.xml: /IBM/WLP8554/usr/servers/taskcalendar/server.xml > Jun 24, 2015 11:14:18 AM org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer getServerXML > FINER: server.xml: /IBM/WLP8554/usr/servers/taskcalendar/server.xml > Jun 24, 2015 11:14:18 AM org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer waitForMBeanTargetState > FINER: ENTRY > [AUDIT ] CWWKG0016I: Starting server configuration update. > [AUDIT ] CWWKG0028A: Processing included configuration resource: C:\IBM\WLP8554\usr\servers\taskcalendar\serverApplication.xml > [AUDIT ] CWWKG0028A: Processing included configuration resource: C:\IBM\WLP8554\usr\servers\taskcalendar\serverKeyStore.xml > [AUDIT ] CWWKG0028A: Processing included configuration resource: C:\IBM\WLP8554\usr\servers\taskcalendar\serverBasicUserRegistry.xml > [AUDIT ] CWWKG0028A: Processing included configuration resource: C:\IBM\WLP8554\usr\servers\taskcalendar\serverTesting.xml > [AUDIT ] CWWKG0017I: The server configuration was successfully updated in 0.043 seconds. > [AUDIT ] CWWKT0017I: Web application removed (default_host): http://dlwester:30080/task-calendar-ejb-task-calendar-bean-test/ > [INFO ] SRVE0253I: [task-calendar-ejb-task-calendar-bean-test] [/task-calendar-ejb-task-calendar-bean-test] [ArquillianServletRunner]: Destroy successful. > [INFO ] OpenWebBeans Container was stopped for context path, [/task-calendar-ejb-task-calendar-bean-test] > [INFO ] CNTR4003I: The task-calendar-ejb-task-calendar-bean-test.war EJB module in the task-calendar-ejb-task-calendar-bean-test application is stopping. > [INFO ] CNTR4004I: The task-calendar-ejb-task-calendar-bean-test.war EJB module in the task-calendar-ejb-task-calendar-bean-test application has stopped successfully. > [AUDIT ] CWWKZ0009I: The application task-calendar-ejb-task-calendar-bean-test has stopped successfully. > Jun 24, 2015 11:14:18 AM org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer waitForMBeanTargetState > FINER: RETURN > Jun 24, 2015 11:14:18 AM org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer getAppDirectory > FINER: appDir: /IBM/WLP8554/usr/servers/taskcalendar/apps > Jun 24, 2015 11:14:19 AM org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer stop > FINER: ENTRY > Jun 24, 2015 11:14:19 AM org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer stop > FINER: RETURN -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 16:11:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Mon, 7 Mar 2016 16:11:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2018) Upgrade Karaf to latest release for arquillian-container-karaf-managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173132#comment-13173132 ] Steve Storck commented on ARQ-2018: ----------------------------------- I missed that file on the original commit. Updated the pull request, so it should be good now. > Upgrade Karaf to latest release for arquillian-container-karaf-managed > ---------------------------------------------------------------------- > > Key: ARQ-2018 > URL: https://issues.jboss.org/browse/ARQ-2018 > Project: Arquillian > Issue Type: Enhancement > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > > The current version of the managed Karaf container is 2.3.3. This was released in 2013, so it is quite outdated. The latest release is 4.0.4, which was released in early 2016. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 16:15:01 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Mon, 7 Mar 2016 16:15:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) arquillian-osgi-bundle includes dependencies but does not export them In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173134#comment-13173134 ] Steve Storck commented on ARQ-2016: ----------------------------------- [~thomas.diesler]: I cannot change the assignee at all, so I'll just comment here and link you when I need that to be done, if that's all right with you. By the way, I need some information with regard to how auxiliary archives are deployed to a container (particularly to an OSGi container) and if they are available in the same way that all bundles are available, with their exports available to the tests. The spock extension that I want to use deploys an auxiliary archive, and the exports seem to be unavailable in the container when my tests are deployed. I have searched with Google quite a bit, and I have looked into the code, but I am not finding anything definitive. > arquillian-osgi-bundle includes dependencies but does not export them > --------------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 16:16:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Mon, 7 Mar 2016 16:16:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2018) Upgrade Karaf to latest release for arquillian-container-karaf-managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173132#comment-13173132 ] Steve Storck edited comment on ARQ-2018 at 3/7/16 4:15 PM: ----------------------------------------------------------- [~thomas.diesler]: I missed that file on the original commit. Updated the pull request, so it should be good now. was (Author: stevestorck): I missed that file on the original commit. Updated the pull request, so it should be good now. > Upgrade Karaf to latest release for arquillian-container-karaf-managed > ---------------------------------------------------------------------- > > Key: ARQ-2018 > URL: https://issues.jboss.org/browse/ARQ-2018 > Project: Arquillian > Issue Type: Enhancement > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > > The current version of the managed Karaf container is 2.3.3. This was released in 2013, so it is quite outdated. The latest release is 4.0.4, which was released in early 2016. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 16:37:00 2016 From: issues at jboss.org (Arcadiy Ivanov (JIRA)) Date: Mon, 7 Mar 2016 16:37:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2021) Allow extending ArquillianConfig service In-Reply-To: References: Message-ID: Arcadiy Ivanov created ARQ-2021: ----------------------------------- Summary: Allow extending ArquillianConfig service Key: ARQ-2021 URL: https://issues.jboss.org/browse/ARQ-2021 Project: Arquillian Issue Type: Feature Request Components: JBoss AS Containers Reporter: Arcadiy Ivanov Priority: Minor Need to be able to add dependencies to ArquillianConfig MSC service and inject values from other services. Need to allow adding dependencies to Arquillian Service archive. Fix a broken switch. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 16:41:00 2016 From: issues at jboss.org (Arcadiy Ivanov (JIRA)) Date: Mon, 7 Mar 2016 16:41:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2021) Allow extending ArquillianConfig service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arcadiy Ivanov updated ARQ-2021: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/wildfly/wildfly-arquillian/pull/68 > Allow extending ArquillianConfig service > ---------------------------------------- > > Key: ARQ-2021 > URL: https://issues.jboss.org/browse/ARQ-2021 > Project: Arquillian > Issue Type: Feature Request > Components: JBoss AS Containers > Reporter: Arcadiy Ivanov > Priority: Minor > > Need to be able to add dependencies to ArquillianConfig MSC service and inject values from other services. > Need to allow adding dependencies to Arquillian Service archive. > Fix a broken switch. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 16:42:00 2016 From: issues at jboss.org (Arcadiy Ivanov (JIRA)) Date: Mon, 7 Mar 2016 16:42:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2021) Allow extending ArquillianConfig service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173148#comment-13173148 ] Arcadiy Ivanov commented on ARQ-2021: ------------------------------------- Also please cut a release if the change is approved. > Allow extending ArquillianConfig service > ---------------------------------------- > > Key: ARQ-2021 > URL: https://issues.jboss.org/browse/ARQ-2021 > Project: Arquillian > Issue Type: Feature Request > Components: JBoss AS Containers > Reporter: Arcadiy Ivanov > Priority: Minor > > Need to be able to add dependencies to ArquillianConfig MSC service and inject values from other services. > Need to allow adding dependencies to Arquillian Service archive. > Fix a broken switch. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 16:52:00 2016 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 7 Mar 2016 16:52:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2021) Allow extending ArquillianConfig service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173156#comment-13173156 ] James Perkins commented on ARQ-2021: ------------------------------------ This should be moved to https://issues.jboss.org/projects/WFARQ. I don't seem to have permissions to move it though. > Allow extending ArquillianConfig service > ---------------------------------------- > > Key: ARQ-2021 > URL: https://issues.jboss.org/browse/ARQ-2021 > Project: Arquillian > Issue Type: Feature Request > Components: JBoss AS Containers > Reporter: Arcadiy Ivanov > Priority: Minor > > Need to be able to add dependencies to ArquillianConfig MSC service and inject values from other services. > Need to allow adding dependencies to Arquillian Service archive. > Fix a broken switch. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 17:05:00 2016 From: issues at jboss.org (Arcadiy Ivanov (JIRA)) Date: Mon, 7 Mar 2016 17:05:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2021) Allow extending ArquillianConfig service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173164#comment-13173164 ] Arcadiy Ivanov commented on ARQ-2021: ------------------------------------- [~swd847] [~thomas.diesler] Please review. > Allow extending ArquillianConfig service > ---------------------------------------- > > Key: ARQ-2021 > URL: https://issues.jboss.org/browse/ARQ-2021 > Project: Arquillian > Issue Type: Feature Request > Components: JBoss AS Containers > Reporter: Arcadiy Ivanov > Priority: Minor > > Need to be able to add dependencies to ArquillianConfig MSC service and inject values from other services. > Need to allow adding dependencies to Arquillian Service archive. > Fix a broken switch. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 17:06:00 2016 From: issues at jboss.org (Arcadiy Ivanov (JIRA)) Date: Mon, 7 Mar 2016 17:06:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2021) Allow extending ArquillianConfig service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173166#comment-13173166 ] Arcadiy Ivanov commented on ARQ-2021: ------------------------------------- [~jamezp]Thanks. Neither have I. :( > Allow extending ArquillianConfig service > ---------------------------------------- > > Key: ARQ-2021 > URL: https://issues.jboss.org/browse/ARQ-2021 > Project: Arquillian > Issue Type: Feature Request > Components: JBoss AS Containers > Reporter: Arcadiy Ivanov > Priority: Minor > > Need to be able to add dependencies to ArquillianConfig MSC service and inject values from other services. > Need to allow adding dependencies to Arquillian Service archive. > Fix a broken switch. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 17:13:00 2016 From: issues at jboss.org (Arcadiy Ivanov (JIRA)) Date: Mon, 7 Mar 2016 17:13:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2021) Allow extending ArquillianConfig service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173166#comment-13173166 ] Arcadiy Ivanov edited comment on ARQ-2021 at 3/7/16 5:12 PM: ------------------------------------------------------------- [~jamezp] Thanks. Neither have I. :( was (Author: arcivanov): [~jamezp]Thanks. Neither have I. :( > Allow extending ArquillianConfig service > ---------------------------------------- > > Key: ARQ-2021 > URL: https://issues.jboss.org/browse/ARQ-2021 > Project: Arquillian > Issue Type: Feature Request > Components: JBoss AS Containers > Reporter: Arcadiy Ivanov > Priority: Minor > > Need to be able to add dependencies to ArquillianConfig MSC service and inject values from other services. > Need to allow adding dependencies to Arquillian Service archive. > Fix a broken switch. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 02:59:00 2016 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Tue, 8 Mar 2016 02:59:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) arquillian-osgi-bundle includes dependencies but does not export them In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173278#comment-13173278 ] Thomas Diesler commented on ARQ-2016: ------------------------------------- This is ordinary OSGi. ARQ provides the infrastructure for bundle deployment through @Deployment. Beyond that, package visibility is handled by whatever OSGi framework Karaf uses. > arquillian-osgi-bundle includes dependencies but does not export them > --------------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 04:58:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Tue, 8 Mar 2016 04:58:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) arquillian-osgi-bundle includes dependencies but does not export them In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173353#comment-13173353 ] Steve Storck commented on ARQ-2016: ----------------------------------- I'm asking specifically about the AuxiliaryArchiveAppender. When the auxiliary archive is created, what's the process by which it is deployed? And is it a bundle or is it only intended as a library to go into a web archive? I'm using a jar archive for my test, so I'm trying to understand the best way to make Spock available within the container. > arquillian-osgi-bundle includes dependencies but does not export them > --------------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 05:02:00 2016 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Tue, 8 Mar 2016 05:02:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) arquillian-osgi-bundle includes dependencies but does not export them In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173356#comment-13173356 ] Thomas Diesler commented on ARQ-2016: ------------------------------------- Again, this is OSGi. The ARQ server side is a bundle so is every artefact that gets installed on the underlying OSGi framework. IIRC, the transport of data between client/server side happens via OSGi JMX. > arquillian-osgi-bundle includes dependencies but does not export them > --------------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 07:37:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Wed, 9 Mar 2016 07:37:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2018) Upgrade Karaf to latest release for arquillian-container-karaf-managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2018: ------------------------------ Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/48 (was: https://github.com/arquillian/arquillian-container-osgi/pull/47) > Upgrade Karaf to latest release for arquillian-container-karaf-managed > ---------------------------------------------------------------------- > > Key: ARQ-2018 > URL: https://issues.jboss.org/browse/ARQ-2018 > Project: Arquillian > Issue Type: Enhancement > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > > The current version of the managed Karaf container is 2.3.3. This was released in 2013, so it is quite outdated. The latest release is 4.0.4, which was released in early 2016. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 07:38:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Wed, 9 Mar 2016 07:38:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2019) Upgrade Karaf to 4.0.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2019: ------------------------------ Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/48 (was: https://github.com/arquillian/arquillian-container-osgi/pull/47) > Upgrade Karaf to 4.0.4 > ---------------------- > > Key: ARQ-2019 > URL: https://issues.jboss.org/browse/ARQ-2019 > Project: Arquillian > Issue Type: Sub-task > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > > Upgrade Karaf to 4.0.4 for managed and remote. Update execution environment accordingly. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 07:42:00 2016 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 9 Mar 2016 07:42:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2019) Upgrade Karaf to 4.0.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler updated ARQ-2019: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Done > Upgrade Karaf to 4.0.4 > ---------------------- > > Key: ARQ-2019 > URL: https://issues.jboss.org/browse/ARQ-2019 > Project: Arquillian > Issue Type: Sub-task > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > > Upgrade Karaf to 4.0.4 for managed and remote. Update execution environment accordingly. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 11:39:00 2016 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Wed, 9 Mar 2016 11:39:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2001) Log status code in WLPRestClient.isServerUp() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul updated ARQ-2001: ------------------------------ Fix Version/s: was_1.0.0.next > Log status code in WLPRestClient.isServerUp() > --------------------------------------------- > > Key: ARQ-2001 > URL: https://issues.jboss.org/browse/ARQ-2001 > Project: Arquillian > Issue Type: Enhancement > Components: WebSphere Containers > Reporter: Paul Holding > Assignee: Gerhard Poul > Fix For: was_1.0.0.next > > > The WLPRestClient.isServerUp() method doesn't log the status code returned when the following line of code is executed > {code:java} > HttpResponse result = executor.execute(Request.Get(hostName)).returnResponse(); > {code} > The lack of logging makes is impossible to tell why the isServerUp() check failure occurred and the only information returned is a LifecycleException thrown by WLPRemoteContainer with the text "Remote server is not started". This can be misleading as the server may be up but something else is wrong such as an authentication failure. > Adding something similar to the logging in WLPRestClient.deploy(File archive) would allow the HTTP status code to be recorded and make troubleshooting a lot easier. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 11:40:00 2016 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Wed, 9 Mar 2016 11:40:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2001) Log status code in WLPRestClient.isServerUp() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul updated ARQ-2001: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Log status code in WLPRestClient.isServerUp() > --------------------------------------------- > > Key: ARQ-2001 > URL: https://issues.jboss.org/browse/ARQ-2001 > Project: Arquillian > Issue Type: Enhancement > Components: WebSphere Containers > Reporter: Paul Holding > Assignee: Gerhard Poul > Fix For: was_1.0.0.next > > > The WLPRestClient.isServerUp() method doesn't log the status code returned when the following line of code is executed > {code:java} > HttpResponse result = executor.execute(Request.Get(hostName)).returnResponse(); > {code} > The lack of logging makes is impossible to tell why the isServerUp() check failure occurred and the only information returned is a LifecycleException thrown by WLPRemoteContainer with the text "Remote server is not started". This can be misleading as the server may be up but something else is wrong such as an authentication failure. > Adding something similar to the logging in WLPRestClient.deploy(File archive) would allow the HTTP status code to be recorded and make troubleshooting a lot easier. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 14:56:02 2016 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Wed, 9 Mar 2016 14:56:02 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1756) wlp-managed arquillian support for wlp server assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul updated ARQ-1756: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > wlp-managed arquillian support for wlp server assembly > ------------------------------------------------------ > > Key: ARQ-1756 > URL: https://issues.jboss.org/browse/ARQ-1756 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: D K > Assignee: Gerhard Poul > Fix For: was_1.0.0.next > > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > https://github.com/arquillian/arquillian-container-was/tree/master/wlp-managed-8.5 > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 17:19:00 2016 From: issues at jboss.org (Steve Storck (JIRA)) Date: Wed, 9 Mar 2016 17:19:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2016) Improve the ability to add custom extensions for the containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Storck updated ARQ-2016: ------------------------------ Summary: Improve the ability to add custom extensions for the containers (was: arquillian-osgi-bundle includes dependencies but does not export them) > Improve the ability to add custom extensions for the containers > --------------------------------------------------------------- > > Key: ARQ-2016 > URL: https://issues.jboss.org/browse/ARQ-2016 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Environment: Under Linux, and inside Karaf 4.x > Reporter: Steve Storck > > When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows: > {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid} > package org.jboss.arquillian.spock; > public class ArquillianSputnik extends Sputnik { > import org.jboss.arquillian.test.spi.TestRunnerAdaptor; > import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder; > // Methods and fields omitted for brevity, but you can see that the > // proper packages are imported > public void run(RunNotifier notifier) { > // Code omitted for brevity > final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build(); > // More code omitted for brevity > } > } > {code} > {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > public class TestRunnerAdaptorBuilder { > private static final String DEFAULT_EXTENSION_CLASS = > "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader"; > private static final String TEST_RUNNER_IMPL_CLASS = > "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor"; > public static TestRunnerAdaptor build() { > // omitted lines for brevity > ManagerBuilder builder = ManagerBuilder.from() > .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS)); > return SecurityActions.newInstance( > TEST_RUNNER_IMPL_CLASS, > new Class[] {ManagerBuilder.class}, > new Object[] {builder}, > TestRunnerAdaptor.class); > } > } > {code} > {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid} > package org.jboss.arquillian.test.spi; > final class SecurityActions { > static T newInstance(final String className, > final Class[] argumentTypes, > final Object[] arguments, > final Class expectedType) { > @SuppressWarnings("unchecked") > Class implClass = (Class) loadClass(className); > if (!expectedType.isAssignableFrom(implClass)) { > throw new RuntimeException("Loaded class " + > className + > " is not of expected type " + > expectedType); > } > return newInstance(implClass, argumentTypes, arguments); > } > } > {code} > I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own. > Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Mar 13 04:40:00 2016 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Sun, 13 Mar 2016 04:40:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2020) wlp-remote arquillian support for wlp server assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul updated ARQ-2020: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-was/pull/26 > wlp-remote arquillian support for wlp server assembly > ----------------------------------------------------- > > Key: ARQ-2020 > URL: https://issues.jboss.org/browse/ARQ-2020 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: Gerhard Poul > Assignee: Gerhard Poul > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Mar 13 16:39:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Sun, 13 Mar 2016 16:39:00 -0400 (EDT) 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: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/152 > @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 > 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.4.11#64026) From issues at jboss.org Sun Mar 13 16:39:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Sun, 13 Mar 2016 16:39:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-483: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/153 > @Location might use the Wrong URL when used with Warp > ------------------------------------------------------ > > Key: ARQGRA-483 > URL: https://issues.jboss.org/browse/ARQGRA-483 > Project: Arquillian Graphene > Issue Type: Bug > Components: integration > Affects Versions: 2.1.0.Alpha2 > Reporter: Aslak Knutsen > Fix For: 2.1-Tracking > > > Both Graphene and Warp attempt to override the default Core URLResourceProvider. > Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. > When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. > Technically the two URLs used here could be different: > {code} > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > } > {code} > BaseURL could be proxied and the URL used by InitialPage not, or the other way around. > Graphene sets up it's ContextRootStore with which ever URL was provided last; > https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L54 > Core will do the opposite, which ever comes first. > When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. > This seems to be a good test case currently: > {code} > @Drone > private WebDriver driver; > > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort()); > } > {code} > Currently one will show 'proxy-port' and the other '8080'. > This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Mar 13 16:40:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Sun, 13 Mar 2016 16:40:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-474) Remove arquillian-graphene depchain as no one uses it In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-474: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/150 > Remove arquillian-graphene depchain as no one uses it > ----------------------------------------------------- > > Key: ARQGRA-474 > URL: https://issues.jboss.org/browse/ARQGRA-474 > Project: Arquillian Graphene > Issue Type: Task > Reporter: Luk?? Fry? > Fix For: 2.1-Tracking > > > Docs and tutorials mention graphene-webdriver depchain: > https://docs.jboss.org/author/display/ARQGRA2/Framework+Integration+Options > http://arquillian.org/guides/functional_testing_using_graphene/ > The depchains are not used by EAP BOMs too: > https://issues.jboss.org/browse/JDF-840 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Mar 13 16:40:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Sun, 13 Mar 2016 16:40:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-477) Upgrade to Core 1.1.8, Drone 2.0.0.Alpha5, Selenium 2.47.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-477: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/145 > Upgrade to Core 1.1.8, Drone 2.0.0.Alpha5, Selenium 2.47.1 > ----------------------------------------------------------- > > Key: ARQGRA-477 > URL: https://issues.jboss.org/browse/ARQGRA-477 > Project: Arquillian Graphene > Issue Type: Component Upgrade > Reporter: Luk?? Fry? > Assignee: Matous Jobanek > Fix For: 2.1-Tracking > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Mar 13 16:40:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Sun, 13 Mar 2016 16:40:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-472) TestCases are copy-pasted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-472: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/151 > TestCases are copy-pasted > ------------------------- > > Key: ARQGRA-472 > URL: https://issues.jboss.org/browse/ARQGRA-472 > Project: Arquillian Graphene > Issue Type: Bug > Components: unit-test > Affects Versions: 2.1-Tracking > Reporter: Vitalii Grygoryuk > Assignee: Matous Jobanek > Fix For: 2.1-Tracking > > > TestHandlingOfStaleElements.testDeletion() and TestHandlingOfStaleElements.testReplacement() are both testing deletion, so there is no test case for node replacement logic: > {code} > @Test > public void testDeletion() { > rootElement.isDisplayed(); > executor.executeScript("return arguments[0].parentNode.removeChild(arguments[0])", rootElement); > try { > rootElement.isDisplayed(); > fail("rootElement should not be found"); > } catch (NoSuchElementException e) { > } > } > @Test > public void testReplacement() { > rootElement.isDisplayed(); > executor.executeScript("return arguments[0].parentNode.removeChild(arguments[0])", rootElement); > try { > rootElement.isDisplayed(); > fail("rootElement should not be found"); > } catch (NoSuchElementException e) { > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Mar 13 16:40:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Sun, 13 Mar 2016 16:40:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-471) GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-471: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/147 > GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException > ------------------------------------------------------------------------------- > > Key: ARQGRA-471 > URL: https://issues.jboss.org/browse/ARQGRA-471 > Project: Arquillian Graphene > Issue Type: Enhancement > Affects Versions: 2.1.0.Alpha2 > Reporter: Ji?? ?tefek > Priority: Trivial > Fix For: 2.1-Tracking > > > When you perform an assertion in e.g. a page fragment, which leads to throwing an AssertionError, the error is wrapped in IllegalStateException. This is imho an unwanted behaviour and these errors should be forwarded. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:05:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:05:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-477) Upgrade to Core 1.1.8, Drone 2.0.0.Alpha5, Selenium 2.47.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-477: ------------------------------ Fix Version/s: 2.1.0.Beta1 (was: 2.1-Tracking) > Upgrade to Core 1.1.8, Drone 2.0.0.Alpha5, Selenium 2.47.1 > ----------------------------------------------------------- > > Key: ARQGRA-477 > URL: https://issues.jboss.org/browse/ARQGRA-477 > Project: Arquillian Graphene > Issue Type: Component Upgrade > Reporter: Luk?? Fry? > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:06:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-483: ------------------------------ Fix Version/s: 2.1.0.Beta1 (was: 2.1-Tracking) > @Location might use the Wrong URL when used with Warp > ------------------------------------------------------ > > Key: ARQGRA-483 > URL: https://issues.jboss.org/browse/ARQGRA-483 > Project: Arquillian Graphene > Issue Type: Bug > Components: integration > Affects Versions: 2.1.0.Alpha2 > Reporter: Aslak Knutsen > Fix For: 2.1.0.Beta1 > > > Both Graphene and Warp attempt to override the default Core URLResourceProvider. > Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. > When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. > Technically the two URLs used here could be different: > {code} > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > } > {code} > BaseURL could be proxied and the URL used by InitialPage not, or the other way around. > Graphene sets up it's ContextRootStore with which ever URL was provided last; > https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L54 > Core will do the opposite, which ever comes first. > When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. > This seems to be a good test case currently: > {code} > @Drone > private WebDriver driver; > > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort()); > } > {code} > Currently one will show 'proxy-port' and the other '8080'. > This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:06:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-483: ------------------------------ Status: Resolved (was: Pull Request Sent) Assignee: Matous Jobanek Resolution: Done > @Location might use the Wrong URL when used with Warp > ------------------------------------------------------ > > Key: ARQGRA-483 > URL: https://issues.jboss.org/browse/ARQGRA-483 > Project: Arquillian Graphene > Issue Type: Bug > Components: integration > Affects Versions: 2.1.0.Alpha2 > Reporter: Aslak Knutsen > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > > Both Graphene and Warp attempt to override the default Core URLResourceProvider. > Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. > When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. > Technically the two URLs used here could be different: > {code} > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > } > {code} > BaseURL could be proxied and the URL used by InitialPage not, or the other way around. > Graphene sets up it's ContextRootStore with which ever URL was provided last; > https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L54 > Core will do the opposite, which ever comes first. > When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. > This seems to be a good test case currently: > {code} > @Drone > private WebDriver driver; > > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort()); > } > {code} > Currently one will show 'proxy-port' and the other '8080'. > This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:06:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:06:00 -0400 (EDT) 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: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 2.1.0.Beta1 (was: 2.1-Tracking) Resolution: Done > @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 > Fix For: 2.1.0.Beta1 > > > 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.4.11#64026) From issues at jboss.org Mon Mar 14 03:06:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:06:00 -0400 (EDT) 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? reassigned ARQGRA-464: --------------------------------- Assignee: Matous Jobanek > @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: Matous Jobanek > Fix For: 2.1.0.Beta1 > > > 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.4.11#64026) From issues at jboss.org Mon Mar 14 03:07:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:07:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-472) TestCases are copy-pasted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-472: ------------------------------ Fix Version/s: 2.1.0.Beta1 (was: 2.1-Tracking) > TestCases are copy-pasted > ------------------------- > > Key: ARQGRA-472 > URL: https://issues.jboss.org/browse/ARQGRA-472 > Project: Arquillian Graphene > Issue Type: Bug > Components: unit-test > Affects Versions: 2.1-Tracking > Reporter: Vitalii Grygoryuk > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > > TestHandlingOfStaleElements.testDeletion() and TestHandlingOfStaleElements.testReplacement() are both testing deletion, so there is no test case for node replacement logic: > {code} > @Test > public void testDeletion() { > rootElement.isDisplayed(); > executor.executeScript("return arguments[0].parentNode.removeChild(arguments[0])", rootElement); > try { > rootElement.isDisplayed(); > fail("rootElement should not be found"); > } catch (NoSuchElementException e) { > } > } > @Test > public void testReplacement() { > rootElement.isDisplayed(); > executor.executeScript("return arguments[0].parentNode.removeChild(arguments[0])", rootElement); > try { > rootElement.isDisplayed(); > fail("rootElement should not be found"); > } catch (NoSuchElementException e) { > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:07:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:07:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-472) TestCases are copy-pasted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-472: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > TestCases are copy-pasted > ------------------------- > > Key: ARQGRA-472 > URL: https://issues.jboss.org/browse/ARQGRA-472 > Project: Arquillian Graphene > Issue Type: Bug > Components: unit-test > Affects Versions: 2.1-Tracking > Reporter: Vitalii Grygoryuk > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > > TestHandlingOfStaleElements.testDeletion() and TestHandlingOfStaleElements.testReplacement() are both testing deletion, so there is no test case for node replacement logic: > {code} > @Test > public void testDeletion() { > rootElement.isDisplayed(); > executor.executeScript("return arguments[0].parentNode.removeChild(arguments[0])", rootElement); > try { > rootElement.isDisplayed(); > fail("rootElement should not be found"); > } catch (NoSuchElementException e) { > } > } > @Test > public void testReplacement() { > rootElement.isDisplayed(); > executor.executeScript("return arguments[0].parentNode.removeChild(arguments[0])", rootElement); > try { > rootElement.isDisplayed(); > fail("rootElement should not be found"); > } catch (NoSuchElementException e) { > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:07:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:07:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-474) Remove arquillian-graphene depchain as no one uses it In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-474: ------------------------------ Fix Version/s: 2.1.0.Beta1 (was: 2.1-Tracking) > Remove arquillian-graphene depchain as no one uses it > ----------------------------------------------------- > > Key: ARQGRA-474 > URL: https://issues.jboss.org/browse/ARQGRA-474 > Project: Arquillian Graphene > Issue Type: Task > Reporter: Luk?? Fry? > Fix For: 2.1.0.Beta1 > > > Docs and tutorials mention graphene-webdriver depchain: > https://docs.jboss.org/author/display/ARQGRA2/Framework+Integration+Options > http://arquillian.org/guides/functional_testing_using_graphene/ > The depchains are not used by EAP BOMs too: > https://issues.jboss.org/browse/JDF-840 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:07:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:07:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-474) Remove arquillian-graphene depchain as no one uses it In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-474: ------------------------------ Status: Resolved (was: Pull Request Sent) Assignee: Matous Jobanek Resolution: Done > Remove arquillian-graphene depchain as no one uses it > ----------------------------------------------------- > > Key: ARQGRA-474 > URL: https://issues.jboss.org/browse/ARQGRA-474 > Project: Arquillian Graphene > Issue Type: Task > Reporter: Luk?? Fry? > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > > Docs and tutorials mention graphene-webdriver depchain: > https://docs.jboss.org/author/display/ARQGRA2/Framework+Integration+Options > http://arquillian.org/guides/functional_testing_using_graphene/ > The depchains are not used by EAP BOMs too: > https://issues.jboss.org/browse/JDF-840 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:08:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:08:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-471) GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-471: --------------------------------- Assignee: Matous Jobanek > GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException > ------------------------------------------------------------------------------- > > Key: ARQGRA-471 > URL: https://issues.jboss.org/browse/ARQGRA-471 > Project: Arquillian Graphene > Issue Type: Enhancement > Affects Versions: 2.1.0.Alpha2 > Reporter: Ji?? ?tefek > Assignee: Matous Jobanek > Priority: Trivial > Fix For: 2.1.0.Beta1 > > > When you perform an assertion in e.g. a page fragment, which leads to throwing an AssertionError, the error is wrapped in IllegalStateException. This is imho an unwanted behaviour and these errors should be forwarded. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:08:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:08:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-471) GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-471: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 2.1.0.Beta1 (was: 2.1-Tracking) Resolution: Done > GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException > ------------------------------------------------------------------------------- > > Key: ARQGRA-471 > URL: https://issues.jboss.org/browse/ARQGRA-471 > Project: Arquillian Graphene > Issue Type: Enhancement > Affects Versions: 2.1.0.Alpha2 > Reporter: Ji?? ?tefek > Assignee: Matous Jobanek > Priority: Trivial > Fix For: 2.1.0.Beta1 > > > When you perform an assertion in e.g. a page fragment, which leads to throwing an AssertionError, the error is wrapped in IllegalStateException. This is imho an unwanted behaviour and these errors should be forwarded. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:08:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:08:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-477) Upgrade to Core 1.1.8, Drone 2.0.0.Alpha5, Selenium 2.47.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-477: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade to Core 1.1.8, Drone 2.0.0.Alpha5, Selenium 2.47.1 > ----------------------------------------------------------- > > Key: ARQGRA-477 > URL: https://issues.jboss.org/browse/ARQGRA-477 > Project: Arquillian Graphene > Issue Type: Component Upgrade > Reporter: Luk?? Fry? > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:08:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:08:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-477) Upgrade to Core 1.1.8, Drone 2.0.0.Beta1, Selenium 2.47.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-477: ------------------------------ Summary: Upgrade to Core 1.1.8, Drone 2.0.0.Beta1, Selenium 2.47.1 (was: Upgrade to Core 1.1.8, Drone 2.0.0.Alpha5, Selenium 2.47.1) > Upgrade to Core 1.1.8, Drone 2.0.0.Beta1, Selenium 2.47.1 > ---------------------------------------------------------- > > Key: ARQGRA-477 > URL: https://issues.jboss.org/browse/ARQGRA-477 > Project: Arquillian Graphene > Issue Type: Component Upgrade > Reporter: Luk?? Fry? > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:09:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:09:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-477) Upgrade to Arquillian Core 1.1.11, Drone 2.0.0.Beta1, Selenium 2.47.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-477: ------------------------------ Summary: Upgrade to Arquillian Core 1.1.11, Drone 2.0.0.Beta1, Selenium 2.47.1 (was: Upgrade to Core 1.1.8, Drone 2.0.0.Beta1, Selenium 2.47.1) > Upgrade to Arquillian Core 1.1.11, Drone 2.0.0.Beta1, Selenium 2.47.1 > ---------------------------------------------------------------------- > > Key: ARQGRA-477 > URL: https://issues.jboss.org/browse/ARQGRA-477 > Project: Arquillian Graphene > Issue Type: Component Upgrade > Reporter: Luk?? Fry? > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:15:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:15:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-484) Enriched element is not equal to the same element In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-484: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/154, https://github.com/arquillian/arquillian-graphene/pull/155 > Enriched element is not equal to the same element > ------------------------------------------------- > > Key: ARQGRA-484 > URL: https://issues.jboss.org/browse/ARQGRA-484 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha3 > Reporter: Ji?? ?tefek > > After upgrading to 2.1.0.Alpha3 from Alpha2, the following (simplified) test won't pass: > {code} > @FindBy(id="id") > private WebElement e; > @Test > private void test(){ > e.equals(e) > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:26:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:26:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-431) Case insensitive matcher In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-431: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/149 > Case insensitive matcher > ------------------------ > > Key: ARQGRA-431 > URL: https://issues.jboss.org/browse/ARQGRA-431 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Karel Piwko > Fix For: 2.0-Tracking > > > It is not possible to match text/attribute in case insensitive way. > {code} > Graphene.waitModel().until().element(notify).text(). > {code} > * .contains(String) > * .equals(String) > it should have equalsIgnoreCase as well. A regex matcher would be handy here as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:30:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:30:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-431) Case insensitive matcher In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-431: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 2.1.0.Beta1 (was: 2.0-Tracking) Assignee: Ji?? ?tefek Resolution: Done > Case insensitive matcher > ------------------------ > > Key: ARQGRA-431 > URL: https://issues.jboss.org/browse/ARQGRA-431 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Karel Piwko > Assignee: Ji?? ?tefek > Fix For: 2.1.0.Beta1 > > > It is not possible to match text/attribute in case insensitive way. > {code} > Graphene.waitModel().until().element(notify).text(). > {code} > * .contains(String) > * .equals(String) > it should have equalsIgnoreCase as well. A regex matcher would be handy here as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:31:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:31:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-454: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/148 > NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final > -------------------------------------------------------------- > > Key: ARQGRA-454 > URL: https://issues.jboss.org/browse/ARQGRA-454 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Juergen Zimmermann > Assignee: Luk?? Fry? > Fix For: 2.0.4.Final, 2.1-Tracking > > > I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final. > The stacktrace: > {code} > org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException: > Error while initializing: class de.shop.util.IndexPage > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120) > at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291) > at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.lang.NullPointerException > at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73) > at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97) > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76) > ... 34 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:35:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:35:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-454: ------------------------------ Status: Resolved (was: Pull Request Sent) Release Notes Text: Agreem, as this is fixed with the newer Arquillian Core, we will go with a test case. Fix Version/s: 2.1.0.Beta1 (was: 2.1-Tracking) (was: 2.0.4.Final) Assignee: Matous Jobanek (was: Luk?? Fry?) Resolution: Won't Fix > NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final > -------------------------------------------------------------- > > Key: ARQGRA-454 > URL: https://issues.jboss.org/browse/ARQGRA-454 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Juergen Zimmermann > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > > I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final. > The stacktrace: > {code} > org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException: > Error while initializing: class de.shop.util.IndexPage > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120) > at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291) > at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.lang.NullPointerException > at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73) > at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97) > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76) > ... 34 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:35:01 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:35:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175871#comment-13175871 ] Luk?? Fry? commented on ARQGRA-454: ----------------------------------- Thanks [~mjobanek] > NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final > -------------------------------------------------------------- > > Key: ARQGRA-454 > URL: https://issues.jboss.org/browse/ARQGRA-454 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Juergen Zimmermann > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > > I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final. > The stacktrace: > {code} > org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException: > Error while initializing: class de.shop.util.IndexPage > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120) > at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291) > at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.lang.NullPointerException > at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73) > at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97) > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76) > ... 34 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:35:01 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:35:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-454: ------------------------------ Release Notes Text: (was: Agreem, as this is fixed with the newer Arquillian Core, we will go with a test case.) > NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final > -------------------------------------------------------------- > > Key: ARQGRA-454 > URL: https://issues.jboss.org/browse/ARQGRA-454 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Juergen Zimmermann > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > > I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final. > The stacktrace: > {code} > org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException: > Error while initializing: class de.shop.util.IndexPage > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120) > at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291) > at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.lang.NullPointerException > at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73) > at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97) > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76) > ... 34 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:35:01 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:35:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175871#comment-13175871 ] Luk?? Fry? edited comment on ARQGRA-454 at 3/14/16 3:34 AM: ------------------------------------------------------------ Agree, as this is fixed with the newer Arquillian Core, we will go with a test case. Thanks [~mjobanek] was (Author: lfryc): Thanks [~mjobanek] > NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final > -------------------------------------------------------------- > > Key: ARQGRA-454 > URL: https://issues.jboss.org/browse/ARQGRA-454 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Juergen Zimmermann > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > > I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final. > The stacktrace: > {code} > org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException: > Error while initializing: class de.shop.util.IndexPage > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120) > at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291) > at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.lang.NullPointerException > at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73) > at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97) > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76) > ... 34 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:44:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:44:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-473) ClassNotFoundException: org.openqa.selenium.html5.DatabaseStorage with Selenium 2.46.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-473. ------------------------------- Fix Version/s: 2.1.0.Beta1 (was: 2.1-Tracking) Assignee: Matous Jobanek Resolution: Cannot Reproduce Bug > ClassNotFoundException: org.openqa.selenium.html5.DatabaseStorage with Selenium 2.46.0 > -------------------------------------------------------------------------------------- > > Key: ARQGRA-473 > URL: https://issues.jboss.org/browse/ARQGRA-473 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 2.1.0.Beta1 > > > Graphene is not compatible with the latest Selenium 2.46.0. It throws {{ClassNotFoundException: org.openqa.selenium.html5.DatabaseStorage}} > DatabaseStorage is deprecated class, that is not included it the latest Selenium. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:45:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:45:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-458) Graphene can't be compiled in Maven 3.1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-458. ------------------------------- Fix Version/s: (was: 2.1-Tracking) Assignee: Matous Jobanek Resolution: Cannot Reproduce Bug I can't reproduce it either. > Graphene can't be compiled in Maven 3.1.1 > ----------------------------------------- > > Key: ARQGRA-458 > URL: https://issues.jboss.org/browse/ARQGRA-458 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Luk?? Fry? > Assignee: Matous Jobanek > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:46:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:46:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-380) Debugging in Eclipse throw InvocationException when inspecting fields enriched by Graphene In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-380. ------------------------------- Fix Version/s: (was: 2.1-Tracking) Assignee: Luk?? Fry? Resolution: Incomplete Description > Debugging in Eclipse throw InvocationException when inspecting fields enriched by Graphene > ------------------------------------------------------------------------------------------ > > Key: ARQGRA-380 > URL: https://issues.jboss.org/browse/ARQGRA-380 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.0.Beta2 > Reporter: Juraj H?ska > Assignee: Luk?? Fry? > > During debugging in Eclipse, when inspecting the values of the fields which are enriched by Graphene, an {{InvocationException}} is thrown. > We should investigate why it is so, and improve it if it is feasible. It can enhance the usability. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:46:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:46:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-380) Debugging in Eclipse throw InvocationException when inspecting fields enriched by Graphene In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175879#comment-13175879 ] Luk?? Fry? commented on ARQGRA-380: ----------------------------------- Closing as incomplete description for now. Please comment with more details. > Debugging in Eclipse throw InvocationException when inspecting fields enriched by Graphene > ------------------------------------------------------------------------------------------ > > Key: ARQGRA-380 > URL: https://issues.jboss.org/browse/ARQGRA-380 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.0.Beta2 > Reporter: Juraj H?ska > Assignee: Luk?? Fry? > > During debugging in Eclipse, when inspecting the values of the fields which are enriched by Graphene, an {{InvocationException}} is thrown. > We should investigate why it is so, and improve it if it is feasible. It can enhance the usability. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 03:48:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 03:48:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-462) Polish AjaxHalter API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-462: ------------------------------ Fix Version/s: 2.2-Tracking (was: 2.1-Tracking) > Polish AjaxHalter API > --------------------- > > Key: ARQGRA-462 > URL: https://issues.jboss.org/browse/ARQGRA-462 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: api, core > Affects Versions: 2.1.0.Alpha2 > Reporter: Juraj H?ska > Assignee: Luk?? Fry? > Fix For: 2.2-Tracking > > > The API for {{AjaxHalter}} was ported from {{XHRHalter}} in _Graphene1_. > We talked about polishing it based on the community feedback after releasing {{2.1.0.Alpha2}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 05:06:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 05:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-417) Support for automatic scrolling to element before its usage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175913#comment-13175913 ] Luk?? Fry? commented on ARQGRA-417: ----------------------------------- [~jstefek] this seems like a nice addition - with use of interceptors, we could add this as a cross-cutting concern. Lemme know if I could be of any help - e.g. pinging me on IRC. > Support for automatic scrolling to element before its usage > ----------------------------------------------------------- > > Key: ARQGRA-417 > URL: https://issues.jboss.org/browse/ARQGRA-417 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Priority: Minor > Fix For: 2.2-Tracking > > > It would be nice if Graphene supports automatic scrolling of browser window to {{WebElement}} / Page Fragment before its is used. > It can be useful for interactions with various popups web components: contextMenu, tooltip, ... > Those components can not be interacted correctly when they are not in the viewport, and thus one needs to scroll to them manually in his test. > It is often problem in CI environment, where tests run on screens with lower resolution (smaller part of the page fit the browser window, and lot of elements are not in the viewport). > My naive implementation of this would look like: > * intercept all calls to {{WebElements}} and PageFragments root elements > * in the interceptor method get the location of the element by: {{Point location = element.getLocation();}} > * a then scroll to it: {{jsExecutor.executeScript("window.scrollTo("" + location.getX() +", " + location.getY() + ")");}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 05:17:01 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 05:17:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2014) When warp is on classpath then almost every non-warp arquillian test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-2014: ---------------------------- Status: Pull Request Sent (was: Open) > When warp is on classpath then almost every non-warp arquillian test fails > -------------------------------------------------------------------------- > > Key: ARQ-2014 > URL: https://issues.jboss.org/browse/ARQ-2014 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > Consider a test suite that contains a warp test (so you need to have the warp dependency on your classpath) and some other non-warp arquillian test. Then the non-warp tests fails with various exceptions depending on the type of the test. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 05:18:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 05:18:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2014) When warp is on classpath then almost every non-warp arquillian test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-2014: ---------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: warp_1.0.0.Beta1 Resolution: Done > When warp is on classpath then almost every non-warp arquillian test fails > -------------------------------------------------------------------------- > > Key: ARQ-2014 > URL: https://issues.jboss.org/browse/ARQ-2014 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: warp_1.0.0.Beta1 > > > Consider a test suite that contains a warp test (so you need to have the warp dependency on your classpath) and some other non-warp arquillian test. Then the non-warp tests fails with various exceptions depending on the type of the test. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 05:18:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 05:18:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2013) Update Arquillian, Drone, Resolver, JaCoCo and JUnit to newer version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-2013: ---------------------------- Status: Pull Request Sent (was: Open) > Update Arquillian, Drone, Resolver, JaCoCo and JUnit to newer version > --------------------------------------------------------------------- > > Key: ARQ-2013 > URL: https://issues.jboss.org/browse/ARQ-2013 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: warp_1.0.0.Beta1 > > > Please update to newer versions to use the latest and greatest implementations. > In case of JaCoCo - the current version {{0.6.0.201210061924}} is not compatible with JDK8 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 05:18:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 05:18:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2013) Update Arquillian, Drone, Resolver, JaCoCo and JUnit to newer version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-2013: ---------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: warp_1.0.0.Beta1 Resolution: Done > Update Arquillian, Drone, Resolver, JaCoCo and JUnit to newer version > --------------------------------------------------------------------- > > Key: ARQ-2013 > URL: https://issues.jboss.org/browse/ARQ-2013 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: warp_1.0.0.Beta1 > > > Please update to newer versions to use the latest and greatest implementations. > In case of JaCoCo - the current version {{0.6.0.201210061924}} is not compatible with JDK8 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 05:18:01 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 05:18:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1923) Cannot build Warp 1.0.0.Alpha7 with OpenJDK 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1923: ---------------------------- Status: Pull Request Sent (was: Open) > Cannot build Warp 1.0.0.Alpha7 with OpenJDK 8 > --------------------------------------------- > > Key: ARQ-1923 > URL: https://issues.jboss.org/browse/ARQ-1923 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Pavol Pitonak > Fix For: warp_1.0.0.Beta1 > > > # git clone https://github.com/arquillian/arquillian-extension-warp.git > # mvn clean install > result: > * when launched with OpenJDK 8, one test fails TestExecutedMethod.testSerializedAnnotation > {code} > java.lang.IllegalStateException: java.lang.IllegalStateException: Error instantiating proxy for annotation. Annotation type: interface org.jboss.arquillian.warp.impl.shared.TestingAnnotation > at org.jboss.arquillian.warp.impl.shared.SerializedAnnotation.getAnnotation(SerializedAnnotation.java:61) > at org.jboss.arquillian.warp.impl.shared.TestExecutedMethod.testSerializedAnnotation(TestExecutedMethod.java:49) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: java.lang.IllegalStateException: Error instantiating proxy for annotation. Annotation type: interface org.jboss.arquillian.warp.impl.shared.TestingAnnotation > at org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider.get(AnnotationInstanceProvider.java:83) > at org.jboss.arquillian.warp.impl.shared.SerializedAnnotation.getAnnotation(SerializedAnnotation.java:59) > ... 24 more > Caused by: java.lang.IllegalAccessException: Class org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider can not access a member of class org.jboss.arquillian.warp.impl.shared.$Proxy5 with modifiers "public" > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101) > at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:295) > at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:287) > at java.lang.reflect.Constructor.newInstance(Constructor.java:398) > at org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider.get(AnnotationInstanceProvider.java:76) > ... 25 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 05:18:01 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 05:18:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1923) Cannot build Warp 1.0.0.Alpha7 with OpenJDK 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1923: ---------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Matous Jobanek Resolution: Done > Cannot build Warp 1.0.0.Alpha7 with OpenJDK 8 > --------------------------------------------- > > Key: ARQ-1923 > URL: https://issues.jboss.org/browse/ARQ-1923 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Pavol Pitonak > Assignee: Matous Jobanek > Fix For: warp_1.0.0.Beta1 > > > # git clone https://github.com/arquillian/arquillian-extension-warp.git > # mvn clean install > result: > * when launched with OpenJDK 8, one test fails TestExecutedMethod.testSerializedAnnotation > {code} > java.lang.IllegalStateException: java.lang.IllegalStateException: Error instantiating proxy for annotation. Annotation type: interface org.jboss.arquillian.warp.impl.shared.TestingAnnotation > at org.jboss.arquillian.warp.impl.shared.SerializedAnnotation.getAnnotation(SerializedAnnotation.java:61) > at org.jboss.arquillian.warp.impl.shared.TestExecutedMethod.testSerializedAnnotation(TestExecutedMethod.java:49) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: java.lang.IllegalStateException: Error instantiating proxy for annotation. Annotation type: interface org.jboss.arquillian.warp.impl.shared.TestingAnnotation > at org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider.get(AnnotationInstanceProvider.java:83) > at org.jboss.arquillian.warp.impl.shared.SerializedAnnotation.getAnnotation(SerializedAnnotation.java:59) > ... 24 more > Caused by: java.lang.IllegalAccessException: Class org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider can not access a member of class org.jboss.arquillian.warp.impl.shared.$Proxy5 with modifiers "public" > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101) > at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:295) > at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:287) > at java.lang.reflect.Constructor.newInstance(Constructor.java:398) > at org.jboss.arquillian.warp.impl.utils.AnnotationInstanceProvider.get(AnnotationInstanceProvider.java:76) > ... 25 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 09:34:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 09:34:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQRUSH-43) Configure jenkins job running RushEye Core on current samples producing result.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQRUSH-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQRUSH-43: --------------------------------- Assignee: (was: Luk?? Fry?) > Configure jenkins job running RushEye Core on current samples producing result.xml > ---------------------------------------------------------------------------------- > > Key: ARQRUSH-43 > URL: https://issues.jboss.org/browse/ARQRUSH-43 > Project: Arquillian RushEye > Issue Type: Sub-task > Components: Tests > Reporter: Luk?? Fry? > Fix For: 1.0.0.Alpha1 > > > The task is take the output of job ARQRUSH-42 and run the RushEye Core on it, so producing result.xml. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 09:34:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 09:34:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQRUSH-39) Enhance Positive/Negative buttons In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQRUSH-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQRUSH-39: --------------------------------- Assignee: (was: Luk?? Fry?) > Enhance Positive/Negative buttons > --------------------------------- > > Key: ARQRUSH-39 > URL: https://issues.jboss.org/browse/ARQRUSH-39 > Project: Arquillian RushEye > Issue Type: Enhancement > Components: Manager > Reporter: Luk?? Fry? > Fix For: 1.0.0.Alpha1 > > > The possitive button should be called "Accept changes". > Negative button can be removed, since its functionality would be duplicated with Next Case / Next Test. > ---- > "Accept changes" will actually act on what is selected: > 1. if Test is selected > * one particular test's pattern is accepted as new pattern, replacing the old one > 2. if Case is selected > * all the changes in underlying Case are accepted (adopted to current suite) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 11:45:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 11:45:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQRUSH-26) Support detection of changes in cases and tests (removals, additions, modifications) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQRUSH-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQRUSH-26: --------------------------------- Assignee: (was: Luk?? Fry?) > Support detection of changes in cases and tests (removals, additions, modifications) > ------------------------------------------------------------------------------------ > > Key: ARQRUSH-26 > URL: https://issues.jboss.org/browse/ARQRUSH-26 > Project: Arquillian RushEye > Issue Type: Feature Request > Components: Core, Manager > Reporter: Luk?? Fry? > Fix For: 1.0.0.Alpha1 > > > {quote} > T 1341996997 3130 (5) problem of changes in test suite > T 1341997028 3130 basically what to do when "screenshots1" and "screenshots2" differs > T 1341997042 3130 in case of: > T 1341997047 3130 a) test additions > T 1341997050 3130 b) test removals > T 1341997055 3130 c) test modifications > T 1341997087 3130 the Manager should inteligently show the test case with matching images > T 1341997100 3130 and even allow context-menu resolution > T 1341997163 3130 we are currently investigating what's the stability of test suite (if the list of images doesn't differ between runs) > T 1341997163 18 if there is no corresponding image for test, this big image warning will be shown > T 1341997204 3130 yeah, this would need to be more smart.. > T 1341997220 3130 let's see this case, you get those tests (images): > T 1341997248 3130 00-open > T 1341997248 3130 01-click > T 1341997248 3130 02-click > T 1341997248 3130 03-type > T 1341997248 3130 04-click > T 1341997248 3130 05-click > T 1341997274 3130 but then you get other just those: > T 1341997279 3130 00-open > T 1341997283 3130 01-click > T 1341997285 3130 03-type > T 1341997304 3130 those images identifies all changes during the automated browser test > T 1341997316 3130 then you have problem > T 1341997321 3130 (sorry 02-type) > T 1341997337 3130 the Manager could fallback to heuristics > T 1341997359 3130 and in case of the images does not match in suite and samples.. > T 1341997378 18 so, you want to have a test pruning for missing cases? > T 1341997380 3130 it can offer alternative mode, when it could try determine what happened > T 1341997390 18 *test tree > T 1341997394 3130 yep > T 1341997402 3130 it should show something like: > T 1341997407 3130 OK 00-open > T 1341997412 3130 OK 01-click > T 1341997434 3130 02-click (missing sample) > T 1341997445 3130 02-type (missing pattern) > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 12:13:00 2016 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 14 Mar 2016 12:13:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2018) Upgrade Karaf to latest release for arquillian-container-karaf-managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler closed ARQ-2018. ------------------------------- Resolution: Duplicate Issue Duplicates ARQ-2019 > Upgrade Karaf to latest release for arquillian-container-karaf-managed > ---------------------------------------------------------------------- > > Key: ARQ-2018 > URL: https://issues.jboss.org/browse/ARQ-2018 > Project: Arquillian > Issue Type: Enhancement > Components: OSGi Containers > Affects Versions: osgi_2.1.0.Final > Reporter: Steve Storck > > The current version of the managed Karaf container is 2.3.3. This was released in 2013, so it is quite outdated. The latest release is 4.0.4, which was released in early 2016. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 14:47:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 14:47:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1328) Warp: guide outline In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQ-1328: ------------------------------- Assignee: (was: Luk?? Fry?) > Warp: guide outline > ------------------- > > Key: ARQ-1328 > URL: https://issues.jboss.org/browse/ARQ-1328 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Warp > Reporter: Luk?? Fry? > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 14:47:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 14:47:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1489) Warp Filter: prepend to all other filters in a chain & do not participate in forwarding In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQ-1489: ------------------------------- Assignee: (was: Luk?? Fry?) > Warp Filter: prepend to all other filters in a chain & do not participate in forwarding > --------------------------------------------------------------------------------------- > > Key: ARQ-1489 > URL: https://issues.jboss.org/browse/ARQ-1489 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Affects Versions: 1.0.0.Alpha4 > Environment: Arquillian Warp 1.0.0.Alpha4 with Rewrite 2.0.7.Final in a JBoss AS 7.1.1.Final > Reporter: Harald Albers > Fix For: warp_1.0.0.Beta1 > > > *Original title*: Warp: response payload was never registered when used with OCPsoft Rewrite > I use OCPsoft Rewrite (http://ocpsoft.org/rewrite/) to add fancy URL aliases to my JSF webapp. > Warp tests work as long as I use the original unaliased URLs. > Warp tests using the aliased URLs fail with > {quote} > ClientWarpExecutionException: deenriching response failed: The response payload with serialId [...] was never registered > {quote} > I created a demonstration project, see README.md for details: > https://github.com/albers/arquillian-showcase/tree/rewrite -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 14:47:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 14:47:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQ-1952: ------------------------------- Assignee: (was: Luk?? Fry?) > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: P?tr Andreev > Fix For: warp_1.0.0.Beta1 > > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 14:48:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 14:48:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQRUSH-46) Add test cases for Case In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQRUSH-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQRUSH-46: --------------------------------- Assignee: (was: Luk?? Fry?) > Add test cases for Case > ----------------------- > > Key: ARQRUSH-46 > URL: https://issues.jboss.org/browse/ARQRUSH-46 > Project: Arquillian RushEye > Issue Type: Task > Components: Core > Reporter: Luk?? Fry? > > {{Case}} has been introduced without proper coverage with tests ARQRUSH-27 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 14:48:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 14:48:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQRUSH-42) Configure jenkins job screen-shoting RichFaces snapshots In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQRUSH-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQRUSH-42: --------------------------------- Assignee: (was: Luk?? Fry?) > Configure jenkins job screen-shoting RichFaces snapshots > -------------------------------------------------------- > > Key: ARQRUSH-42 > URL: https://issues.jboss.org/browse/ARQRUSH-42 > Project: Arquillian RushEye > Issue Type: Sub-task > Components: Tests > Reporter: Luk?? Fry? > Fix For: 1.0.0.Alpha1 > > > This job will purely show the samples for current state of tests from ARQRUSH-41 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 14:48:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 14:48:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-331) Graphene guards fails when page stores reference to XMLHttpRequest before Graphene rewrites them In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-331: --------------------------------- Assignee: (was: Luk?? Fry?) > Graphene guards fails when page stores reference to XMLHttpRequest before Graphene rewrites them > ------------------------------------------------------------------------------------------------ > > Key: ARQGRA-331 > URL: https://issues.jboss.org/browse/ARQGRA-331 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.0.Alpha4 > Reporter: Oliver Ki?? > Fix For: 2.2-Tracking > > > Graphene guards do not work correctly in the [AngularJS Kitchensink quickstart|https://github.com/jboss-jdf/jboss-as-quickstart/tree/master/kitchensink-angularjs]. > The registration form sends a XHR POST request on submit, but this is not recognized and clicking on the submit button with {{guardAjax(registerButton).click()}} throws an exception: "{{RequestGuardException: Request type 'XHR' was expected, but type 'NONE' was done instead}}". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 14:48:00 2016 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 14 Mar 2016 14:48:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-462) Polish AjaxHalter API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-462: --------------------------------- Assignee: (was: Luk?? Fry?) > Polish AjaxHalter API > --------------------- > > Key: ARQGRA-462 > URL: https://issues.jboss.org/browse/ARQGRA-462 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: api, core > Affects Versions: 2.1.0.Alpha2 > Reporter: Juraj H?ska > Fix For: 2.2-Tracking > > > The API for {{AjaxHalter}} was ported from {{XHRHalter}} in _Graphene1_. > We talked about polishing it based on the community feedback after releasing {{2.1.0.Alpha2}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 17 08:39:00 2016 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 17 Mar 2016 08:39:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2022) Support starting Browser window in Fullscreen In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-2022: ---------------------------------- Summary: Support starting Browser window in Fullscreen Key: ARQ-2022 URL: https://issues.jboss.org/browse/ARQ-2022 Project: Arquillian Issue Type: Feature Request Components: Extension - Drone Reporter: Aslak Knutsen Ref https://github.com/richfaces/richfaces/blob/master/build/build-resources/src/main/java/org/richfaces/arquillian/browser/WindowResizer.java -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 18 05:51:00 2016 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Fri, 18 Mar 2016 05:51:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2023) Use Weld relaxed default constructor configuration in Arquillian Weld SE embedded 1.1 adapter In-Reply-To: References: Message-ID: Antonin Stefanutti created ARQ-2023: --------------------------------------- Summary: Use Weld relaxed default constructor configuration in Arquillian Weld SE embedded 1.1 adapter Key: ARQ-2023 URL: https://issues.jboss.org/browse/ARQ-2023 Project: Arquillian Issue Type: Enhancement Components: Weld Containers Reporter: Antonin Stefanutti Priority: Minor Weld exposes a relaxed default constructor configuration that enables to relax the constraint of having to declare a default constructor for proxied bean types. This configuration is very useful in a number of use cases, notably when integrating with third-parties libraries that do some _heavy_ initialisation in their default constructors, like Apache Camel. This is enabled by default in Weld SE so it would be consistent to enable that mode as well when using the corresponding Arquillian adapter. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 18 12:43:00 2016 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Fri, 18 Mar 2016 12:43:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2023) Use Weld relaxed default constructor configuration in Arquillian Weld SE embedded 1.1 adapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated ARQ-2023: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-weld/pull/23 > Use Weld relaxed default constructor configuration in Arquillian Weld SE embedded 1.1 adapter > --------------------------------------------------------------------------------------------- > > Key: ARQ-2023 > URL: https://issues.jboss.org/browse/ARQ-2023 > Project: Arquillian > Issue Type: Enhancement > Components: Weld Containers > Reporter: Antonin Stefanutti > Priority: Minor > > Weld exposes a relaxed default constructor configuration that enables to relax the constraint of having to declare a default constructor for proxied bean types. > This configuration is very useful in a number of use cases, notably when integrating with third-parties libraries that do some _heavy_ initialisation in their default constructors, like Apache Camel. > This is enabled by default in Weld SE so it would be consistent to enable that mode as well when using the corresponding Arquillian adapter. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:27:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:27:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2024) Update Selenium & Arquillian core to the latest versions In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-2024: ----------------------------------- Summary: Update Selenium & Arquillian core to the latest versions Key: ARQ-2024 URL: https://issues.jboss.org/browse/ARQ-2024 Project: Arquillian Issue Type: Component Upgrade Components: Extension - Drone Affects Versions: drone_2.0.0.CR1 Reporter: Matous Jobanek -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:28:01 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:28:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2024) Update Selenium & phantom-driver & Arquillian core to the latest versions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2024: -------------------------------- Summary: Update Selenium & phantom-driver & Arquillian core to the latest versions (was: Update Selenium & Arquillian core to the latest versions) > Update Selenium & phantom-driver & Arquillian core to the latest versions > ------------------------------------------------------------------------- > > Key: ARQ-2024 > URL: https://issues.jboss.org/browse/ARQ-2024 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Affects Versions: drone_2.0.0.CR1 > Reporter: Matous Jobanek > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:29:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:29:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2024) Update Selenium & phantom-driver & additional components to the latest versions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2024: -------------------------------- Summary: Update Selenium & phantom-driver & additional components to the latest versions (was: Update Selenium & phantom-driver & Arquillian core to the latest versions) > Update Selenium & phantom-driver & additional components to the latest versions > ------------------------------------------------------------------------------- > > Key: ARQ-2024 > URL: https://issues.jboss.org/browse/ARQ-2024 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Affects Versions: drone_2.0.0.CR1 > Reporter: Matous Jobanek > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:32:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:32:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1694) Update Saucelabs extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-1694: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/61 > Update Saucelabs extension > -------------------------- > > Key: ARQ-1694 > URL: https://issues.jboss.org/browse/ARQ-1694 > Project: Arquillian > Issue Type: Task > Components: Extension - Drone > Reporter: Karel Piwko > Fix For: drone_2.0.0.CR1 > > > Provide working SauceLabs extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:32:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:32:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1694) Update Saucelabs extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-1694: ----------------------------------- Assignee: Matous Jobanek > Update Saucelabs extension > -------------------------- > > Key: ARQ-1694 > URL: https://issues.jboss.org/browse/ARQ-1694 > Project: Arquillian > Issue Type: Task > Components: Extension - Drone > Reporter: Karel Piwko > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > > Provide working SauceLabs extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:34:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:34:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2025) Create BrowserStack extension In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-2025: ----------------------------------- Summary: Create BrowserStack extension Key: ARQ-2025 URL: https://issues.jboss.org/browse/ARQ-2025 Project: Arquillian Issue Type: Feature Request Components: Extension - Drone Affects Versions: drone_2.0.0.CR1 Reporter: Matous Jobanek Provide working BrowserStack extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:35:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:35:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2024) Update Selenium & phantom-driver & additional components to the latest versions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2024: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/60 > Update Selenium & phantom-driver & additional components to the latest versions > ------------------------------------------------------------------------------- > > Key: ARQ-2024 > URL: https://issues.jboss.org/browse/ARQ-2024 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Affects Versions: drone_2.0.0.CR1 > Reporter: Matous Jobanek > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:35:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:35:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2025) Create BrowserStack extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2025: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/62 > Create BrowserStack extension > ----------------------------- > > Key: ARQ-2025 > URL: https://issues.jboss.org/browse/ARQ-2025 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Affects Versions: drone_2.0.0.CR1 > Reporter: Matous Jobanek > > Provide working BrowserStack extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:36:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:36:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2025) Create BrowserStack extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-2025: ----------------------------------- Assignee: Matous Jobanek > Create BrowserStack extension > ----------------------------- > > Key: ARQ-2025 > URL: https://issues.jboss.org/browse/ARQ-2025 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Affects Versions: drone_2.0.0.CR1 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > Provide working BrowserStack extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:36:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:36:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2024) Update Selenium & phantom-driver & additional components to the latest versions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-2024: ----------------------------------- Assignee: Matous Jobanek > Update Selenium & phantom-driver & additional components to the latest versions > ------------------------------------------------------------------------------- > > Key: ARQ-2024 > URL: https://issues.jboss.org/browse/ARQ-2024 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Affects Versions: drone_2.0.0.CR1 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:37:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:37:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2025) Create BrowserStack extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2025: -------------------------------- Affects Version/s: (was: drone_2.0.0.CR1) > Create BrowserStack extension > ----------------------------- > > Key: ARQ-2025 > URL: https://issues.jboss.org/browse/ARQ-2025 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > > Provide working BrowserStack extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:37:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:37:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2025) Create BrowserStack extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2025: -------------------------------- Fix Version/s: drone_2.0.0.CR1 > Create BrowserStack extension > ----------------------------- > > Key: ARQ-2025 > URL: https://issues.jboss.org/browse/ARQ-2025 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > > Provide working BrowserStack extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 04:38:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 23 Mar 2016 04:38:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2024) Update Selenium & phantom-driver & additional components to the latest versions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2024: -------------------------------- Fix Version/s: drone_2.0.0.CR1 Affects Version/s: (was: drone_2.0.0.CR1) > Update Selenium & phantom-driver & additional components to the latest versions > ------------------------------------------------------------------------------- > > Key: ARQ-2024 > URL: https://issues.jboss.org/browse/ARQ-2024 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 07:08:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 24 Mar 2016 07:08:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2024) Update Selenium & phantom-driver & additional components to the latest versions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek resolved ARQ-2024. --------------------------------- Resolution: Done > Update Selenium & phantom-driver & additional components to the latest versions > ------------------------------------------------------------------------------- > > Key: ARQ-2024 > URL: https://issues.jboss.org/browse/ARQ-2024 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 07:08:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 24 Mar 2016 07:08:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2025) Create BrowserStack extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek resolved ARQ-2025. --------------------------------- Resolution: Done > Create BrowserStack extension > ----------------------------- > > Key: ARQ-2025 > URL: https://issues.jboss.org/browse/ARQ-2025 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > > Provide working BrowserStack extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 07:08:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 24 Mar 2016 07:08:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1694) Update Saucelabs extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek resolved ARQ-1694. --------------------------------- Resolution: Done > Update Saucelabs extension > -------------------------- > > Key: ARQ-1694 > URL: https://issues.jboss.org/browse/ARQ-1694 > Project: Arquillian > Issue Type: Task > Components: Extension - Drone > Reporter: Karel Piwko > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > > Provide working SauceLabs extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 11:08:02 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 24 Mar 2016 11:08:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2024) Update Selenium & phantom-driver & additional components to the latest versions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-2024. ------------------------------- > Update Selenium & phantom-driver & additional components to the latest versions > ------------------------------------------------------------------------------- > > Key: ARQ-2024 > URL: https://issues.jboss.org/browse/ARQ-2024 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 11:10:02 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 24 Mar 2016 11:10:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2024) Update Selenium & phantom-driver & additional components to the latest versions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182060#comment-13182060 ] Matous Jobanek commented on ARQ-2024: ------------------------------------- Pushed upstream in: https://github.com/arquillian/arquillian-extension-drone/commit/ae4dabc658172d2ce76bbd396c96ca645f88a7bc https://github.com/arquillian/arquillian-extension-drone/commit/90571cc6c5363c816eba922f631db128568b0c1a https://github.com/arquillian/arquillian-extension-drone/commit/3b9bae2194e5bd85f1263492e892b9ccf3f58a32 https://github.com/arquillian/arquillian-extension-drone/commit/8f02218104129c5c200bcb4ef7b98891de25d3af > Update Selenium & phantom-driver & additional components to the latest versions > ------------------------------------------------------------------------------- > > Key: ARQ-2024 > URL: https://issues.jboss.org/browse/ARQ-2024 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 11:11:00 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 24 Mar 2016 11:11:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2025) Create BrowserStack extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-2025. ------------------------------- Pushed upstream in: https://github.com/arquillian/arquillian-extension-drone/commit/137342c8424ec07172e2decbd18e7a98a41c86bf > Create BrowserStack extension > ----------------------------- > > Key: ARQ-2025 > URL: https://issues.jboss.org/browse/ARQ-2025 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > > Provide working BrowserStack extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 11:11:01 2016 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 24 Mar 2016 11:11:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1694) Update Saucelabs extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-1694. ------------------------------- Pushed upstream in: https://github.com/arquillian/arquillian-extension-drone/commit/595ce3c10461a06fff63a29de68b66fa2e551e76 > Update Saucelabs extension > -------------------------- > > Key: ARQ-1694 > URL: https://issues.jboss.org/browse/ARQ-1694 > Project: Arquillian > Issue Type: Task > Components: Extension - Drone > Reporter: Karel Piwko > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > > Provide working SauceLabs extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 30 09:25:00 2016 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Wed, 30 Mar 2016 09:25:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1694) Update Saucelabs extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183900#comment-13183900 ] Karel Piwko commented on ARQ-1694: ---------------------------------- Awesome, thanks Matous! > Update Saucelabs extension > -------------------------- > > Key: ARQ-1694 > URL: https://issues.jboss.org/browse/ARQ-1694 > Project: Arquillian > Issue Type: Task > Components: Extension - Drone > Reporter: Karel Piwko > Assignee: Matous Jobanek > Fix For: drone_2.0.0.CR1 > > > Provide working SauceLabs extension fully compatible with Drone 2. -- This message was sent by Atlassian JIRA (v6.4.11#64026)