From issues at jboss.org Tue Sep 1 11:34:05 2015 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Tue, 1 Sep 2015 11:34:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1976) All ResourceProvider#canProvide implementations could try to inject subtypes In-Reply-To: References: Message-ID: Radoslav Husar created ARQ-1976: ----------------------------------- Summary: All ResourceProvider#canProvide implementations could try to inject subtypes Key: ARQ-1976 URL: https://issues.jboss.org/browse/ARQ-1976 Project: Arquillian Issue Type: Bug Reporter: Radoslav Husar Currently the conditions seem to be the other way round as they normally would: {noformat} @Override public boolean canProvide(Class type) { - return Deployer.class.isAssignableFrom(type); + return type.isAssignableFrom(Deployer.class); } {noformat} It does not seem to be intentional. This would not be usually spotted because usually the same class is injected and requested and no provider provides a subtype of other ResourceProvider, so the problem would never occur. The resulting exception would look like: {noformat} java.lang.RuntimeException: Could not set value on field protected ClassA TestClass.field using ClassB at 19b89d4, {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 11:37:05 2015 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Tue, 1 Sep 2015 11:37:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1976) All ResourceProvider#canProvide implementations could try to inject subtypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104165#comment-13104165 ] Radoslav Husar commented on ARQ-1976: ------------------------------------- PR: https://github.com/arquillian/arquillian-core/pull/93 > All ResourceProvider#canProvide implementations could try to inject subtypes > ---------------------------------------------------------------------------- > > Key: ARQ-1976 > URL: https://issues.jboss.org/browse/ARQ-1976 > Project: Arquillian > Issue Type: Bug > Reporter: Radoslav Husar > > Currently the conditions seem to be the other way round as they normally would: > {noformat} > @Override > public boolean canProvide(Class type) > { > - return Deployer.class.isAssignableFrom(type); > + return type.isAssignableFrom(Deployer.class); > } > {noformat} > It does not seem to be intentional. This would not be usually spotted because usually the same class is injected and requested and no provider provides a subtype of other ResourceProvider, so the problem would never occur. > The resulting exception would look like: > {noformat} > java.lang.RuntimeException: Could not set value on field protected ClassA TestClass.field using ClassB at 19b89d4, > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 12:08:05 2015 From: issues at jboss.org (Richard Achmatowicz (JIRA)) Date: Tue, 1 Sep 2015 12:08:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1976) All ResourceProvider#canProvide implementations could try to inject subtypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104183#comment-13104183 ] Richard Achmatowicz commented on ARQ-1976: ------------------------------------------ This issue and its PR were observed when testing https://issues.jboss.org/browse/WFLY-4255. Certain test cases were not passing with the exception: {noformat} Running org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.043 sec <<< FAILURE! - in org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase testPutRelayedToBackups(org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase) Time elapsed: 0.033 sec <<< ERROR! java.lang.RuntimeException: Could not set value on field protected org.jboss.as.arquillian.api.WildFlyContainerController org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase.controller using org.jboss.arquillian.container.test.impl.client.container.ClientContainerController at 19b89d4, exception = Can not set org.jboss.as.arquillian.api.WildFlyContainerController field org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase.controller to org.jboss.arquillian.container.test.impl.client.container.ClientContainerController at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:103) at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52) at org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) {noformat} which in turn was caused by the wrong ResourceProvider being picked up and used to inject the resource. With the fix of this issue, that problem goes away. > All ResourceProvider#canProvide implementations could try to inject subtypes > ---------------------------------------------------------------------------- > > Key: ARQ-1976 > URL: https://issues.jboss.org/browse/ARQ-1976 > Project: Arquillian > Issue Type: Bug > Reporter: Radoslav Husar > > Currently the conditions seem to be the other way round as they normally would: > {noformat} > @Override > public boolean canProvide(Class type) > { > - return Deployer.class.isAssignableFrom(type); > + return type.isAssignableFrom(Deployer.class); > } > {noformat} > It does not seem to be intentional. This would not be usually spotted because usually the same class is injected and requested and no provider provides a subtype of other ResourceProvider, so the problem would never occur. > The resulting exception would look like: > {noformat} > java.lang.RuntimeException: Could not set value on field protected ClassA TestClass.field using ClassB at 19b89d4, > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 12:10:05 2015 From: issues at jboss.org (Richard Achmatowicz (JIRA)) Date: Tue, 1 Sep 2015 12:10:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1976) All ResourceProvider#canProvide implementations could try to inject subtypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104185#comment-13104185 ] Richard Achmatowicz commented on ARQ-1976: ------------------------------------------ The issue https://issues.jboss.org/browse/WFLY-4255 is holding up testing of clean shutdown, so any help in getting this issue resolved as quickly as possible would be greatly appreciated and received with heartfelt thanks. > All ResourceProvider#canProvide implementations could try to inject subtypes > ---------------------------------------------------------------------------- > > Key: ARQ-1976 > URL: https://issues.jboss.org/browse/ARQ-1976 > Project: Arquillian > Issue Type: Bug > Reporter: Radoslav Husar > > Currently the conditions seem to be the other way round as they normally would: > {noformat} > @Override > public boolean canProvide(Class type) > { > - return Deployer.class.isAssignableFrom(type); > + return type.isAssignableFrom(Deployer.class); > } > {noformat} > It does not seem to be intentional. This would not be usually spotted because usually the same class is injected and requested and no provider provides a subtype of other ResourceProvider, so the problem would never occur. > The resulting exception would look like: > {noformat} > java.lang.RuntimeException: Could not set value on field protected ClassA TestClass.field using ClassB at 19b89d4, > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 13:34:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 13:34:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1976) All ResourceProvider#canProvide implementations could try to inject subtypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1976: ------------------------------- Fix Version/s: 1.1.9.Final > All ResourceProvider#canProvide implementations could try to inject subtypes > ---------------------------------------------------------------------------- > > Key: ARQ-1976 > URL: https://issues.jboss.org/browse/ARQ-1976 > Project: Arquillian > Issue Type: Bug > Reporter: Radoslav Husar > Fix For: 1.1.9.Final > > > Currently the conditions seem to be the other way round as they normally would: > {noformat} > @Override > public boolean canProvide(Class type) > { > - return Deployer.class.isAssignableFrom(type); > + return type.isAssignableFrom(Deployer.class); > } > {noformat} > It does not seem to be intentional. This would not be usually spotted because usually the same class is injected and requested and no provider provides a subtype of other ResourceProvider, so the problem would never occur. > The resulting exception would look like: > {noformat} > java.lang.RuntimeException: Could not set value on field protected ClassA TestClass.field using ClassB at 19b89d4, > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 13:35:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 13:35:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1976) All ResourceProvider#canProvide implementations could try to inject subtypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1976: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/93 > All ResourceProvider#canProvide implementations could try to inject subtypes > ---------------------------------------------------------------------------- > > Key: ARQ-1976 > URL: https://issues.jboss.org/browse/ARQ-1976 > Project: Arquillian > Issue Type: Bug > Reporter: Radoslav Husar > Fix For: 1.1.9.Final > > > Currently the conditions seem to be the other way round as they normally would: > {noformat} > @Override > public boolean canProvide(Class type) > { > - return Deployer.class.isAssignableFrom(type); > + return type.isAssignableFrom(Deployer.class); > } > {noformat} > It does not seem to be intentional. This would not be usually spotted because usually the same class is injected and requested and no provider provides a subtype of other ResourceProvider, so the problem would never occur. > The resulting exception would look like: > {noformat} > java.lang.RuntimeException: Could not set value on field protected ClassA TestClass.field using ClassB at 19b89d4, > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 13:35:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 13:35:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1976) All ResourceProvider#canProvide implementations could try to inject subtypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1976: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > All ResourceProvider#canProvide implementations could try to inject subtypes > ---------------------------------------------------------------------------- > > Key: ARQ-1976 > URL: https://issues.jboss.org/browse/ARQ-1976 > Project: Arquillian > Issue Type: Bug > Reporter: Radoslav Husar > Fix For: 1.1.9.Final > > > Currently the conditions seem to be the other way round as they normally would: > {noformat} > @Override > public boolean canProvide(Class type) > { > - return Deployer.class.isAssignableFrom(type); > + return type.isAssignableFrom(Deployer.class); > } > {noformat} > It does not seem to be intentional. This would not be usually spotted because usually the same class is injected and requested and no provider provides a subtype of other ResourceProvider, so the problem would never occur. > The resulting exception would look like: > {noformat} > java.lang.RuntimeException: Could not set value on field protected ClassA TestClass.field using ClassB at 19b89d4, > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 13:35:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 13:35:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1966) Support ENV variables to configure Arquillian In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1966: ------------------------------- Fix Version/s: 1.1.9.Final (was: 1.2.0.Alpha1) > Support ENV variables to configure Arquillian > --------------------------------------------- > > Key: ARQ-1966 > URL: https://issues.jboss.org/browse/ARQ-1966 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.8.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.9.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 13:36:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 13:36:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1977) Allow for setting the protocol in ServletProtocolConfiguration In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1977: ---------------------------------- Summary: Allow for setting the protocol in ServletProtocolConfiguration Key: ARQ-1977 URL: https://issues.jboss.org/browse/ARQ-1977 Project: Arquillian Issue Type: Feature Request Components: Test Protocol SPIs and Implementation Affects Versions: 1.1.8.Final Reporter: Aslak Knutsen Fix For: 1.1.9.Final -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 13:37:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 13:37:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1977) Allow for setting the protocol in ServletProtocolConfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1977: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/91 > Allow for setting the protocol in ServletProtocolConfiguration > --------------------------------------------------------------- > > Key: ARQ-1977 > URL: https://issues.jboss.org/browse/ARQ-1977 > Project: Arquillian > Issue Type: Feature Request > Components: Test Protocol SPIs and Implementation > Affects Versions: 1.1.8.Final > Reporter: Aslak Knutsen > Fix For: 1.1.9.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 13:37:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 13:37:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1975) Adds ServletContext as Arquillian Resource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1975: ------------------------------- Fix Version/s: 1.1.9.Final > Adds ServletContext as Arquillian Resource > ------------------------------------------ > > Key: ARQ-1975 > URL: https://issues.jboss.org/browse/ARQ-1975 > Project: Arquillian > Issue Type: Feature Request > Components: Test Protocol SPIs and Implementation > Reporter: Alex Soto > Assignee: Alex Soto > Fix For: 1.1.9.Final > > > Adds ServletContext as Arquillian Resource so it can be used in the tests. In case of in-container tests, ServletContxt used is the one provided by the Servlet protocol. > In case of client test, it only works in case of embedded containers and they are the responsible of provide the instance by producing the instance: > {code:java} > @Inject > @ApplicationScoped > private InstanceProducer servletContextInstanceProducer; > servletContextInstanceProducer.set(servletContext); > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 13:41:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 13:41:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1975) Adds ServletContext as Arquillian Resource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104220#comment-13104220 ] Aslak Knutsen commented on ARQ-1975: ------------------------------------ [~mjobanek] This is a separate issue. In ARQ-540 we want to support injecting @ArquillianResource URL in container. Currently it's only supported on the client side. That can be useful to get the URL of another deployment context. This issue is to support @ArquillianResource ServletContext, which would be the ServletContext used/created by the ServletTestRunner and the in container test is running within. > Adds ServletContext as Arquillian Resource > ------------------------------------------ > > Key: ARQ-1975 > URL: https://issues.jboss.org/browse/ARQ-1975 > Project: Arquillian > Issue Type: Feature Request > Components: Test Protocol SPIs and Implementation > Reporter: Alex Soto > Assignee: Alex Soto > Fix For: 1.1.9.Final > > > Adds ServletContext as Arquillian Resource so it can be used in the tests. In case of in-container tests, ServletContxt used is the one provided by the Servlet protocol. > In case of client test, it only works in case of embedded containers and they are the responsible of provide the instance by producing the instance: > {code:java} > @Inject > @ApplicationScoped > private InstanceProducer servletContextInstanceProducer; > servletContextInstanceProducer.set(servletContext); > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 14:12:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 14:12:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1975) Adds ServletContext as Arquillian Resource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1975: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/92 > Adds ServletContext as Arquillian Resource > ------------------------------------------ > > Key: ARQ-1975 > URL: https://issues.jboss.org/browse/ARQ-1975 > Project: Arquillian > Issue Type: Feature Request > Components: Test Protocol SPIs and Implementation > Reporter: Alex Soto > Assignee: Alex Soto > Fix For: 1.1.9.Final > > > Adds ServletContext as Arquillian Resource so it can be used in the tests. In case of in-container tests, ServletContxt used is the one provided by the Servlet protocol. > In case of client test, it only works in case of embedded containers and they are the responsible of provide the instance by producing the instance: > {code:java} > @Inject > @ApplicationScoped > private InstanceProducer servletContextInstanceProducer; > servletContextInstanceProducer.set(servletContext); > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 14:14:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 14:14:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1975) Adds ServletContext as Arquillian Resource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1975: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Pushed upstream https://github.com/arquillian/arquillian-core/commit/d1e996420d1c9703f23dcca09199472c878ab9ce > Adds ServletContext as Arquillian Resource > ------------------------------------------ > > Key: ARQ-1975 > URL: https://issues.jboss.org/browse/ARQ-1975 > Project: Arquillian > Issue Type: Feature Request > Components: Test Protocol SPIs and Implementation > Reporter: Alex Soto > Assignee: Alex Soto > Fix For: 1.1.9.Final > > > Adds ServletContext as Arquillian Resource so it can be used in the tests. In case of in-container tests, ServletContxt used is the one provided by the Servlet protocol. > In case of client test, it only works in case of embedded containers and they are the responsible of provide the instance by producing the instance: > {code:java} > @Inject > @ApplicationScoped > private InstanceProducer servletContextInstanceProducer; > servletContextInstanceProducer.set(servletContext); > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 14:19:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 14:19:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1978) Allow Containers to register HTTPSContexts in ProtocolMetadata In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1978: ---------------------------------- Summary: Allow Containers to register HTTPSContexts in ProtocolMetadata Key: ARQ-1978 URL: https://issues.jboss.org/browse/ARQ-1978 Project: Arquillian Issue Type: Feature Request Components: Test Protocol SPIs and Implementation Affects Versions: 1.1.8.Final Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.1.9.Final During Deployment a Container should be able to register httpS and http Context objects via the ProtocolMetadata. This would allow Arquillian to automatically fetch the configured https port. This would open for only defining the schema to use in the ServletProtocolConfiguration if you wanted to use httpS communication; https://issues.jboss.org/browse/ARQ-1977 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 14:23:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 14:23:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1977) Allow for setting the protocol in ServletProtocolConfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1977: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Pushed upstream https://github.com/arquillian/arquillian-core/commit/60932e7824e990f6c11ef143a97a20c3faa912fe > Allow for setting the protocol in ServletProtocolConfiguration > --------------------------------------------------------------- > > Key: ARQ-1977 > URL: https://issues.jboss.org/browse/ARQ-1977 > Project: Arquillian > Issue Type: Feature Request > Components: Test Protocol SPIs and Implementation > Affects Versions: 1.1.8.Final > Reporter: Aslak Knutsen > Fix For: 1.1.9.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 20:23:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 20:23:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-540) Support @ArquillianResource URL for in-container test cases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-540. ------------------------------- Fix Version/s: 1.1.9.Final (was: 2.0.0.Beta1) Assignee: Aslak Knutsen Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/a6aae69ba50e233813416647ed501eda6ad6701f > Support @ArquillianResource URL for in-container test cases > ----------------------------------------------------------- > > Key: ARQ-540 > URL: https://issues.jboss.org/browse/ARQ-540 > Project: Arquillian > Issue Type: Enhancement > Affects Versions: 1.0.0.CR2 > Reporter: Ian Brandt > Assignee: Aslak Knutsen > Fix For: 1.1.9.Final > > > From [IRC|http://echelog.matzon.dk/logs/browse/jbosstesting/1312408800]: > {quote} > [2:13pm] ianbrandt: aslak, Should @ArquillianResource injection work for in-container test cases? It works fine when I try it for an as-client test, but when I do the same in-container the org.jboss.arquillian.container.test.impl.enricher.resource.URLResourceProvider.protocolMetadata.get() is null, so no context URL. I verified the container is returning a non-null ProtocolMetaData from deploy(...). > [2:15pm] aslak: ianbrandt, no it currently doesn't work > [2:16pm] aslak: ianbrandt, it probably should, but i'm not sure we have the info incontianer without doing a callback to the client.. > [2:16pm] aslak: ianbrandt, but then we don't know which deployment we are when incontianer, so we have a little problem there.. > [2:17pm] ianbrandt: aslak, Ah, okay. > [2:17pm] aslak: no wait we do > [2:18pm] aslak: the Protocol is executed within a DeploymentScope/ContainerScope, so when it gets the callback, it has the correct context.. > [2:18pm] aslak: we tho need OperatesOnDeployment support for that tho, cuz you possible want to inject URLs not to your self, but to another deployment on possible another contianer that you should invoke from incontainer > [2:19pm] aslak: so from incontianer on dep 1, we can do @ArqRes @OperatesOnDep("dep2") URL url; > [2:23pm] ianbrandt: aslak, Makes sense. It's a little more than I could take on at the moment. I was just augmenting the Tomcat tests to show @ArqRes usage. I'll skip it for shouldBeAbleToInvokeServletInDeployedWebApp, and JIRA+Wiki the limitation. > {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 20:23:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 20:23:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1978) Allow Containers to register HTTPSContexts in ProtocolMetadata In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1978: ------------------------------- Fix Version/s: 1.2.0.Alpha1 (was: 1.1.9.Final) > Allow Containers to register HTTPSContexts in ProtocolMetadata > -------------------------------------------------------------- > > Key: ARQ-1978 > URL: https://issues.jboss.org/browse/ARQ-1978 > Project: Arquillian > Issue Type: Feature Request > Components: Test Protocol SPIs and Implementation > Affects Versions: 1.1.8.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.2.0.Alpha1 > > > During Deployment a Container should be able to register httpS and http Context objects via the ProtocolMetadata. This would allow Arquillian to automatically fetch the configured https port. > This would open for only defining the schema to use in the ServletProtocolConfiguration if you wanted to use httpS communication; https://issues.jboss.org/browse/ARQ-1977 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 20:48:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 20:48:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1977) Allow for setting the protocol in ServletProtocolConfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1977. ------------------------------ > Allow for setting the protocol in ServletProtocolConfiguration > --------------------------------------------------------------- > > Key: ARQ-1977 > URL: https://issues.jboss.org/browse/ARQ-1977 > Project: Arquillian > Issue Type: Feature Request > Components: Test Protocol SPIs and Implementation > Affects Versions: 1.1.8.Final > Reporter: Aslak Knutsen > Fix For: 1.1.9.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 20:48:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 20:48:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1975) Adds ServletContext as Arquillian Resource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1975. ------------------------------ > Adds ServletContext as Arquillian Resource > ------------------------------------------ > > Key: ARQ-1975 > URL: https://issues.jboss.org/browse/ARQ-1975 > Project: Arquillian > Issue Type: Feature Request > Components: Test Protocol SPIs and Implementation > Reporter: Alex Soto > Assignee: Alex Soto > Fix For: 1.1.9.Final > > > Adds ServletContext as Arquillian Resource so it can be used in the tests. In case of in-container tests, ServletContxt used is the one provided by the Servlet protocol. > In case of client test, it only works in case of embedded containers and they are the responsible of provide the instance by producing the instance: > {code:java} > @Inject > @ApplicationScoped > private InstanceProducer servletContextInstanceProducer; > servletContextInstanceProducer.set(servletContext); > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 20:48:07 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 20:48:07 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-540) Support @ArquillianResource URL for in-container test cases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-540. ----------------------------- > Support @ArquillianResource URL for in-container test cases > ----------------------------------------------------------- > > Key: ARQ-540 > URL: https://issues.jboss.org/browse/ARQ-540 > Project: Arquillian > Issue Type: Enhancement > Affects Versions: 1.0.0.CR2 > Reporter: Ian Brandt > Assignee: Aslak Knutsen > Fix For: 1.1.9.Final > > > From [IRC|http://echelog.matzon.dk/logs/browse/jbosstesting/1312408800]: > {quote} > [2:13pm] ianbrandt: aslak, Should @ArquillianResource injection work for in-container test cases? It works fine when I try it for an as-client test, but when I do the same in-container the org.jboss.arquillian.container.test.impl.enricher.resource.URLResourceProvider.protocolMetadata.get() is null, so no context URL. I verified the container is returning a non-null ProtocolMetaData from deploy(...). > [2:15pm] aslak: ianbrandt, no it currently doesn't work > [2:16pm] aslak: ianbrandt, it probably should, but i'm not sure we have the info incontianer without doing a callback to the client.. > [2:16pm] aslak: ianbrandt, but then we don't know which deployment we are when incontianer, so we have a little problem there.. > [2:17pm] ianbrandt: aslak, Ah, okay. > [2:17pm] aslak: no wait we do > [2:18pm] aslak: the Protocol is executed within a DeploymentScope/ContainerScope, so when it gets the callback, it has the correct context.. > [2:18pm] aslak: we tho need OperatesOnDeployment support for that tho, cuz you possible want to inject URLs not to your self, but to another deployment on possible another contianer that you should invoke from incontainer > [2:19pm] aslak: so from incontianer on dep 1, we can do @ArqRes @OperatesOnDep("dep2") URL url; > [2:23pm] ianbrandt: aslak, Makes sense. It's a little more than I could take on at the moment. I was just augmenting the Tomcat tests to show @ArqRes usage. I'll skip it for shouldBeAbleToInvokeServletInDeployedWebApp, and JIRA+Wiki the limitation. > {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 20:48:07 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 20:48:07 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1966) Support ENV variables to configure Arquillian In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1966. ------------------------------ > Support ENV variables to configure Arquillian > --------------------------------------------- > > Key: ARQ-1966 > URL: https://issues.jboss.org/browse/ARQ-1966 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.8.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.9.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 20:48:07 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 20:48:07 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1976) All ResourceProvider#canProvide implementations could try to inject subtypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1976. ------------------------------ > All ResourceProvider#canProvide implementations could try to inject subtypes > ---------------------------------------------------------------------------- > > Key: ARQ-1976 > URL: https://issues.jboss.org/browse/ARQ-1976 > Project: Arquillian > Issue Type: Bug > Reporter: Radoslav Husar > Fix For: 1.1.9.Final > > > Currently the conditions seem to be the other way round as they normally would: > {noformat} > @Override > public boolean canProvide(Class type) > { > - return Deployer.class.isAssignableFrom(type); > + return type.isAssignableFrom(Deployer.class); > } > {noformat} > It does not seem to be intentional. This would not be usually spotted because usually the same class is injected and requested and no provider provides a subtype of other ResourceProvider, so the problem would never occur. > The resulting exception would look like: > {noformat} > java.lang.RuntimeException: Could not set value on field protected ClassA TestClass.field using ClassB at 19b89d4, > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 21:08:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 21:08:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-328) EJB-API dependencies in Weld EE container should be optional (causes failures on boot) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-328: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-weld/pull/19 > EJB-API dependencies in Weld EE container should be optional (causes failures on boot) > -------------------------------------------------------------------------------------- > > Key: ARQ-328 > URL: https://issues.jboss.org/browse/ARQ-328 > Project: Arquillian > Issue Type: Feature Request > Components: Weld Containers > Affects Versions: 1.0.0.Alpha4 > Reporter: Lincoln Baxter III > > EJB APIs should be optional. If users do not supply the API jars, then EJB services should not attempt to load. This would enable easier configuration for those users who do not need EJB services, who only want Weld in EE-like container. > Currently the ejb-api maven dependency is required. > java.lang.NoClassDefFoundError: javax/ejb/Stateless > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.findEjbs(Ejbs.java:38) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.createEjbDescriptors(Ejbs.java:25) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.BeanDeploymentArchiveImpl.(BeanDeploymentArchiveImpl.java:81) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.(TestContainer.java:215) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:76) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:62) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:50) > at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) > at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) > at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:96) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:162) > at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:186) > at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:182) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:127) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:64) > Caused by: java.lang.ClassNotFoundException: javax.ejb.Stateless > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > ... 28 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 21:09:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 21:09:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-328) EJB-API dependencies in Weld EE container should be optional (causes failures on boot) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-328: ------------------------------ Fix Version/s: weld_1.0.0.CR9 > EJB-API dependencies in Weld EE container should be optional (causes failures on boot) > -------------------------------------------------------------------------------------- > > Key: ARQ-328 > URL: https://issues.jboss.org/browse/ARQ-328 > Project: Arquillian > Issue Type: Feature Request > Components: Weld Containers > Affects Versions: 1.0.0.Alpha4 > Reporter: Lincoln Baxter III > Fix For: weld_1.0.0.CR9 > > > EJB APIs should be optional. If users do not supply the API jars, then EJB services should not attempt to load. This would enable easier configuration for those users who do not need EJB services, who only want Weld in EE-like container. > Currently the ejb-api maven dependency is required. > java.lang.NoClassDefFoundError: javax/ejb/Stateless > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.findEjbs(Ejbs.java:38) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.createEjbDescriptors(Ejbs.java:25) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.BeanDeploymentArchiveImpl.(BeanDeploymentArchiveImpl.java:81) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.(TestContainer.java:215) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:76) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:62) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:50) > at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) > at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) > at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:96) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:162) > at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:186) > at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:182) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:127) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:64) > Caused by: java.lang.ClassNotFoundException: javax.ejb.Stateless > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > ... 28 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 21:10:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 21:10:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1793) arquillian-weld-ee-embedded expose wrong version of Arquillian Core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1793: ------------------------------- Fix Version/s: weld_1.0.0.CR9 (was: weld_1.0.0.Final) > arquillian-weld-ee-embedded expose wrong version of Arquillian Core > ------------------------------------------------------------------- > > Key: ARQ-1793 > URL: https://issues.jboss.org/browse/ARQ-1793 > Project: Arquillian > Issue Type: Feature Request > Components: Weld Containers > Affects Versions: weld_1.0.0.CR8 > Reporter: Tomas Remes > Assignee: Aslak Knutsen > Fix For: weld_1.0.0.CR9 > > > weld-bom expose an older v of Arquillian Core via weld-parent. This forces the direct dependencies of arquillian-weld-ee-embedded on Arquillian Core to downgrade to the weld-bom v while leaving the other dependencies upgraded. Result is a mixed set of Arquillian Core artifacts. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 21:11:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 21:11:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-328) EJB-API dependencies in Weld EE container should be optional (causes failures on boot) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-328: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > EJB-API dependencies in Weld EE container should be optional (causes failures on boot) > -------------------------------------------------------------------------------------- > > Key: ARQ-328 > URL: https://issues.jboss.org/browse/ARQ-328 > Project: Arquillian > Issue Type: Feature Request > Components: Weld Containers > Affects Versions: 1.0.0.Alpha4 > Reporter: Lincoln Baxter III > Fix For: weld_1.0.0.CR9 > > > EJB APIs should be optional. If users do not supply the API jars, then EJB services should not attempt to load. This would enable easier configuration for those users who do not need EJB services, who only want Weld in EE-like container. > Currently the ejb-api maven dependency is required. > java.lang.NoClassDefFoundError: javax/ejb/Stateless > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.findEjbs(Ejbs.java:38) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.createEjbDescriptors(Ejbs.java:25) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.BeanDeploymentArchiveImpl.(BeanDeploymentArchiveImpl.java:81) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.(TestContainer.java:215) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:76) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:62) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:50) > at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) > at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) > at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:96) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:162) > at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:186) > at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:182) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:127) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:64) > Caused by: java.lang.ClassNotFoundException: javax.ejb.Stateless > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > ... 28 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 21:12:05 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 21:12:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1793) arquillian-weld-ee-embedded expose wrong version of Arquillian Core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1793. ------------------------------ > arquillian-weld-ee-embedded expose wrong version of Arquillian Core > ------------------------------------------------------------------- > > Key: ARQ-1793 > URL: https://issues.jboss.org/browse/ARQ-1793 > Project: Arquillian > Issue Type: Feature Request > Components: Weld Containers > Affects Versions: weld_1.0.0.CR8 > Reporter: Tomas Remes > Assignee: Aslak Knutsen > Fix For: weld_1.0.0.CR9 > > > weld-bom expose an older v of Arquillian Core via weld-parent. This forces the direct dependencies of arquillian-weld-ee-embedded on Arquillian Core to downgrade to the weld-bom v while leaving the other dependencies upgraded. Result is a mixed set of Arquillian Core artifacts. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 21:12:06 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Sep 2015 21:12:06 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-328) EJB-API dependencies in Weld EE container should be optional (causes failures on boot) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-328. ----------------------------- > EJB-API dependencies in Weld EE container should be optional (causes failures on boot) > -------------------------------------------------------------------------------------- > > Key: ARQ-328 > URL: https://issues.jboss.org/browse/ARQ-328 > Project: Arquillian > Issue Type: Feature Request > Components: Weld Containers > Affects Versions: 1.0.0.Alpha4 > Reporter: Lincoln Baxter III > Fix For: weld_1.0.0.CR9 > > > EJB APIs should be optional. If users do not supply the API jars, then EJB services should not attempt to load. This would enable easier configuration for those users who do not need EJB services, who only want Weld in EE-like container. > Currently the ejb-api maven dependency is required. > java.lang.NoClassDefFoundError: javax/ejb/Stateless > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.findEjbs(Ejbs.java:38) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.createEjbDescriptors(Ejbs.java:25) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.BeanDeploymentArchiveImpl.(BeanDeploymentArchiveImpl.java:81) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.(TestContainer.java:215) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:76) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:62) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:50) > at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) > at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) > at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:96) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:162) > at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:186) > at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:182) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:127) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:64) > Caused by: java.lang.ClassNotFoundException: javax.ejb.Stateless > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > ... 28 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 8 09:59:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 8 Sep 2015 09:59:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1979) Screenshot is not taken when the test fails In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-1979: ----------------------------------- Summary: Screenshot is not taken when the test fails Key: ARQ-1979 URL: https://issues.jboss.org/browse/ARQ-1979 Project: Arquillian Issue Type: Bug Components: Extension - Recorder Reporter: Matous Jobanek The cause: There in the Arquillian-core 1.1.7.Final have been introduced new events: {{AfterTestLifecycleEvent}} {{BeforeTestLifecycleEvent}} that replaces the behaviour of predecessors {{After}} {{Before}} For more information see: https://github.com/arquillian/arquillian-core/commit/606b4b29a3a561bc0ea6ed2f4883f7e37fa5153c ARQ-1818 This change is not reflected there in the arquillian-recorder project - this causes that the screenshot is not taken when test fails: https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L96 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 10:01:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 8 Sep 2015 10:01:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1979) Screenshot is not taken when a test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-1979: -------------------------------- Summary: Screenshot is not taken when a test fails (was: Screenshot is not taken when the test fails) > Screenshot is not taken when a test fails > ----------------------------------------- > > Key: ARQ-1979 > URL: https://issues.jboss.org/browse/ARQ-1979 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Reporter: Matous Jobanek > > The cause: > There in the Arquillian-core 1.1.7.Final have been introduced new events: > {{AfterTestLifecycleEvent}} > {{BeforeTestLifecycleEvent}} > that replaces the behaviour of predecessors > {{After}} > {{Before}} > For more information see: > https://github.com/arquillian/arquillian-core/commit/606b4b29a3a561bc0ea6ed2f4883f7e37fa5153c > ARQ-1818 > This change is not reflected there in the arquillian-recorder project - this causes that the screenshot is not taken when test fails: > https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L96 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 10 08:34:00 2015 From: issues at jboss.org (Ladislav Thon (JIRA)) Date: Thu, 10 Sep 2015 08:34:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1971) Start WildFly in domain mode via arquillian fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107387#comment-13107387 ] Ladislav Thon commented on ARQ-1971: ------------------------------------ Should probably be an issue in the WFLY project? > Start WildFly in domain mode via arquillian fails > ------------------------------------------------- > > Key: ARQ-1971 > URL: https://issues.jboss.org/browse/ARQ-1971 > Project: Arquillian > Issue Type: Bug > Components: JBoss AS Containers > Reporter: Radim Hatlapatka > Priority: Blocker > > Starting WildFly container in domain mode from arquillian fails with [1]. > Not sure what is causing the issue, it seems that it tries to read-resource in wrong time. If I put sleep before the read-resource is called [2], the server is correctly started (no exception is thrown) > I am using arquillian container for domain managed in version 1.0.1.Final, I have also tried it with latest code from git repository [https://github.com/wildfly/wildfly-arquillian/commit/9467473d8b440ad9d01f5b84ae8373a19cde9249] with the same result. > I tried it using WildFly 10.0.0.Beta1. > [1] > {noformat} > java.lang.RuntimeException: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:390) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.checkSuccessful(ManagementClient.java:446) > at org.jboss.as.arquillian.container.domain.ManagementClient.executeForResult(ManagementClient.java:439) > at org.jboss.as.arquillian.container.domain.ManagementClient.readResource(ManagementClient.java:417) > at org.jboss.as.arquillian.container.domain.ManagementClient.readRootNode(ManagementClient.java:294) > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:387) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > {noformat} > [2] > `org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer` > {code} > Domain domain = managementClient.createDomain(containerNameMap); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Sep 12 06:21:00 2015 From: issues at jboss.org (Christian Schulz (JIRA)) Date: Sat, 12 Sep 2015 06:21:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1237) Warp: use PortProber to determine free ports for proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108040#comment-13108040 ] Christian Schulz commented on ARQ-1237: --------------------------------------- Any news about it? I have multiple wildfly instances with warp tests and it seems that they collide. > Warp: use PortProber to determine free ports for proxy > ------------------------------------------------------ > > Key: ARQ-1237 > URL: https://issues.jboss.org/browse/ARQ-1237 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Bartosz Majsak > Priority: Minor > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Selenium 2 uses {{PortProber}} to check free ports to run Selenium Server on. > We can leverage that component too for Warp proxy and avoid conflicting ports. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Sep 12 11:57:00 2015 From: issues at jboss.org (Christian Schulz (JIRA)) Date: Sat, 12 Sep 2015 11:57:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1237) Warp: use PortProber to determine free ports for proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108040#comment-13108040 ] Christian Schulz edited comment on ARQ-1237 at 9/12/15 11:56 AM: ----------------------------------------------------------------- Any news about it? I have different projects using warp tests. Executing them parallel spawn multiple wildfly instances and it seems that they collide. was (Author: chschulz): Any news about it? I have multiple wildfly instances with warp tests and it seems that they collide. > Warp: use PortProber to determine free ports for proxy > ------------------------------------------------------ > > Key: ARQ-1237 > URL: https://issues.jboss.org/browse/ARQ-1237 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Bartosz Majsak > Priority: Minor > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Selenium 2 uses {{PortProber}} to check free ports to run Selenium Server on. > We can leverage that component too for Warp proxy and avoid conflicting ports. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 14 18:25:00 2015 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 14 Sep 2015 18:25:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1971) Start WildFly in domain mode via arquillian fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108468#comment-13108468 ] James Perkins commented on ARQ-1971: ------------------------------------ I think this actually has to do with WFCORE-845. > Start WildFly in domain mode via arquillian fails > ------------------------------------------------- > > Key: ARQ-1971 > URL: https://issues.jboss.org/browse/ARQ-1971 > Project: Arquillian > Issue Type: Bug > Components: JBoss AS Containers > Reporter: Radim Hatlapatka > Priority: Blocker > > Starting WildFly container in domain mode from arquillian fails with [1]. > Not sure what is causing the issue, it seems that it tries to read-resource in wrong time. If I put sleep before the read-resource is called [2], the server is correctly started (no exception is thrown) > I am using arquillian container for domain managed in version 1.0.1.Final, I have also tried it with latest code from git repository [https://github.com/wildfly/wildfly-arquillian/commit/9467473d8b440ad9d01f5b84ae8373a19cde9249] with the same result. > I tried it using WildFly 10.0.0.Beta1. > [1] > {noformat} > java.lang.RuntimeException: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:390) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.checkSuccessful(ManagementClient.java:446) > at org.jboss.as.arquillian.container.domain.ManagementClient.executeForResult(ManagementClient.java:439) > at org.jboss.as.arquillian.container.domain.ManagementClient.readResource(ManagementClient.java:417) > at org.jboss.as.arquillian.container.domain.ManagementClient.readRootNode(ManagementClient.java:294) > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:387) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > {noformat} > [2] > `org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer` > {code} > Domain domain = managementClient.createDomain(containerNameMap); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 14 18:34:00 2015 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 14 Sep 2015 18:34:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1971) Start WildFly in domain mode via arquillian fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108468#comment-13108468 ] James Perkins edited comment on ARQ-1971 at 9/14/15 6:33 PM: ------------------------------------------------------------- -I think this actually has to do with WFCORE-845.- I'm going to retract that. The issue is a server-group is not in the correct state during the read therefore the recursive read fails. I think in general the domain client needs to be cleaned up. was (Author: jamezp): I think this actually has to do with WFCORE-845. > Start WildFly in domain mode via arquillian fails > ------------------------------------------------- > > Key: ARQ-1971 > URL: https://issues.jboss.org/browse/ARQ-1971 > Project: Arquillian > Issue Type: Bug > Components: JBoss AS Containers > Reporter: Radim Hatlapatka > Priority: Blocker > > Starting WildFly container in domain mode from arquillian fails with [1]. > Not sure what is causing the issue, it seems that it tries to read-resource in wrong time. If I put sleep before the read-resource is called [2], the server is correctly started (no exception is thrown) > I am using arquillian container for domain managed in version 1.0.1.Final, I have also tried it with latest code from git repository [https://github.com/wildfly/wildfly-arquillian/commit/9467473d8b440ad9d01f5b84ae8373a19cde9249] with the same result. > I tried it using WildFly 10.0.0.Beta1. > [1] > {noformat} > java.lang.RuntimeException: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:390) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.checkSuccessful(ManagementClient.java:446) > at org.jboss.as.arquillian.container.domain.ManagementClient.executeForResult(ManagementClient.java:439) > at org.jboss.as.arquillian.container.domain.ManagementClient.readResource(ManagementClient.java:417) > at org.jboss.as.arquillian.container.domain.ManagementClient.readRootNode(ManagementClient.java:294) > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:387) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > {noformat} > [2] > `org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer` > {code} > Domain domain = managementClient.createDomain(containerNameMap); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 12:13:00 2015 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 17 Sep 2015 12:13:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1971) Start WildFly in domain mode via arquillian fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110124#comment-13110124 ] James Perkins commented on ARQ-1971: ------------------------------------ This should fix it https://github.com/wildfly/wildfly-arquillian/pull/43. > Start WildFly in domain mode via arquillian fails > ------------------------------------------------- > > Key: ARQ-1971 > URL: https://issues.jboss.org/browse/ARQ-1971 > Project: Arquillian > Issue Type: Bug > Components: JBoss AS Containers > Reporter: Radim Hatlapatka > Priority: Blocker > > Starting WildFly container in domain mode from arquillian fails with [1]. > Not sure what is causing the issue, it seems that it tries to read-resource in wrong time. If I put sleep before the read-resource is called [2], the server is correctly started (no exception is thrown) > I am using arquillian container for domain managed in version 1.0.1.Final, I have also tried it with latest code from git repository [https://github.com/wildfly/wildfly-arquillian/commit/9467473d8b440ad9d01f5b84ae8373a19cde9249] with the same result. > I tried it using WildFly 10.0.0.Beta1. > [1] > {noformat} > java.lang.RuntimeException: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:390) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.checkSuccessful(ManagementClient.java:446) > at org.jboss.as.arquillian.container.domain.ManagementClient.executeForResult(ManagementClient.java:439) > at org.jboss.as.arquillian.container.domain.ManagementClient.readResource(ManagementClient.java:417) > at org.jboss.as.arquillian.container.domain.ManagementClient.readRootNode(ManagementClient.java:294) > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:387) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > {noformat} > [2] > `org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer` > {code} > Domain domain = managementClient.createDomain(containerNameMap); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 18 03:34:00 2015 From: issues at jboss.org (Radim Hatlapatka (JIRA)) Date: Fri, 18 Sep 2015 03:34:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1971) Start WildFly in domain mode via arquillian fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110290#comment-13110290 ] Radim Hatlapatka commented on ARQ-1971: --------------------------------------- I tried it with the PR and domain server is successfully started via arquillian. > Start WildFly in domain mode via arquillian fails > ------------------------------------------------- > > Key: ARQ-1971 > URL: https://issues.jboss.org/browse/ARQ-1971 > Project: Arquillian > Issue Type: Bug > Components: JBoss AS Containers > Reporter: Radim Hatlapatka > Priority: Blocker > > Starting WildFly container in domain mode from arquillian fails with [1]. > Not sure what is causing the issue, it seems that it tries to read-resource in wrong time. If I put sleep before the read-resource is called [2], the server is correctly started (no exception is thrown) > I am using arquillian container for domain managed in version 1.0.1.Final, I have also tried it with latest code from git repository [https://github.com/wildfly/wildfly-arquillian/commit/9467473d8b440ad9d01f5b84ae8373a19cde9249] with the same result. > I tried it using WildFly 10.0.0.Beta1. > [1] > {noformat} > java.lang.RuntimeException: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:390) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.checkSuccessful(ManagementClient.java:446) > at org.jboss.as.arquillian.container.domain.ManagementClient.executeForResult(ManagementClient.java:439) > at org.jboss.as.arquillian.container.domain.ManagementClient.readResource(ManagementClient.java:417) > at org.jboss.as.arquillian.container.domain.ManagementClient.readRootNode(ManagementClient.java:294) > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:387) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > {noformat} > [2] > `org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer` > {code} > Domain domain = managementClient.createDomain(containerNameMap); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 18 04:12:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Fri, 18 Sep 2015 04:12:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1980) Add support for BrowserStack In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-1980: ----------------------------------- Summary: Add support for BrowserStack Key: ARQ-1980 URL: https://issues.jboss.org/browse/ARQ-1980 Project: Arquillian Issue Type: Feature Request Components: Extension - Drone Reporter: Matous Jobanek Assignee: Matous Jobanek Fix For: drone_2.1.0.Final Add support for BrowserStack see: https://github.com/MatousJobanek/arquillian-drone-browserstack-webdriver/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 18 11:34:00 2015 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 18 Sep 2015 11:34:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1971) Start WildFly in domain mode via arquillian fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110492#comment-13110492 ] James Perkins commented on ARQ-1971: ------------------------------------ Excellent. There's an issue with deploying to domain mode as well https://issues.jboss.org/browse/WFCORE-988. The only way to get it to fully work is to disable assertions, but that seems odd for tests. > Start WildFly in domain mode via arquillian fails > ------------------------------------------------- > > Key: ARQ-1971 > URL: https://issues.jboss.org/browse/ARQ-1971 > Project: Arquillian > Issue Type: Bug > Components: JBoss AS Containers > Reporter: Radim Hatlapatka > Priority: Blocker > > Starting WildFly container in domain mode from arquillian fails with [1]. > Not sure what is causing the issue, it seems that it tries to read-resource in wrong time. If I put sleep before the read-resource is called [2], the server is correctly started (no exception is thrown) > I am using arquillian container for domain managed in version 1.0.1.Final, I have also tried it with latest code from git repository [https://github.com/wildfly/wildfly-arquillian/commit/9467473d8b440ad9d01f5b84ae8373a19cde9249] with the same result. > I tried it using WildFly 10.0.0.Beta1. > [1] > {noformat} > java.lang.RuntimeException: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:390) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined > at org.jboss.as.arquillian.container.domain.ManagementClient.checkSuccessful(ManagementClient.java:446) > at org.jboss.as.arquillian.container.domain.ManagementClient.executeForResult(ManagementClient.java:439) > at org.jboss.as.arquillian.container.domain.ManagementClient.readResource(ManagementClient.java:417) > at org.jboss.as.arquillian.container.domain.ManagementClient.readRootNode(ManagementClient.java:294) > at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:387) > at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115) > at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:131) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > {noformat} > [2] > `org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer` > {code} > Domain domain = managementClient.createDomain(containerNameMap); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 06:48:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 21 Sep 2015 06:48:00 -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: ---------------------------- Fix Version/s: warp_1.0.0.Beta1 > 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 Sep 21 14:25:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 21 Sep 2015 14:25:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1237) Warp: use PortProber to determine free ports for proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1237: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-warp/pull/29 > Warp: use PortProber to determine free ports for proxy > ------------------------------------------------------ > > Key: ARQ-1237 > URL: https://issues.jboss.org/browse/ARQ-1237 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Bartosz Majsak > Priority: Minor > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Selenium 2 uses {{PortProber}} to check free ports to run Selenium Server on. > We can leverage that component too for Warp proxy and avoid conflicting ports. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 15:38:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 21 Sep 2015 15:38:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1981) Warp: leverage Chameleon for broader container-coverage In-Reply-To: References: Message-ID: Luk?? Fry? created ARQ-1981: ------------------------------- Summary: Warp: leverage Chameleon for broader container-coverage Key: ARQ-1981 URL: https://issues.jboss.org/browse/ARQ-1981 Project: Arquillian Issue Type: Enhancement Components: Extension - Warp Reporter: Luk?? Fry? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 15:40:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 21 Sep 2015 15:40:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1981) Warp: leverage Chameleon for broader container-coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1981: ---------------------------- Description: Arquillian Chameleon allows for simple switching between various container implementations, modes and versions: http://arquillian.org/modules/arquillian-container-chameleon-container-adapter/ We could leverage Chameleon in order to test Warp against functionally against different containers, modes and versions. > Warp: leverage Chameleon for broader container-coverage > ------------------------------------------------------- > > Key: ARQ-1981 > URL: https://issues.jboss.org/browse/ARQ-1981 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Reporter: Luk?? Fry? > > Arquillian Chameleon allows for simple switching between various container implementations, modes and versions: > http://arquillian.org/modules/arquillian-container-chameleon-container-adapter/ > We could leverage Chameleon in order to test Warp against functionally against different containers, modes and versions. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 15:44:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 21 Sep 2015 15:44:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1237) Warp: use PortProber to determine free ports for proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQ-1237: ------------------------------- Assignee: Christian Schulz (was: Bartosz Majsak) > Warp: use PortProber to determine free ports for proxy > ------------------------------------------------------ > > Key: ARQ-1237 > URL: https://issues.jboss.org/browse/ARQ-1237 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Christian Schulz > Priority: Minor > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Selenium 2 uses {{PortProber}} to check free ports to run Selenium Server on. > We can leverage that component too for Warp proxy and avoid conflicting ports. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 15:44:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 21 Sep 2015 15:44:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1237) Warp: use PortProber to determine free ports for proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1237: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Warp: use PortProber to determine free ports for proxy > ------------------------------------------------------ > > Key: ARQ-1237 > URL: https://issues.jboss.org/browse/ARQ-1237 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Christian Schulz > Priority: Minor > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Selenium 2 uses {{PortProber}} to check free ports to run Selenium Server on. > We can leverage that component too for Warp proxy and avoid conflicting ports. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 15:44:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 21 Sep 2015 15:44:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1237) Warp: use PortProber to determine free ports for proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111013#comment-13111013 ] Luk?? Fry? commented on ARQ-1237: --------------------------------- Thanks [~chschulz], this is nice contribution! > Warp: use PortProber to determine free ports for proxy > ------------------------------------------------------ > > Key: ARQ-1237 > URL: https://issues.jboss.org/browse/ARQ-1237 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Christian Schulz > Priority: Minor > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Selenium 2 uses {{PortProber}} to check free ports to run Selenium Server on. > We can leverage that component too for Warp proxy and avoid conflicting ports. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 15:52:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 21 Sep 2015 15:52:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-475) Support inheritance for page fragments delegating to WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-475: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/133/files > Support inheritance for page fragments delegating to WebElement > --------------------------------------------------------------- > > Key: ARQGRA-475 > URL: https://issues.jboss.org/browse/ARQGRA-475 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Priority: Minor > > When implementing page fragments that extend WebElement as described in https://docs.jboss.org/author/display/ARQGRA2/Delegate+to+WebElement it is not possible to use superclasses for this construct. > This is because the method {{isAboutToDelegateToWebElement}} in {{PageFragmentEnricher}} just searches the current class, but not the superclasses. > I'm preparing a minor change for this currently. Hope to send the pull request soon. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 15:53:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 21 Sep 2015 15:53:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-475) Support inheritance for page fragments delegating to WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-475: --------------------------------- Assignee: Michael Kotten > Support inheritance for page fragments delegating to WebElement > --------------------------------------------------------------- > > Key: ARQGRA-475 > URL: https://issues.jboss.org/browse/ARQGRA-475 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Assignee: Michael Kotten > Priority: Minor > > When implementing page fragments that extend WebElement as described in https://docs.jboss.org/author/display/ARQGRA2/Delegate+to+WebElement it is not possible to use superclasses for this construct. > This is because the method {{isAboutToDelegateToWebElement}} in {{PageFragmentEnricher}} just searches the current class, but not the superclasses. > I'm preparing a minor change for this currently. Hope to send the pull request soon. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 15:53:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 21 Sep 2015 15:53:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-476) Extend root element from GrapheneElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-476: --------------------------------- Assignee: Michael Kotten > Extend root element from GrapheneElement > ----------------------------------------- > > Key: ARQGRA-476 > URL: https://issues.jboss.org/browse/ARQGRA-476 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Assignee: Michael Kotten > Priority: Minor > > Currently the root element in page fragments must extend WebElement. I would like to extend this, so it can also extend GrapheneElement. I'm preparing a pull request for this currently. Would be nice if this enhancement would make it to the next release. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 16:29:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 21 Sep 2015 16:29: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: Luk?? Fry? created ARQGRA-477: --------------------------------- Summary: 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? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 23 10:18:01 2015 From: issues at jboss.org (Luca Stancapiano (JIRA)) Date: Wed, 23 Sep 2015 10:18:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-286) Should support JUnit @Rules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111728#comment-13111728 ] Luca Stancapiano commented on ARQ-286: -------------------------------------- I'm triing arquillian 1.1.7 with the same code in mode 'in container' so: {code:java} @RunWith(Arquillian.class) public class TestCase { @Rule public ExpectedException e = ExpectedException.none(); @Test public void test() { e.expect(RuntimeException.class) throw new RuntimeException(); } } {code} I see that the rule is executed anyhow in the client side. Should it run in the container side? > Should support JUnit @Rules > --------------------------- > > Key: ARQ-286 > URL: https://issues.jboss.org/browse/ARQ-286 > Project: Arquillian > Issue Type: Feature Request > Components: Test Harness Integration > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.5.Final > > > Using the JUnit feature @Rule becomes a problem when running against Remote servers since the @Rule is executed both on the Client and Container side. > It works fine in Embedded Containers since the Test is executed in the same VM, but if the Rule is dependent on Container features, the @Test will fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 23 14:47:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 23 Sep 2015 14:47:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-286) Should support JUnit @Rules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111844#comment-13111844 ] Aslak Knutsen commented on ARQ-286: ----------------------------------- Do you have the code/pom example somewhere? > Should support JUnit @Rules > --------------------------- > > Key: ARQ-286 > URL: https://issues.jboss.org/browse/ARQ-286 > Project: Arquillian > Issue Type: Feature Request > Components: Test Harness Integration > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.5.Final > > > Using the JUnit feature @Rule becomes a problem when running against Remote servers since the @Rule is executed both on the Client and Container side. > It works fine in Embedded Containers since the Test is executed in the same VM, but if the Rule is dependent on Container features, the @Test will fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 02:59:01 2015 From: issues at jboss.org (Luca Stancapiano (JIRA)) Date: Thu, 24 Sep 2015 02:59:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-286) Should support JUnit @Rules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111973#comment-13111973 ] Luca Stancapiano commented on ARQ-286: -------------------------------------- I preapare a git project...wait please ;) > Should support JUnit @Rules > --------------------------- > > Key: ARQ-286 > URL: https://issues.jboss.org/browse/ARQ-286 > Project: Arquillian > Issue Type: Feature Request > Components: Test Harness Integration > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.5.Final > > > Using the JUnit feature @Rule becomes a problem when running against Remote servers since the @Rule is executed both on the Client and Container side. > It works fine in Embedded Containers since the Test is executed in the same VM, but if the Rule is dependent on Container features, the @Test will fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 14:08:00 2015 From: issues at jboss.org (Damien Vidal (JIRA)) Date: Thu, 24 Sep 2015 14:08:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1982) Each test case is launched 4 times In-Reply-To: References: Message-ID: Damien Vidal created ARQ-1982: --------------------------------- Summary: Each test case is launched 4 times Key: ARQ-1982 URL: https://issues.jboss.org/browse/ARQ-1982 Project: Arquillian Issue Type: Bug Reporter: Damien Vidal Each test is called 4 times on the following orders. @Before @Before @Test - firstTest @Test - firstTest @After @After @Before @Before @Test - firstTest @Test - firstTest @After @After ------------------------- @Before @Before @Test - secondTest @Test - secondTest @After @After @Before @Before @Test - secondTest @Test - secondTest @After @After Note: --------- I tried without Drone - same issue I tried without RunAsClient - same issue and without Deployment The instance of the Class is the same for each call of @Test method -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 14:09:00 2015 From: issues at jboss.org (Damien Vidal (JIRA)) Date: Thu, 24 Sep 2015 14:09:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1982) Each test case is launched 4 times In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Vidal updated ARQ-1982: ------------------------------ Steps to Reproduce: - Create a Test class using Arquillian import java.io.InputStream; import java.util.concurrent.TimeUnit; import junit.framework.Assert; import org.apache.commons.io.FileUtils; import org.jboss.arquillian.container.test.api.Deployment; import org.jboss.arquillian.container.test.api.RunAsClient; import org.jboss.arquillian.drone.api.annotation.Drone; import org.jboss.arquillian.junit.Arquillian; import org.jboss.arquillian.junit.InSequence; import org.jboss.osgi.metadata.OSGiManifestBuilder; import org.jboss.shrinkwrap.api.ShrinkWrap; import org.jboss.shrinkwrap.api.asset.Asset; import org.jboss.shrinkwrap.api.spec.JavaArchive; import org.junit.After; import org.junit.Before; import org.junit.Test; import org.junit.runner.RunWith; import org.openqa.selenium.Alert; import org.openqa.selenium.By; import org.openqa.selenium.NoAlertPresentException; import org.openqa.selenium.NoSuchElementException; import org.openqa.selenium.OutputType; import org.openqa.selenium.TakesScreenshot; import org.openqa.selenium.WebDriver; import org.openqa.selenium.support.ui.WebDriverWait; import org.osgi.framework.Bundle; @RunAsClient @RunWith(Arquillian.class) public class SampleTest { @Drone protected WebDriver driver; protected StringBuffer verificationErrors = new StringBuffer(); @Deployment(testable = false) public static JavaArchive createdeployment() { final JavaArchive archive = ShrinkWrap.create(JavaArchive.class, "test.jar"); archive.setManifest(new Asset() { @Override public InputStream openStream() { OSGiManifestBuilder builder = OSGiManifestBuilder.newInstance(); builder.addBundleSymbolicName(archive.getName()); builder.addBundleManifestVersion(2); builder.addImportPackages(Bundle.class); return builder.openStream(); } }); return archive; } @Before public void setUp() throws Exception { } @Test @InSequence(1) public void firstTest() { System.out.println("firstTest()"); } @Test @InSequence(2) public void secondTest() { System.out.println("secondTest()"); } @After public void tearDown() throws Exception { String verificationErrorString = verificationErrors.toString(); verificationErrors = new StringBuffer(); if (!"".equals(verificationErrorString)) { Assert.fail(verificationErrorString); } } } - Launch it in OSGi using with the plugin: org.eclipse.tycho tycho-surefire-plugin was: - Create a Test class using Arquillian import java.io.InputStream; import java.util.concurrent.TimeUnit; import junit.framework.Assert; import org.apache.commons.io.FileUtils; import org.jboss.arquillian.container.test.api.Deployment; import org.jboss.arquillian.container.test.api.RunAsClient; import org.jboss.arquillian.drone.api.annotation.Drone; import org.jboss.arquillian.junit.Arquillian; import org.jboss.arquillian.junit.InSequence; import org.jboss.osgi.metadata.OSGiManifestBuilder; import org.jboss.shrinkwrap.api.ShrinkWrap; import org.jboss.shrinkwrap.api.asset.Asset; import org.jboss.shrinkwrap.api.spec.JavaArchive; import org.junit.After; import org.junit.Before; import org.junit.Test; import org.junit.runner.RunWith; import org.openqa.selenium.Alert; import org.openqa.selenium.By; import org.openqa.selenium.NoAlertPresentException; import org.openqa.selenium.NoSuchElementException; import org.openqa.selenium.OutputType; import org.openqa.selenium.TakesScreenshot; import org.openqa.selenium.WebDriver; import org.openqa.selenium.support.ui.WebDriverWait; import org.osgi.framework.Bundle; @RunAsClient @RunWith(Arquillian.class) public class SampleTest { @Drone protected WebDriver driver; protected StringBuffer verificationErrors = new StringBuffer(); @Deployment(testable = false) public static JavaArchive createdeployment() { final JavaArchive archive = ShrinkWrap.create(JavaArchive.class, "test.jar"); archive.setManifest(new Asset() { @Override public InputStream openStream() { OSGiManifestBuilder builder = OSGiManifestBuilder.newInstance(); builder.addBundleSymbolicName(archive.getName()); builder.addBundleManifestVersion(2); builder.addImportPackages(Bundle.class); return builder.openStream(); } }); return archive; } @Before public void setUp() throws Exception { } @Test @InSequence(1) public void firstTest() { System.out.println("firstTest()"); } @Test @InSequence(2) public void secondTest() { System.out.println("secondTest()"); } @After public void tearDown() throws Exception { String verificationErrorString = verificationErrors.toString(); verificationErrors = new StringBuffer(); if (!"".equals(verificationErrorString)) { Assert.fail(verificationErrorString); } } } - Launch it is OSGi using with the plugin: org.eclipse.tycho tycho-surefire-plugin Labels: Arquillian OSGI (was: ) > Each test case is launched 4 times > ---------------------------------- > > Key: ARQ-1982 > URL: https://issues.jboss.org/browse/ARQ-1982 > Project: Arquillian > Issue Type: Bug > Reporter: Damien Vidal > Labels: Arquillian, OSGI > > Each test is called 4 times on the following orders. > @Before > @Before > @Test - firstTest > @Test - firstTest > @After > @After > @Before > @Before > @Test - firstTest > @Test - firstTest > @After > @After > ------------------------- > @Before > @Before > @Test - secondTest > @Test - secondTest > @After > @After > @Before > @Before > @Test - secondTest > @Test - secondTest > @After > @After > Note: > --------- > I tried without Drone - same issue > I tried without RunAsClient - same issue and without Deployment > The instance of the Class is the same for each call of @Test method -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 14:10:00 2015 From: issues at jboss.org (Damien Vidal (JIRA)) Date: Thu, 24 Sep 2015 14:10:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1982) Each test case is launched 4 times In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Vidal updated ARQ-1982: ------------------------------ Description: Each test is called 4 times on the following orders. @Before @Before @Test - firstTest @Test - firstTest @After @After @Before @Before @Test - firstTest @Test - firstTest @After @After ------------------------- @Before @Before @Test - secondTest @Test - secondTest @After @After @Before @Before @Test - secondTest @Test - secondTest @After @After Note: --------- I tried without Drone -> same issue I tried without RunAsClient and without Deployment -> same issue The instance of the SampleTest Class is the same for each call of @Test method was: Each test is called 4 times on the following orders. @Before @Before @Test - firstTest @Test - firstTest @After @After @Before @Before @Test - firstTest @Test - firstTest @After @After ------------------------- @Before @Before @Test - secondTest @Test - secondTest @After @After @Before @Before @Test - secondTest @Test - secondTest @After @After Note: --------- I tried without Drone - same issue I tried without RunAsClient - same issue and without Deployment The instance of the Class is the same for each call of @Test method > Each test case is launched 4 times > ---------------------------------- > > Key: ARQ-1982 > URL: https://issues.jboss.org/browse/ARQ-1982 > Project: Arquillian > Issue Type: Bug > Reporter: Damien Vidal > Labels: Arquillian, OSGI > > Each test is called 4 times on the following orders. > @Before > @Before > @Test - firstTest > @Test - firstTest > @After > @After > @Before > @Before > @Test - firstTest > @Test - firstTest > @After > @After > ------------------------- > @Before > @Before > @Test - secondTest > @Test - secondTest > @After > @After > @Before > @Before > @Test - secondTest > @Test - secondTest > @After > @After > Note: > --------- > I tried without Drone -> same issue > I tried without RunAsClient and without Deployment -> same issue > The instance of the SampleTest Class is the same for each call of @Test method -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 14:11:00 2015 From: issues at jboss.org (Damien Vidal (JIRA)) Date: Thu, 24 Sep 2015 14:11:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1982) Each test case is launched 4 times In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Vidal updated ARQ-1982: ------------------------------ Environment: Bundle-ClassPath: ., lib/jbosgi-metadata-3.0.1.Final.jar, lib/arquillian-config-api-1.1.9.Final.jar, lib/arquillian-config-impl-base-1.1.9.Final.jar, lib/arquillian-container-impl-base-1.1.9.Final.jar, lib/arquillian-container-spi-1.1.9.Final.jar, lib/arquillian-container-test-api-1.1.9.Final.jar, lib/arquillian-container-test-impl-base-1.1.9.Final.jar, lib/arquillian-container-test-spi-1.1.9.Final.jar, lib/arquillian-core-api-1.1.9.Final.jar, lib/arquillian-core-impl-base-1.1.9.Final.jar, lib/arquillian-core-spi-1.1.9.Final.jar, lib/arquillian-drone-api-1.3.1.Final.jar, lib/arquillian-drone-configuration-1.3.1.Final.jar, lib/arquillian-drone-impl-1.3.1.Final.jar, lib/arquillian-drone-selenium-1.3.1.Final.jar, lib/arquillian-drone-selenium-server-1.3.1.Final.jar, lib/arquillian-drone-spi-1.3.1.Final.jar, lib/arquillian-drone-webdriver-1.3.1.Final.jar, lib/arquillian-junit-container-1.1.9.Final.jar, lib/arquillian-junit-core-1.1.9.Final.jar, lib/arquillian-junit-standalone-1.1.9.Final.jar, lib/arquillian-test-api-1.1.9.Final.jar, lib/arquillian-test-impl-base-1.1.9.Final.jar, lib/arquillian-test-spi-1.1.9.Final.jar, lib/arquillian-testenricher-cdi-1.1.5.Final.jar, lib/arquillian-testenricher-initialcontext-1.1.5.Final.jar, lib/arquillian-testenricher-resource-1.1.5.Final.jar, lib/arquillian-tomcat-embedded-6-1.0.0.CR7.jar, lib/jetty-rc-repacked-5.jar, lib/jetty-repacked-7.6.1.jar, lib/operadriver-1.1.jar, lib/operalaunchers-1.1.jar, lib/phantomjsdriver-1.1.0.jar, lib/selenium-api-2.47.1.jar, lib/selenium-chrome-driver-2.47.1.jar, lib/selenium-edge-driver-2.47.1.jar, lib/selenium-firefox-driver-2.47.1.jar, lib/selenium-htmlunit-driver-2.47.1.jar, lib/selenium-ie-driver-2.47.1.jar, lib/selenium-java-2.47.1.jar, lib/selenium-leg-rc-2.47.1.jar, lib/selenium-remote-driver-2.47.1.jar, lib/selenium-safari-driver-2.47.1.jar, lib/selenium-server-2.47.1.jar, lib/selenium-support-2.47.1.jar, lib/shrinkwrap-api-1.2.2.jar, lib/shrinkwrap-container-tomcat-60-1.0.0-beta-1.jar, lib/shrinkwrap-descriptors-api-base-2.0.0-alpha-7.jar, lib/shrinkwrap-descriptors-spi-2.0.0-alpha-7.jar, lib/shrinkwrap-impl-base-1.2.2.jar, lib/shrinkwrap-spi-1.2.2.jar, lib/jboss-logging-3.3.0.Final.jar, lib/httpclient-4.3.1.jar, lib/httpcore-4.3.jar, lib/httpmime-4.4.1.jar, lib/guava-19.0-rc1.jar, lib/gson-2.3.1.jar, lib/commons-exec-1.3.jar, lib/commons-lang3-3.4.jar > Each test case is launched 4 times > ---------------------------------- > > Key: ARQ-1982 > URL: https://issues.jboss.org/browse/ARQ-1982 > Project: Arquillian > Issue Type: Bug > Environment: Bundle-ClassPath: ., > lib/jbosgi-metadata-3.0.1.Final.jar, > lib/arquillian-config-api-1.1.9.Final.jar, > lib/arquillian-config-impl-base-1.1.9.Final.jar, > lib/arquillian-container-impl-base-1.1.9.Final.jar, > lib/arquillian-container-spi-1.1.9.Final.jar, > lib/arquillian-container-test-api-1.1.9.Final.jar, > lib/arquillian-container-test-impl-base-1.1.9.Final.jar, > lib/arquillian-container-test-spi-1.1.9.Final.jar, > lib/arquillian-core-api-1.1.9.Final.jar, > lib/arquillian-core-impl-base-1.1.9.Final.jar, > lib/arquillian-core-spi-1.1.9.Final.jar, > lib/arquillian-drone-api-1.3.1.Final.jar, > lib/arquillian-drone-configuration-1.3.1.Final.jar, > lib/arquillian-drone-impl-1.3.1.Final.jar, > lib/arquillian-drone-selenium-1.3.1.Final.jar, > lib/arquillian-drone-selenium-server-1.3.1.Final.jar, > lib/arquillian-drone-spi-1.3.1.Final.jar, > lib/arquillian-drone-webdriver-1.3.1.Final.jar, > lib/arquillian-junit-container-1.1.9.Final.jar, > lib/arquillian-junit-core-1.1.9.Final.jar, > lib/arquillian-junit-standalone-1.1.9.Final.jar, > lib/arquillian-test-api-1.1.9.Final.jar, > lib/arquillian-test-impl-base-1.1.9.Final.jar, > lib/arquillian-test-spi-1.1.9.Final.jar, > lib/arquillian-testenricher-cdi-1.1.5.Final.jar, > lib/arquillian-testenricher-initialcontext-1.1.5.Final.jar, > lib/arquillian-testenricher-resource-1.1.5.Final.jar, > lib/arquillian-tomcat-embedded-6-1.0.0.CR7.jar, > lib/jetty-rc-repacked-5.jar, > lib/jetty-repacked-7.6.1.jar, > lib/operadriver-1.1.jar, > lib/operalaunchers-1.1.jar, > lib/phantomjsdriver-1.1.0.jar, > lib/selenium-api-2.47.1.jar, > lib/selenium-chrome-driver-2.47.1.jar, > lib/selenium-edge-driver-2.47.1.jar, > lib/selenium-firefox-driver-2.47.1.jar, > lib/selenium-htmlunit-driver-2.47.1.jar, > lib/selenium-ie-driver-2.47.1.jar, > lib/selenium-java-2.47.1.jar, > lib/selenium-leg-rc-2.47.1.jar, > lib/selenium-remote-driver-2.47.1.jar, > lib/selenium-safari-driver-2.47.1.jar, > lib/selenium-server-2.47.1.jar, > lib/selenium-support-2.47.1.jar, > lib/shrinkwrap-api-1.2.2.jar, > lib/shrinkwrap-container-tomcat-60-1.0.0-beta-1.jar, > lib/shrinkwrap-descriptors-api-base-2.0.0-alpha-7.jar, > lib/shrinkwrap-descriptors-spi-2.0.0-alpha-7.jar, > lib/shrinkwrap-impl-base-1.2.2.jar, > lib/shrinkwrap-spi-1.2.2.jar, > lib/jboss-logging-3.3.0.Final.jar, > lib/httpclient-4.3.1.jar, > lib/httpcore-4.3.jar, > lib/httpmime-4.4.1.jar, > lib/guava-19.0-rc1.jar, > lib/gson-2.3.1.jar, > lib/commons-exec-1.3.jar, > lib/commons-lang3-3.4.jar > Reporter: Damien Vidal > Labels: Arquillian, OSGI > > Each test is called 4 times on the following orders. > @Before > @Before > @Test - firstTest > @Test - firstTest > @After > @After > @Before > @Before > @Test - firstTest > @Test - firstTest > @After > @After > ------------------------- > @Before > @Before > @Test - secondTest > @Test - secondTest > @After > @After > @Before > @Before > @Test - secondTest > @Test - secondTest > @After > @After > Note: > --------- > I tried without Drone -> same issue > I tried without RunAsClient and without Deployment -> same issue > The instance of the SampleTest Class is the same for each call of @Test method -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 14:14:00 2015 From: issues at jboss.org (Damien Vidal (JIRA)) Date: Thu, 24 Sep 2015 14:14:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1982) Each test case is launched 4 times in OSGi In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Vidal updated ARQ-1982: ------------------------------ Summary: Each test case is launched 4 times in OSGi (was: Each test case is launched 4 times) > Each test case is launched 4 times in OSGi > ------------------------------------------ > > Key: ARQ-1982 > URL: https://issues.jboss.org/browse/ARQ-1982 > Project: Arquillian > Issue Type: Bug > Environment: Bundle-ClassPath: ., > lib/jbosgi-metadata-3.0.1.Final.jar, > lib/arquillian-config-api-1.1.9.Final.jar, > lib/arquillian-config-impl-base-1.1.9.Final.jar, > lib/arquillian-container-impl-base-1.1.9.Final.jar, > lib/arquillian-container-spi-1.1.9.Final.jar, > lib/arquillian-container-test-api-1.1.9.Final.jar, > lib/arquillian-container-test-impl-base-1.1.9.Final.jar, > lib/arquillian-container-test-spi-1.1.9.Final.jar, > lib/arquillian-core-api-1.1.9.Final.jar, > lib/arquillian-core-impl-base-1.1.9.Final.jar, > lib/arquillian-core-spi-1.1.9.Final.jar, > lib/arquillian-drone-api-1.3.1.Final.jar, > lib/arquillian-drone-configuration-1.3.1.Final.jar, > lib/arquillian-drone-impl-1.3.1.Final.jar, > lib/arquillian-drone-selenium-1.3.1.Final.jar, > lib/arquillian-drone-selenium-server-1.3.1.Final.jar, > lib/arquillian-drone-spi-1.3.1.Final.jar, > lib/arquillian-drone-webdriver-1.3.1.Final.jar, > lib/arquillian-junit-container-1.1.9.Final.jar, > lib/arquillian-junit-core-1.1.9.Final.jar, > lib/arquillian-junit-standalone-1.1.9.Final.jar, > lib/arquillian-test-api-1.1.9.Final.jar, > lib/arquillian-test-impl-base-1.1.9.Final.jar, > lib/arquillian-test-spi-1.1.9.Final.jar, > lib/arquillian-testenricher-cdi-1.1.5.Final.jar, > lib/arquillian-testenricher-initialcontext-1.1.5.Final.jar, > lib/arquillian-testenricher-resource-1.1.5.Final.jar, > lib/arquillian-tomcat-embedded-6-1.0.0.CR7.jar, > lib/jetty-rc-repacked-5.jar, > lib/jetty-repacked-7.6.1.jar, > lib/operadriver-1.1.jar, > lib/operalaunchers-1.1.jar, > lib/phantomjsdriver-1.1.0.jar, > lib/selenium-api-2.47.1.jar, > lib/selenium-chrome-driver-2.47.1.jar, > lib/selenium-edge-driver-2.47.1.jar, > lib/selenium-firefox-driver-2.47.1.jar, > lib/selenium-htmlunit-driver-2.47.1.jar, > lib/selenium-ie-driver-2.47.1.jar, > lib/selenium-java-2.47.1.jar, > lib/selenium-leg-rc-2.47.1.jar, > lib/selenium-remote-driver-2.47.1.jar, > lib/selenium-safari-driver-2.47.1.jar, > lib/selenium-server-2.47.1.jar, > lib/selenium-support-2.47.1.jar, > lib/shrinkwrap-api-1.2.2.jar, > lib/shrinkwrap-container-tomcat-60-1.0.0-beta-1.jar, > lib/shrinkwrap-descriptors-api-base-2.0.0-alpha-7.jar, > lib/shrinkwrap-descriptors-spi-2.0.0-alpha-7.jar, > lib/shrinkwrap-impl-base-1.2.2.jar, > lib/shrinkwrap-spi-1.2.2.jar, > lib/jboss-logging-3.3.0.Final.jar, > lib/httpclient-4.3.1.jar, > lib/httpcore-4.3.jar, > lib/httpmime-4.4.1.jar, > lib/guava-19.0-rc1.jar, > lib/gson-2.3.1.jar, > lib/commons-exec-1.3.jar, > lib/commons-lang3-3.4.jar > Reporter: Damien Vidal > Labels: Arquillian, OSGI > > Each test is called 4 times on the following orders. > @Before > @Before > @Test - firstTest > @Test - firstTest > @After > @After > @Before > @Before > @Test - firstTest > @Test - firstTest > @After > @After > ------------------------- > @Before > @Before > @Test - secondTest > @Test - secondTest > @After > @After > @Before > @Before > @Test - secondTest > @Test - secondTest > @After > @After > Note: > --------- > I tried without Drone -> same issue > I tried without RunAsClient and without Deployment -> same issue > The instance of the SampleTest Class is the same for each call of @Test method -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 17:03:00 2015 From: issues at jboss.org (Michael Irwin (JIRA)) Date: Thu, 24 Sep 2015 17:03:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-478) Add support for multiple @InitialPage when using Qualifiers In-Reply-To: References: Message-ID: Michael Irwin created ARQGRA-478: ------------------------------------ Summary: Add support for multiple @InitialPage when using Qualifiers Key: ARQGRA-478 URL: https://issues.jboss.org/browse/ARQGRA-478 Project: Arquillian Graphene Issue Type: Enhancement Components: core Reporter: Michael Irwin If using multiple browsers in a test, it would be nice to support multiple @InitialPage parameters in the method, each with a separate qualifier. Obviously, if the same qualifier is applied to more than one @InitialPage, it should throw and prevent execution. Pull-request incoming... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 05:25:00 2015 From: issues at jboss.org (Luca Stancapiano (JIRA)) Date: Fri, 25 Sep 2015 05:25:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-286) Should support JUnit @Rules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112435#comment-13112435 ] Luca Stancapiano commented on ARQ-286: -------------------------------------- I added a test project here: https://github.com/flashboss/arquillian-rules But strangely it works different by I signaled. There are two tests that shows if the test work server side, one with a rule and one with a simple test. I will continue to verify if the problem is real > Should support JUnit @Rules > --------------------------- > > Key: ARQ-286 > URL: https://issues.jboss.org/browse/ARQ-286 > Project: Arquillian > Issue Type: Feature Request > Components: Test Harness Integration > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.5.Final > > > Using the JUnit feature @Rule becomes a problem when running against Remote servers since the @Rule is executed both on the Client and Container side. > It works fine in Embedded Containers since the Test is executed in the same VM, but if the Rule is dependent on Container features, the @Test will fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 05:38:00 2015 From: issues at jboss.org (Luca Stancapiano (JIRA)) Date: Fri, 25 Sep 2015 05:38:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-286) Should support JUnit @Rules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112440#comment-13112440 ] Luca Stancapiano commented on ARQ-286: -------------------------------------- In the rules.RuleTest, the rules.Container class is instantiate two times, the first client side and the second server side. I presume it is the correct achievement > Should support JUnit @Rules > --------------------------- > > Key: ARQ-286 > URL: https://issues.jboss.org/browse/ARQ-286 > Project: Arquillian > Issue Type: Feature Request > Components: Test Harness Integration > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.5.Final > > > Using the JUnit feature @Rule becomes a problem when running against Remote servers since the @Rule is executed both on the Client and Container side. > It works fine in Embedded Containers since the Test is executed in the same VM, but if the Rule is dependent on Container features, the @Test will fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:06:00 2015 From: issues at jboss.org (Luca Stancapiano (JIRA)) Date: Fri, 25 Sep 2015 06:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-286) Should support JUnit @Rules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112455#comment-13112455 ] Luca Stancapiano commented on ARQ-286: -------------------------------------- Ok I reproduced the problem I met. In the RuleTest there is a runtime exception that is throwed if the test is not in the server side, so the rules.Container class starts only once and my test fail. Only a question. Can I choose if run the test only in a mode instead of both leaving the exception inside the instantiation of the rule? I updated the git project with the issue > Should support JUnit @Rules > --------------------------- > > Key: ARQ-286 > URL: https://issues.jboss.org/browse/ARQ-286 > Project: Arquillian > Issue Type: Feature Request > Components: Test Harness Integration > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.5.Final > > > Using the JUnit feature @Rule becomes a problem when running against Remote servers since the @Rule is executed both on the Client and Container side. > It works fine in Embedded Containers since the Test is executed in the same VM, but if the Rule is dependent on Container features, the @Test will fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 12:38:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 25 Sep 2015 12:38:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-478) Add support for multiple @InitialPage when using Qualifiers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-478: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/136 > Add support for multiple @InitialPage when using Qualifiers > ----------------------------------------------------------- > > Key: ARQGRA-478 > URL: https://issues.jboss.org/browse/ARQGRA-478 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Reporter: Michael Irwin > > If using multiple browsers in a test, it would be nice to support multiple @InitialPage parameters in the method, each with a separate qualifier. > Obviously, if the same qualifier is applied to more than one @InitialPage, it should throw and prevent execution. > Pull-request incoming... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 12:38:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 25 Sep 2015 12:38:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-478) Add support for multiple @InitialPage when using Qualifiers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-478: --------------------------------- Assignee: Luk?? Fry? > Add support for multiple @InitialPage when using Qualifiers > ----------------------------------------------------------- > > Key: ARQGRA-478 > URL: https://issues.jboss.org/browse/ARQGRA-478 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Reporter: Michael Irwin > Assignee: Luk?? Fry? > > If using multiple browsers in a test, it would be nice to support multiple @InitialPage parameters in the method, each with a separate qualifier. > Obviously, if the same qualifier is applied to more than one @InitialPage, it should throw and prevent execution. > Pull-request incoming... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 12:40:01 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 25 Sep 2015 12:40:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-478) Add support for multiple @InitialPage when using Qualifiers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-478: --------------------------------- Assignee: Michael Irwin (was: Luk?? Fry?) > Add support for multiple @InitialPage when using Qualifiers > ----------------------------------------------------------- > > Key: ARQGRA-478 > URL: https://issues.jboss.org/browse/ARQGRA-478 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Reporter: Michael Irwin > Assignee: Michael Irwin > Fix For: 2.1-Tracking > > > If using multiple browsers in a test, it would be nice to support multiple @InitialPage parameters in the method, each with a separate qualifier. > Obviously, if the same qualifier is applied to more than one @InitialPage, it should throw and prevent execution. > Pull-request incoming... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 12:40:01 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 25 Sep 2015 12:40:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-478) Add support for multiple @InitialPage when using Qualifiers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-478: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 2.1-Tracking Resolution: Done > Add support for multiple @InitialPage when using Qualifiers > ----------------------------------------------------------- > > Key: ARQGRA-478 > URL: https://issues.jboss.org/browse/ARQGRA-478 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Reporter: Michael Irwin > Assignee: Michael Irwin > Fix For: 2.1-Tracking > > > If using multiple browsers in a test, it would be nice to support multiple @InitialPage parameters in the method, each with a separate qualifier. > Obviously, if the same qualifier is applied to more than one @InitialPage, it should throw and prevent execution. > Pull-request incoming... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 02:03:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 29 Sep 2015 02:03:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-479) Propagate xhr.response values in wrapper callback In-Reply-To: References: Message-ID: Luk?? Fry? created ARQGRA-479: --------------------------------- Summary: Propagate xhr.response values in wrapper callback Key: ARQGRA-479 URL: https://issues.jboss.org/browse/ARQGRA-479 Project: Arquillian Graphene Issue Type: Bug Reporter: Luk?? Fry? Assignee: Luk?? Fry? Fix For: 2.0-Tracking, 2.1-Tracking When the xhr wrapper is created the response property is copied but it isn't updated in the callback, which leads to the property values' being out of sync. Some frameworks (e.g. Angular) will use the xhr.response over xhr.responseText if it is present, which means that simply using a guardAjax in a Graphene test will cause all subsequent xhr calls to return invalid data. In my case (Firefox 38, Angular 1.4.4, Graphene 2.0.3.Final) all $http calls would return "" once a guardAjax was executed, despite valid data being shown in Firefox's request log. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 02:05:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 29 Sep 2015 02:05:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-479) Propagate xhr.response values in wrapper callback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-479: ------------------------------ Affects Version/s: 2.1.0.Alpha2 2.0.3.Final > Propagate xhr.response values in wrapper callback > ------------------------------------------------- > > Key: ARQGRA-479 > URL: https://issues.jboss.org/browse/ARQGRA-479 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: 2.0-Tracking, 2.1-Tracking > > > When the xhr wrapper is created the response property is copied but it isn't updated in the callback, which leads to the property values' being out of sync. Some frameworks (e.g. Angular) will use the xhr.response over xhr.responseText if it is present, which means that simply using a guardAjax in a Graphene test will cause all subsequent xhr calls to return invalid data. In my case (Firefox 38, Angular 1.4.4, Graphene 2.0.3.Final) all $http calls would return "" once a guardAjax was executed, despite valid data being shown in Firefox's request log. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 02:06:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 29 Sep 2015 02:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-479) Propagate xhr.response values in wrapper callback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-479: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/137, https://github.com/arquillian/arquillian-graphene/pull/138 > Propagate xhr.response values in wrapper callback > ------------------------------------------------- > > Key: ARQGRA-479 > URL: https://issues.jboss.org/browse/ARQGRA-479 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: 2.0-Tracking, 2.1-Tracking > > > When the xhr wrapper is created the response property is copied but it isn't updated in the callback, which leads to the property values' being out of sync. Some frameworks (e.g. Angular) will use the xhr.response over xhr.responseText if it is present, which means that simply using a guardAjax in a Graphene test will cause all subsequent xhr calls to return invalid data. In my case (Firefox 38, Angular 1.4.4, Graphene 2.0.3.Final) all $http calls would return "" once a guardAjax was executed, despite valid data being shown in Firefox's request log. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 02:25:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 29 Sep 2015 02:25:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-479) Propagate xhr.response values in wrapper callback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-479: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Propagate xhr.response values in wrapper callback > ------------------------------------------------- > > Key: ARQGRA-479 > URL: https://issues.jboss.org/browse/ARQGRA-479 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: 2.0-Tracking, 2.1-Tracking > > > When the xhr wrapper is created the response property is copied but it isn't updated in the callback, which leads to the property values' being out of sync. Some frameworks (e.g. Angular) will use the xhr.response over xhr.responseText if it is present, which means that simply using a guardAjax in a Graphene test will cause all subsequent xhr calls to return invalid data. In my case (Firefox 38, Angular 1.4.4, Graphene 2.0.3.Final) all $http calls would return "" once a guardAjax was executed, despite valid data being shown in Firefox's request log. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 02:49:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 29 Sep 2015 02:49:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1979) Screenshot is not taken when a test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-1979: ----------------------------------- Assignee: Matous Jobanek > Screenshot is not taken when a test fails > ----------------------------------------- > > Key: ARQ-1979 > URL: https://issues.jboss.org/browse/ARQ-1979 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > The cause: > There in the Arquillian-core 1.1.7.Final have been introduced new events: > {{AfterTestLifecycleEvent}} > {{BeforeTestLifecycleEvent}} > that replaces the behaviour of predecessors > {{After}} > {{Before}} > For more information see: > https://github.com/arquillian/arquillian-core/commit/606b4b29a3a561bc0ea6ed2f4883f7e37fa5153c > ARQ-1818 > This change is not reflected there in the arquillian-recorder project - this causes that the screenshot is not taken when test fails: > https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L96 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 02:53:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 29 Sep 2015 02:53:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1979) Screenshot is not taken when a test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-1979: -------------------------------- Description: The cause: There in the Arquillian-core 1.1.7.Final have been changed the workflow of events and the moment when the status of a test is set For more information see: https://github.com/arquillian/arquillian-core/commit/606b4b29a3a561bc0ea6ed2f4883f7e37fa5153c ARQ-1818 This change is not reflected there in the arquillian-recorder project - this causes that the screenshot is not taken when test fails: https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L96 was: The cause: There in the Arquillian-core 1.1.7.Final have been introduced new events: {{AfterTestLifecycleEvent}} {{BeforeTestLifecycleEvent}} that replaces the behaviour of predecessors {{After}} {{Before}} For more information see: https://github.com/arquillian/arquillian-core/commit/606b4b29a3a561bc0ea6ed2f4883f7e37fa5153c ARQ-1818 This change is not reflected there in the arquillian-recorder project - this causes that the screenshot is not taken when test fails: https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L96 > Screenshot is not taken when a test fails > ----------------------------------------- > > Key: ARQ-1979 > URL: https://issues.jboss.org/browse/ARQ-1979 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > The cause: > There in the Arquillian-core 1.1.7.Final have been changed the workflow of events and the moment when the status of a test is set > For more information see: > https://github.com/arquillian/arquillian-core/commit/606b4b29a3a561bc0ea6ed2f4883f7e37fa5153c > ARQ-1818 > This change is not reflected there in the arquillian-recorder project - this causes that the screenshot is not taken when test fails: > https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L96 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 04:06:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 29 Sep 2015 04:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1979) Screenshot is not taken when a test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113092#comment-13113092 ] Matous Jobanek commented on ARQ-1979: ------------------------------------- This causes also bug there in the video recorder component: When {{takeOnlyOnFail}} is set and the test fails, the stored file has wrong suffix: {{_passed}} instead of {{_failed}} > Screenshot is not taken when a test fails > ----------------------------------------- > > Key: ARQ-1979 > URL: https://issues.jboss.org/browse/ARQ-1979 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > The cause: > There in the Arquillian-core 1.1.7.Final have been changed the workflow of events and the moment when the status of a test is set > For more information see: > https://github.com/arquillian/arquillian-core/commit/606b4b29a3a561bc0ea6ed2f4883f7e37fa5153c > ARQ-1818 > This change is not reflected there in the arquillian-recorder project - this causes that the screenshot is not taken when test fails: > https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L96 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 06:30:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 29 Sep 2015 06:30:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1983) tomcat-embedded-8 unpackArchive property doesn't have any effect In-Reply-To: References: Message-ID: Tomas Remes created ARQ-1983: -------------------------------- Summary: tomcat-embedded-8 unpackArchive property doesn't have any effect Key: ARQ-1983 URL: https://issues.jboss.org/browse/ARQ-1983 Project: Arquillian Issue Type: Bug Components: Tomcat Containers Affects Versions: 1.0.0.CR7 Reporter: Tomas Remes This attribute is on class {{org.apache.catalina.core.StandardHost}} as well and {{org.apache.catalina.startup.HostConfig#lifecycleEvent}} uses this value therefore {{org.apache.catalina.startup.HostConfig#unpackWARs}} seems to have no effect. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 06:35:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 29 Sep 2015 06:35:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1983) tomcat-embedded-8 unpackArchive property doesn't have any effect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated ARQ-1983: ----------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-tomcat/pull/32 > tomcat-embedded-8 unpackArchive property doesn't have any effect > ---------------------------------------------------------------- > > Key: ARQ-1983 > URL: https://issues.jboss.org/browse/ARQ-1983 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: 1.0.0.CR7 > Reporter: Tomas Remes > > This attribute is on class {{org.apache.catalina.core.StandardHost}} as well and {{org.apache.catalina.startup.HostConfig#lifecycleEvent}} uses this value therefore {{org.apache.catalina.startup.HostConfig#unpackWARs}} seems to have no effect. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 30 06:17:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 30 Sep 2015 06:17:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1979) Screenshot is not taken when a test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113663#comment-13113663 ] Matous Jobanek commented on ARQ-1979: ------------------------------------- Pushed upstream in https://github.com/arquillian/arquillian-recorder/commit/8599a9715fb2d3a05331d08f9be1c2cdd0bde832 > Screenshot is not taken when a test fails > ----------------------------------------- > > Key: ARQ-1979 > URL: https://issues.jboss.org/browse/ARQ-1979 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > The cause: > There in the Arquillian-core 1.1.7.Final have been changed the workflow of events and the moment when the status of a test is set > For more information see: > https://github.com/arquillian/arquillian-core/commit/606b4b29a3a561bc0ea6ed2f4883f7e37fa5153c > ARQ-1818 > This change is not reflected there in the arquillian-recorder project - this causes that the screenshot is not taken when test fails: > https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L96 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 30 07:49:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 30 Sep 2015 07:49:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1984) Update version of ShrinkWrap Resolver to 2.2.0 In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-1984: ----------------------------------- Summary: Update version of ShrinkWrap Resolver to 2.2.0 Key: ARQ-1984 URL: https://issues.jboss.org/browse/ARQ-1984 Project: Arquillian Issue Type: Component Upgrade Components: Base Implementation Affects Versions: 1.1.9.Final Reporter: Matous Jobanek Update version of ShrinkWrap Resolver to 2.2.0 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 30 07:50:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 30 Sep 2015 07:50:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1984) Update version of ShrinkWrap Resolver to 2.2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-1984: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-core/pull/94 > Update version of ShrinkWrap Resolver to 2.2.0 > ---------------------------------------------- > > Key: ARQ-1984 > URL: https://issues.jboss.org/browse/ARQ-1984 > Project: Arquillian > Issue Type: Component Upgrade > Components: Base Implementation > Affects Versions: 1.1.9.Final > Reporter: Matous Jobanek > > Update version of ShrinkWrap Resolver to 2.2.0 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 30 09:19:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 30 Sep 2015 09:19:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1955) Screenshot not taken when eception occurs during @Before In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113769#comment-13113769 ] Matous Jobanek commented on ARQ-1955: ------------------------------------- Hi [~michbeck100], there cannot be taken the "_failed" screenshot during the @Before phase because there has not started any test case yet. So, this behaviour is correct. > Screenshot not taken when eception occurs during @Before > -------------------------------------------------------- > > Key: ARQ-1955 > URL: https://issues.jboss.org/browse/ARQ-1955 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Final > Reporter: Michael Kotten > > If a test fails with an exception during the @Before method, there is no screenshot taken, even with takeWhenTestFailed=true. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 30 18:45:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 30 Sep 2015 18:45:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1984) Update version of ShrinkWrap Resolver to 2.2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1984. -------------------------------- Fix Version/s: 1.2.0.Alpha1 Resolution: Done > Update version of ShrinkWrap Resolver to 2.2.0 > ---------------------------------------------- > > Key: ARQ-1984 > URL: https://issues.jboss.org/browse/ARQ-1984 > Project: Arquillian > Issue Type: Component Upgrade > Components: Base Implementation > Affects Versions: 1.1.9.Final > Reporter: Matous Jobanek > Fix For: 1.2.0.Alpha1 > > > Update version of ShrinkWrap Resolver to 2.2.0 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 30 18:46:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 30 Sep 2015 18:46:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1985) Update version of ShrinkWrap Descriptor to 2.0.0-alpha-8 In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1985: ---------------------------------- Summary: Update version of ShrinkWrap Descriptor to 2.0.0-alpha-8 Key: ARQ-1985 URL: https://issues.jboss.org/browse/ARQ-1985 Project: Arquillian Issue Type: Component Upgrade Components: Base Implementation Affects Versions: 1.1.9.Final Reporter: Aslak Knutsen Fix For: 1.2.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 30 18:48:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 30 Sep 2015 18:48:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1985) Update version of ShrinkWrap Descriptor to 2.0.0-alpha-8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1985. -------------------------------- Resolution: Done > Update version of ShrinkWrap Descriptor to 2.0.0-alpha-8 > -------------------------------------------------------- > > Key: ARQ-1985 > URL: https://issues.jboss.org/browse/ARQ-1985 > Project: Arquillian > Issue Type: Component Upgrade > Components: Base Implementation > Affects Versions: 1.1.9.Final > Reporter: Aslak Knutsen > Fix For: 1.2.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)