From issues at jboss.org Mon Sep 1 10:11:01 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 1 Sep 2014 10:11:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-86) Support XHR Halter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-86: -------------------------------- Assignee: Luk?? Fry? (was: Juraj H?ska) > Support XHR Halter > ------------------ > > Key: ARQGRA-86 > URL: https://issues.jboss.org/browse/ARQGRA-86 > Project: Arquillian Graphene > Issue Type: Epic > Security Level: Public(Everyone can see) > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: 2.1.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 10:11:03 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 1 Sep 2014 10:11:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-86) Support XHR Halter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQGRA-86 started by Luk?? Fry?. ---------------------------------------- > Support XHR Halter > ------------------ > > Key: ARQGRA-86 > URL: https://issues.jboss.org/browse/ARQGRA-86 > Project: Arquillian Graphene > Issue Type: Epic > Security Level: Public(Everyone can see) > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: 2.1.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 11:04:00 2014 From: issues at jboss.org (Razvan Petre (JIRA)) Date: Mon, 1 Sep 2014 11:04:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1844) Warp does not work with Primefaces 5.0 In-Reply-To: References: Message-ID: Razvan Petre created ARQ-1844: --------------------------------- Summary: Warp does not work with Primefaces 5.0 Key: ARQ-1844 URL: https://issues.jboss.org/browse/ARQ-1844 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Warp Affects Versions: warp_1.0.0.Alpha5 Reporter: Razvan Petre hi all, I am using Mojarra 2.1.6, Glassfish 3.1.2 and Primefaces 5.0. All my tests used to run with Primefaces 3.5 but after upgrade ALL the tests fail with the same issue. Your help will be much appreciated. thank you! -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 11:04:01 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 1 Sep 2014 11:04:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-86) Support XHR Halter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997491#comment-12997491 ] Luk?? Fry? commented on ARQGRA-86: ---------------------------------- Integration tests fail on: {code} Results : Failed tests: TestAjaxHalter.testFoo:82 expected: but was: Tests run: 282, Failures: 1, Errors: 0, Skipped: 0 {code} I believe that this a differente between Firefox (which I was testing on) and PhantomJS (used to run integration tests). > Support XHR Halter > ------------------ > > Key: ARQGRA-86 > URL: https://issues.jboss.org/browse/ARQGRA-86 > Project: Arquillian Graphene > Issue Type: Epic > Security Level: Public(Everyone can see) > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: 2.1.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 11:04:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 1 Sep 2014 11:04:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-86) Support XHR Halter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-86: ----------------------------- Assignee: Juraj H?ska (was: Luk?? Fry?) > Support XHR Halter > ------------------ > > Key: ARQGRA-86 > URL: https://issues.jboss.org/browse/ARQGRA-86 > Project: Arquillian Graphene > Issue Type: Epic > Security Level: Public(Everyone can see) > Reporter: Luk?? Fry? > Assignee: Juraj H?ska > Fix For: 2.1.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 03:31:01 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 2 Sep 2014 03:31:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1844) Warp does not work with Primefaces 5.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1844: ---------------------------- Steps to Reproduce: (was: 25.08.2014 16:16:15 com.sun.faces.config.ConfigureListener contextInitialized INFO: Mojarra 2.1.6 (SNAPSHOT 20111206) f?r Kontext '/fdsi' wird initialisiert. 25.08.2014 16:16:19 org.primefaces.webapp.PostConstructApplicationEventListener processEvent INFO: Running on PrimeFaces 5.0 25.08.2014 16:16:19 com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor$Monitor INFO: Monitoring jndi:/server/fdsi/WEB-INF/faces-config.xml for modifications 25.08.2014 16:16:19 com.sun.enterprise.web.WebApplication start INFO: WEB0671: Loading application [fdsi] at [/fdsi] 25.08.2014 16:16:19 org.glassfish.deployment.admin.DeployCommand execute INFO: fdsi was successfully deployed in 32'101 milliseconds. 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity WARNING: Public field 'selenium' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity WARNING: Public field 'browser' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity WARNING: Public field 'deploymentUrl' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. Started InternetExplorerDriver server (64-bit) 2.39.0.0 Listening on port 36044 *** Opening URL: http://10.21.97.222:18080/fdsi/pages/testGui/setupTestData.xhtml?testName=canShowProgressDetails&racfRole=ADMIN_USERS&userRole=INTERFACE_ADMIN 25.08.2014 16:16:23 com.swissre.g3m.fdsi.internal.jsf.FacesExceptionHandlerWrapper handle SEVERE: General error for: TSTUSR View Id was: /pages/testGui/setupTestData.xhtml Throwable occurred: java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:70) at org.jboss.arquillian.warp.jsf.WarpPhaseListener.beforePhase(WarpPhaseListener.java:38) at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) at org.jboss.arquillian.warp.impl.server.execution.WarpLifecycle.execute(WarpLifecycle.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.warp.impl.server.execution.WarpRequestProcessor.processWarpRequest(WarpRequestProcessor.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.warp.impl.server.execution.HttpRequestProcessor.processHttpRequest(HttpRequestProcessor.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:144) at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:117) at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:90) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:738) Caused by: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.obtain(LifecycleManagerStoreImpl.java:63) at org.jboss.arquillian.warp.spi.LifecycleManagerStore.get(LifecycleManagerStore.java:69) at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:67) ... 69 more) > Warp does not work with Primefaces 5.0 > --------------------------------------- > > Key: ARQ-1844 > URL: https://issues.jboss.org/browse/ARQ-1844 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha5 > Reporter: Razvan Petre > > hi all, > I am using Mojarra 2.1.6, Glassfish 3.1.2 and Primefaces 5.0. All my tests used to run with Primefaces 3.5 but after upgrade ALL the tests fail with the same issue. > Your help will be much appreciated. > thank you! -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 03:31:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 2 Sep 2014 03:31:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1844) Warp does not work with Primefaces 5.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1844: ---------------------------- Description: I am using Mojarra 2.1.6, Glassfish 3.1.2 and Primefaces 5.0. All my tests used to run with Primefaces 3.5 but after upgrade ALL the tests fail with the same issue. {code} 25.08.2014 16:16:15 com.sun.faces.config.ConfigureListener contextInitialized INFO: Mojarra 2.1.6 (SNAPSHOT 20111206) f?r Kontext '/fdsi' wird initialisiert. 25.08.2014 16:16:19 org.primefaces.webapp.PostConstructApplicationEventListener processEvent INFO: Running on PrimeFaces 5.0 25.08.2014 16:16:19 com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor$Monitor INFO: Monitoring jndi:/server/fdsi/WEB-INF/faces-config.xml for modifications 25.08.2014 16:16:19 com.sun.enterprise.web.WebApplication start INFO: WEB0671: Loading application [fdsi] at [/fdsi] 25.08.2014 16:16:19 org.glassfish.deployment.admin.DeployCommand execute INFO: fdsi was successfully deployed in 32'101 milliseconds. 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity WARNING: Public field 'selenium' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity WARNING: Public field 'browser' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity WARNING: Public field 'deploymentUrl' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. Started InternetExplorerDriver server (64-bit) 2.39.0.0 Listening on port 36044 *** Opening URL: http://10.21.97.222:18080/fdsi/pages/testGui/setupTestData.xhtml?testName=canShowProgressDetails&racfRole=ADMIN_USERS&userRole=INTERFACE_ADMIN 25.08.2014 16:16:23 com.swissre.g3m.fdsi.internal.jsf.FacesExceptionHandlerWrapper handle SEVERE: General error for: TSTUSR View Id was: /pages/testGui/setupTestData.xhtml Throwable occurred: java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:70) at org.jboss.arquillian.warp.jsf.WarpPhaseListener.beforePhase(WarpPhaseListener.java:38) at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) at org.jboss.arquillian.warp.impl.server.execution.WarpLifecycle.execute(WarpLifecycle.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.warp.impl.server.execution.WarpRequestProcessor.processWarpRequest(WarpRequestProcessor.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.warp.impl.server.execution.HttpRequestProcessor.processHttpRequest(HttpRequestProcessor.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:144) at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:117) at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:90) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:738) Caused by: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.obtain(LifecycleManagerStoreImpl.java:63) at org.jboss.arquillian.warp.spi.LifecycleManagerStore.get(LifecycleManagerStore.java:69) at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:67) ... 69 more {code} was: hi all, I am using Mojarra 2.1.6, Glassfish 3.1.2 and Primefaces 5.0. All my tests used to run with Primefaces 3.5 but after upgrade ALL the tests fail with the same issue. Your help will be much appreciated. thank you! > Warp does not work with Primefaces 5.0 > --------------------------------------- > > Key: ARQ-1844 > URL: https://issues.jboss.org/browse/ARQ-1844 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha5 > Reporter: Razvan Petre > > I am using Mojarra 2.1.6, Glassfish 3.1.2 and Primefaces 5.0. > All my tests used to run with Primefaces 3.5 but after upgrade ALL the tests fail with the same issue. > {code} > 25.08.2014 16:16:15 com.sun.faces.config.ConfigureListener contextInitialized > INFO: Mojarra 2.1.6 (SNAPSHOT 20111206) f?r Kontext '/fdsi' wird initialisiert. > 25.08.2014 16:16:19 org.primefaces.webapp.PostConstructApplicationEventListener processEvent > INFO: Running on PrimeFaces 5.0 > 25.08.2014 16:16:19 com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor$Monitor > INFO: Monitoring jndi:/server/fdsi/WEB-INF/faces-config.xml for modifications > 25.08.2014 16:16:19 com.sun.enterprise.web.WebApplication start > INFO: WEB0671: Loading application [fdsi] at [/fdsi] > 25.08.2014 16:16:19 org.glassfish.deployment.admin.DeployCommand execute > INFO: fdsi was successfully deployed in 32'101 milliseconds. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'selenium' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'browser' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'deploymentUrl' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > Started InternetExplorerDriver server (64-bit) > 2.39.0.0 > Listening on port 36044 > *** Opening URL: http://10.21.97.222:18080/fdsi/pages/testGui/setupTestData.xhtml?testName=canShowProgressDetails&racfRole=ADMIN_USERS&userRole=INTERFACE_ADMIN > 25.08.2014 16:16:23 com.swissre.g3m.fdsi.internal.jsf.FacesExceptionHandlerWrapper handle > SEVERE: General error for: TSTUSR View Id was: /pages/testGui/setupTestData.xhtml > Throwable occurred: java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:70) > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.beforePhase(WarpPhaseListener.java:38) > at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) > at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) > at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) > at org.jboss.arquillian.warp.impl.server.execution.WarpLifecycle.execute(WarpLifecycle.java:77) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.execution.WarpRequestProcessor.processWarpRequest(WarpRequestProcessor.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.execution.HttpRequestProcessor.processHttpRequest(HttpRequestProcessor.java:70) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:144) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:117) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:90) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) > at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) > at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) > at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) > at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) > at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) > at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) > at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) > at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) > at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) > at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) > at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) > at com.sun.grizzly.ContextTask.run(ContextTask.java:71) > at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) > at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) > at java.lang.Thread.run(Thread.java:738) > Caused by: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.obtain(LifecycleManagerStoreImpl.java:63) > at org.jboss.arquillian.warp.spi.LifecycleManagerStore.get(LifecycleManagerStore.java:69) > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:67) > ... 69 more > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 03:31:59 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 2 Sep 2014 03:31:59 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1844) Warp does not work with Primefaces 5.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997652#comment-12997652 ] Luk?? Fry? commented on ARQ-1844: --------------------------------- Hello Razvan, have you tried with Warp 1.0.0.Alpha7? > Warp does not work with Primefaces 5.0 > --------------------------------------- > > Key: ARQ-1844 > URL: https://issues.jboss.org/browse/ARQ-1844 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha5 > Reporter: Razvan Petre > > I am using Mojarra 2.1.6, Glassfish 3.1.2 and Primefaces 5.0. > All my tests used to run with Primefaces 3.5 but after upgrade ALL the tests fail with the same issue. > {code} > 25.08.2014 16:16:15 com.sun.faces.config.ConfigureListener contextInitialized > INFO: Mojarra 2.1.6 (SNAPSHOT 20111206) f?r Kontext '/fdsi' wird initialisiert. > 25.08.2014 16:16:19 org.primefaces.webapp.PostConstructApplicationEventListener processEvent > INFO: Running on PrimeFaces 5.0 > 25.08.2014 16:16:19 com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor$Monitor > INFO: Monitoring jndi:/server/fdsi/WEB-INF/faces-config.xml for modifications > 25.08.2014 16:16:19 com.sun.enterprise.web.WebApplication start > INFO: WEB0671: Loading application [fdsi] at [/fdsi] > 25.08.2014 16:16:19 org.glassfish.deployment.admin.DeployCommand execute > INFO: fdsi was successfully deployed in 32'101 milliseconds. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'selenium' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'browser' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'deploymentUrl' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > Started InternetExplorerDriver server (64-bit) > 2.39.0.0 > Listening on port 36044 > *** Opening URL: http://10.21.97.222:18080/fdsi/pages/testGui/setupTestData.xhtml?testName=canShowProgressDetails&racfRole=ADMIN_USERS&userRole=INTERFACE_ADMIN > 25.08.2014 16:16:23 com.swissre.g3m.fdsi.internal.jsf.FacesExceptionHandlerWrapper handle > SEVERE: General error for: TSTUSR View Id was: /pages/testGui/setupTestData.xhtml > Throwable occurred: java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:70) > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.beforePhase(WarpPhaseListener.java:38) > at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) > at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) > at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) > at org.jboss.arquillian.warp.impl.server.execution.WarpLifecycle.execute(WarpLifecycle.java:77) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.execution.WarpRequestProcessor.processWarpRequest(WarpRequestProcessor.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.execution.HttpRequestProcessor.processHttpRequest(HttpRequestProcessor.java:70) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:144) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:117) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:90) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) > at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) > at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) > at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) > at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) > at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) > at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) > at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) > at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) > at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) > at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) > at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) > at com.sun.grizzly.ContextTask.run(ContextTask.java:71) > at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) > at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) > at java.lang.Thread.run(Thread.java:738) > Caused by: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.obtain(LifecycleManagerStoreImpl.java:63) > at org.jboss.arquillian.warp.spi.LifecycleManagerStore.get(LifecycleManagerStore.java:69) > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:67) > ... 69 more > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 08:25:00 2014 From: issues at jboss.org (Razvan Petre (JIRA)) Date: Tue, 2 Sep 2014 08:25:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1844) Warp does not work with Primefaces 5.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997763#comment-12997763 ] Razvan Petre commented on ARQ-1844: ----------------------------------- hi Lukas, yes, I have tried with 1.0.0.Alpha7, but I ran into a RuntimeException when is trying to figure out the localhost address (i think warp is using a java 7 class) - i am using java 6 and upgrading to java 7 in not an option atm. however, I have found a workaround ... copied the lines i have found in the warp jsp library to my test faces-config.xml and it is now working... i do not understand why it was working with Primefaces 3.5.. these are the 'magic' lines: {code} org.jboss.arquillian.warp.jsf.WarpPhaseListener org.jboss.arquillian.warp.jsf.FacesContextFactoryWrapper {code} > Warp does not work with Primefaces 5.0 > --------------------------------------- > > Key: ARQ-1844 > URL: https://issues.jboss.org/browse/ARQ-1844 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha5 > Reporter: Razvan Petre > > I am using Mojarra 2.1.6, Glassfish 3.1.2 and Primefaces 5.0. > All my tests used to run with Primefaces 3.5 but after upgrade ALL the tests fail with the same issue. > {code} > 25.08.2014 16:16:15 com.sun.faces.config.ConfigureListener contextInitialized > INFO: Mojarra 2.1.6 (SNAPSHOT 20111206) f?r Kontext '/fdsi' wird initialisiert. > 25.08.2014 16:16:19 org.primefaces.webapp.PostConstructApplicationEventListener processEvent > INFO: Running on PrimeFaces 5.0 > 25.08.2014 16:16:19 com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor$Monitor > INFO: Monitoring jndi:/server/fdsi/WEB-INF/faces-config.xml for modifications > 25.08.2014 16:16:19 com.sun.enterprise.web.WebApplication start > INFO: WEB0671: Loading application [fdsi] at [/fdsi] > 25.08.2014 16:16:19 org.glassfish.deployment.admin.DeployCommand execute > INFO: fdsi was successfully deployed in 32'101 milliseconds. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'selenium' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'browser' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'deploymentUrl' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > Started InternetExplorerDriver server (64-bit) > 2.39.0.0 > Listening on port 36044 > *** Opening URL: http://10.21.97.222:18080/fdsi/pages/testGui/setupTestData.xhtml?testName=canShowProgressDetails&racfRole=ADMIN_USERS&userRole=INTERFACE_ADMIN > 25.08.2014 16:16:23 com.swissre.g3m.fdsi.internal.jsf.FacesExceptionHandlerWrapper handle > SEVERE: General error for: TSTUSR View Id was: /pages/testGui/setupTestData.xhtml > Throwable occurred: java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:70) > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.beforePhase(WarpPhaseListener.java:38) > at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) > at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) > at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) > at org.jboss.arquillian.warp.impl.server.execution.WarpLifecycle.execute(WarpLifecycle.java:77) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.execution.WarpRequestProcessor.processWarpRequest(WarpRequestProcessor.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.execution.HttpRequestProcessor.processHttpRequest(HttpRequestProcessor.java:70) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:144) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:117) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:90) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) > at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) > at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) > at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) > at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) > at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) > at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) > at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) > at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) > at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) > at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) > at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) > at com.sun.grizzly.ContextTask.run(ContextTask.java:71) > at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) > at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) > at java.lang.Thread.run(Thread.java:738) > Caused by: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.obtain(LifecycleManagerStoreImpl.java:63) > at org.jboss.arquillian.warp.spi.LifecycleManagerStore.get(LifecycleManagerStore.java:69) > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:67) > ... 69 more > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 08:26:00 2014 From: issues at jboss.org (Razvan Petre (JIRA)) Date: Tue, 2 Sep 2014 08:26:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1844) Warp does not work with Primefaces 5.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997763#comment-12997763 ] Razvan Petre edited comment on ARQ-1844 at 9/2/14 8:25 AM: ----------------------------------------------------------- hi Lukas, yes, I have tried with 1.0.0.Alpha7, but I ran into a RuntimeException when is trying to figure out the localhost address (i think warp is using a java 7 class) - i am using java 6 and upgrading to java 7 in not an option atm. however, I have found a workaround ... copied the lines i have found in the warp jsf library to my test faces-config.xml and it is now working... i do not understand why it was working with Primefaces 3.5.. these are the 'magic' lines: {code} org.jboss.arquillian.warp.jsf.WarpPhaseListener org.jboss.arquillian.warp.jsf.FacesContextFactoryWrapper {code} was (Author: razvanpetre): hi Lukas, yes, I have tried with 1.0.0.Alpha7, but I ran into a RuntimeException when is trying to figure out the localhost address (i think warp is using a java 7 class) - i am using java 6 and upgrading to java 7 in not an option atm. however, I have found a workaround ... copied the lines i have found in the warp jsp library to my test faces-config.xml and it is now working... i do not understand why it was working with Primefaces 3.5.. these are the 'magic' lines: {code} org.jboss.arquillian.warp.jsf.WarpPhaseListener org.jboss.arquillian.warp.jsf.FacesContextFactoryWrapper {code} > Warp does not work with Primefaces 5.0 > --------------------------------------- > > Key: ARQ-1844 > URL: https://issues.jboss.org/browse/ARQ-1844 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha5 > Reporter: Razvan Petre > > I am using Mojarra 2.1.6, Glassfish 3.1.2 and Primefaces 5.0. > All my tests used to run with Primefaces 3.5 but after upgrade ALL the tests fail with the same issue. > {code} > 25.08.2014 16:16:15 com.sun.faces.config.ConfigureListener contextInitialized > INFO: Mojarra 2.1.6 (SNAPSHOT 20111206) f?r Kontext '/fdsi' wird initialisiert. > 25.08.2014 16:16:19 org.primefaces.webapp.PostConstructApplicationEventListener processEvent > INFO: Running on PrimeFaces 5.0 > 25.08.2014 16:16:19 com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor$Monitor > INFO: Monitoring jndi:/server/fdsi/WEB-INF/faces-config.xml for modifications > 25.08.2014 16:16:19 com.sun.enterprise.web.WebApplication start > INFO: WEB0671: Loading application [fdsi] at [/fdsi] > 25.08.2014 16:16:19 org.glassfish.deployment.admin.DeployCommand execute > INFO: fdsi was successfully deployed in 32'101 milliseconds. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'selenium' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'browser' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'deploymentUrl' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > Started InternetExplorerDriver server (64-bit) > 2.39.0.0 > Listening on port 36044 > *** Opening URL: http://10.21.97.222:18080/fdsi/pages/testGui/setupTestData.xhtml?testName=canShowProgressDetails&racfRole=ADMIN_USERS&userRole=INTERFACE_ADMIN > 25.08.2014 16:16:23 com.swissre.g3m.fdsi.internal.jsf.FacesExceptionHandlerWrapper handle > SEVERE: General error for: TSTUSR View Id was: /pages/testGui/setupTestData.xhtml > Throwable occurred: java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:70) > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.beforePhase(WarpPhaseListener.java:38) > at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) > at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) > at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) > at org.jboss.arquillian.warp.impl.server.execution.WarpLifecycle.execute(WarpLifecycle.java:77) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.execution.WarpRequestProcessor.processWarpRequest(WarpRequestProcessor.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.execution.HttpRequestProcessor.processHttpRequest(HttpRequestProcessor.java:70) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:144) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:117) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:90) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) > at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) > at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) > at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) > at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) > at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) > at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) > at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) > at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) > at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) > at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) > at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) > at com.sun.grizzly.ContextTask.run(ContextTask.java:71) > at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) > at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) > at java.lang.Thread.run(Thread.java:738) > Caused by: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.obtain(LifecycleManagerStoreImpl.java:63) > at org.jboss.arquillian.warp.spi.LifecycleManagerStore.get(LifecycleManagerStore.java:69) > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:67) > ... 69 more > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 02:11:00 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 3 Sep 2014 02:11:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1844) Warp does not work with Primefaces 5.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998178#comment-12998178 ] Luk?? Fry? commented on ARQ-1844: --------------------------------- Thanks for the info about the workaround, Razvan, that certainly helps! With connection to your workaround, I'd guess Warp and PrimeFaces {{FacesContextWrapper}}s do not cooperate, just can't see where that happen from the code. https://github.com/primefaces/primefaces/blob/master/src/main/java/org/primefaces/context/PrimeFacesContextFactory.java https://github.com/arquillian/arquillian-extension-warp/blob/master/extension/jsf/src/main/java/org/jboss/arquillian/warp/jsf/FacesContextFactory.java We will need to debug this. :-) > Warp does not work with Primefaces 5.0 > --------------------------------------- > > Key: ARQ-1844 > URL: https://issues.jboss.org/browse/ARQ-1844 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha5 > Reporter: Razvan Petre > > I am using Mojarra 2.1.6, Glassfish 3.1.2 and Primefaces 5.0. > All my tests used to run with Primefaces 3.5 but after upgrade ALL the tests fail with the same issue. > {code} > 25.08.2014 16:16:15 com.sun.faces.config.ConfigureListener contextInitialized > INFO: Mojarra 2.1.6 (SNAPSHOT 20111206) f?r Kontext '/fdsi' wird initialisiert. > 25.08.2014 16:16:19 org.primefaces.webapp.PostConstructApplicationEventListener processEvent > INFO: Running on PrimeFaces 5.0 > 25.08.2014 16:16:19 com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor$Monitor > INFO: Monitoring jndi:/server/fdsi/WEB-INF/faces-config.xml for modifications > 25.08.2014 16:16:19 com.sun.enterprise.web.WebApplication start > INFO: WEB0671: Loading application [fdsi] at [/fdsi] > 25.08.2014 16:16:19 org.glassfish.deployment.admin.DeployCommand execute > INFO: fdsi was successfully deployed in 32'101 milliseconds. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'selenium' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'browser' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > 25.08.2014 16:16:20 org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field 'deploymentUrl' found in com.swissre.g3m.fdsi.gui.RunDetailsPageTest. Direct access to fields outside of the declaring class is not allowed. > Started InternetExplorerDriver server (64-bit) > 2.39.0.0 > Listening on port 36044 > *** Opening URL: http://10.21.97.222:18080/fdsi/pages/testGui/setupTestData.xhtml?testName=canShowProgressDetails&racfRole=ADMIN_USERS&userRole=INTERFACE_ADMIN > 25.08.2014 16:16:23 com.swissre.g3m.fdsi.internal.jsf.FacesExceptionHandlerWrapper handle > SEVERE: General error for: TSTUSR View Id was: /pages/testGui/setupTestData.xhtml > Throwable occurred: java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:70) > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.beforePhase(WarpPhaseListener.java:38) > at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) > at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) > at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) > at org.jboss.arquillian.warp.impl.server.execution.WarpLifecycle.execute(WarpLifecycle.java:77) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.execution.WarpRequestProcessor.processWarpRequest(WarpRequestProcessor.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.execution.HttpRequestProcessor.processHttpRequest(HttpRequestProcessor.java:70) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:144) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:117) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:90) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) > at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) > at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) > at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) > at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) > at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) > at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) > at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) > at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) > at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) > at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) > at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) > at com.sun.grizzly.ContextTask.run(ContextTask.java:71) > at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) > at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) > at java.lang.Thread.run(Thread.java:738) > Caused by: org.jboss.arquillian.warp.spi.exception.ObjectNotAssociatedException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.obtain(LifecycleManagerStoreImpl.java:63) > at org.jboss.arquillian.warp.spi.LifecycleManagerStore.get(LifecycleManagerStore.java:69) > at org.jboss.arquillian.warp.jsf.WarpPhaseListener.executeEvents(WarpPhaseListener.java:67) > ... 69 more > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 13:53:00 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Wed, 3 Sep 2014 13:53:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1815) Unable to locate Oracle Sequence filter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1815 started by Bartosz Majsak. ------------------------------------------- > Unable to locate Oracle Sequence filter > --------------------------------------- > > Key: ARQ-1815 > URL: https://issues.jboss.org/browse/ARQ-1815 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Priority: Blocker > Fix For: persistence_1.0.0.next > > > When trying to define custom table filter using > {{org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider}} > It's resulting in > {{Unable to find sequence filter for org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider. Using default database sequence filter.}} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 13:53:00 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Wed, 3 Sep 2014 13:53:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1815) Unable to locate Oracle Sequence filter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1815 stopped by Bartosz Majsak. ------------------------------------------- > Unable to locate Oracle Sequence filter > --------------------------------------- > > Key: ARQ-1815 > URL: https://issues.jboss.org/browse/ARQ-1815 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Priority: Blocker > Fix For: persistence_1.0.0.next > > > When trying to define custom table filter using > {{org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider}} > It's resulting in > {{Unable to find sequence filter for org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider. Using default database sequence filter.}} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 13:54:00 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Wed, 3 Sep 2014 13:54:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1809) @ShouldMatchDataSet is broken when ordering by non-string columns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1809 started by Bartosz Majsak. ------------------------------------------- > @ShouldMatchDataSet is broken when ordering by non-string columns > ----------------------------------------------------------------- > > Key: ARQ-1809 > URL: https://issues.jboss.org/browse/ARQ-1809 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Steven Dodd > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > Steps to reproduce: > 1. Create a table, "test", with a single column, an integer primary key, "id". > 2. Try the following test case under the persistence extension: > {code} > @UsingDataSet({test.yml}) > @ShouldMatchDataSet(value={test.yml}) > @Test > public void test() { > // do nothing > } > {code} > {code:title=test.yml} > test: > - id: -1 > - id: -2 > {code} > Result: test fails like so: > {code} > java.lang.AssertionError: Test failed in 2 cases. > test | In row 0: expected value of id "-1" but was "-2". > test | In row 1: expected value of id "-2" but was "-1". > {code} > Reason: > The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN. > The actual dataset is loaded by , and has all of its column types set to their actual types in the database. > DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison. > SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above. > As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results. > Suggested Fix: > The expected dataset needs to have accurate column types assigned, not UNKNOWN. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 19:18:59 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Wed, 3 Sep 2014 19:18:59 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1809) @ShouldMatchDataSet is broken when ordering by non-string columns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998606#comment-12998606 ] Bartosz Majsak commented on ARQ-1809: ------------------------------------- I cannot reproduce this behaviour, but I have improved sorted and filtered sets so that they have now proper metadata. As for the suggested fix : both YAML and JSON implementation are based on FlatXML data sets, where datatype is also set to unknown. If I understand DBUnit right, the real types are then extracted from underlying db and conversion is applied. But this might be wrong reasoning :) I will take a closer look. In the meantime, could you try to run your test against [latest master|https://github.com/arquillian/arquillian-extension-persistence] and let me know? Does this error occurs each and every time you run the test? > @ShouldMatchDataSet is broken when ordering by non-string columns > ----------------------------------------------------------------- > > Key: ARQ-1809 > URL: https://issues.jboss.org/browse/ARQ-1809 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Steven Dodd > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > Steps to reproduce: > 1. Create a table, "test", with a single column, an integer primary key, "id". > 2. Try the following test case under the persistence extension: > {code} > @UsingDataSet({test.yml}) > @ShouldMatchDataSet(value={test.yml}) > @Test > public void test() { > // do nothing > } > {code} > {code:title=test.yml} > test: > - id: -1 > - id: -2 > {code} > Result: test fails like so: > {code} > java.lang.AssertionError: Test failed in 2 cases. > test | In row 0: expected value of id "-1" but was "-2". > test | In row 1: expected value of id "-2" but was "-1". > {code} > Reason: > The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN. > The actual dataset is loaded by , and has all of its column types set to their actual types in the database. > DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison. > SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above. > As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results. > Suggested Fix: > The expected dataset needs to have accurate column types assigned, not UNKNOWN. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 08:40:01 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 4 Sep 2014 08:40:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1830) Only the last Test Class of some subset of Test classes is reported with TestNG runner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998856#comment-12998856 ] Juraj H?ska commented on ARQ-1830: ---------------------------------- I tried to reproduce this with different Arquillian core versions, but I did not found a suitable testng based test suite to try it, and isolate it. Well I can create a one, but as I do not suppose this as critical, I would devote some time to this once somebody requests it. > Only the last Test Class of some subset of Test classes is reported with TestNG runner > -------------------------------------------------------------------------------------- > > Key: ARQ-1830 > URL: https://issues.jboss.org/browse/ARQ-1830 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Alpha4 > Reporter: Juraj H?ska > > When you have TestNG test suite, after running some *subset* of all test classes (particular test classes or e.g. all classes in one package), then only the last test class is reported. > It works when you run all tests, and also with JUnit nicely. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 10:26:01 2014 From: issues at jboss.org (Emond Papegaaij (JIRA)) Date: Fri, 5 Sep 2014 10:26:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1845) BeforeSuite and AfterSuite events triggered for every class in Eclipse since ARQ-1803 In-Reply-To: References: Message-ID: Emond Papegaaij created ARQ-1845: ------------------------------------ Summary: BeforeSuite and AfterSuite events triggered for every class in Eclipse since ARQ-1803 Key: ARQ-1845 URL: https://issues.jboss.org/browse/ARQ-1845 Project: Arquillian Issue Type: Bug Components: Base Implementation Affects Versions: 1.1.5.Final Reporter: Emond Papegaaij The change made in ARQ-1803 broke the Eclipse hack that should prevent Before- and AfterSuite events for every class. Eclipse creates an Arquillian instance for every class to be tested before the tests are actually started. The State.runnerStarted() was placed in the constructor to count the number of tests created, so only the last test would fire AfterSuite. See the comment in org.jboss.arquillian.junit.State for more info. This is a major regression for us, as we depend on the arquillian-suite-extension to only deploy the application once. Deploying the application takes over a minute, adding significant time to our test runs under Eclipse. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 10:37:00 2014 From: issues at jboss.org (Emond Papegaaij (JIRA)) Date: Fri, 5 Sep 2014 10:37:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1845) BeforeSuite and AfterSuite events triggered for every class in Eclipse since ARQ-1803 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emond Papegaaij updated ARQ-1845: --------------------------------- Component/s: Test Harness Integration (was: Base Implementation) > BeforeSuite and AfterSuite events triggered for every class in Eclipse since ARQ-1803 > ------------------------------------------------------------------------------------- > > Key: ARQ-1845 > URL: https://issues.jboss.org/browse/ARQ-1845 > Project: Arquillian > Issue Type: Bug > Components: Test Harness Integration > Affects Versions: 1.1.5.Final > Reporter: Emond Papegaaij > > The change made in ARQ-1803 broke the Eclipse hack that should prevent Before- and AfterSuite events for every class. Eclipse creates an Arquillian instance for every class to be tested before the tests are actually started. The State.runnerStarted() was placed in the constructor to count the number of tests created, so only the last test would fire AfterSuite. See the comment in org.jboss.arquillian.junit.State for more info. > This is a major regression for us, as we depend on the arquillian-suite-extension to only deploy the application once. Deploying the application takes over a minute, adding significant time to our test runs under Eclipse. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 19:15:00 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Fri, 5 Sep 2014 19:15:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers In-Reply-To: References: Message-ID: Ian Brandt created ARQ-1846: ------------------------------- Summary: Support configuration of the Tomcat system classpath from managed containers Key: ARQ-1846 URL: https://issues.jboss.org/browse/ARQ-1846 Project: Arquillian Issue Type: Feature Request Components: Tomcat Containers Affects Versions: tomcat_1.0.0.CR7 Reporter: Ian Brandt In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 19:16:00 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Fri, 5 Sep 2014 19:16:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt reassigned ARQ-1846: ------------------------------- Assignee: Ian Brandt > Support configuration of the Tomcat system classpath from managed containers > ---------------------------------------------------------------------------- > > Key: ARQ-1846 > URL: https://issues.jboss.org/browse/ARQ-1846 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 19:16:00 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Fri, 5 Sep 2014 19:16:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1846: ---------------------------- Fix Version/s: tomcat_1.0.0.Final > Support configuration of the Tomcat system classpath from managed containers > ---------------------------------------------------------------------------- > > Key: ARQ-1846 > URL: https://issues.jboss.org/browse/ARQ-1846 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 19:16:01 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Fri, 5 Sep 2014 19:16:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1846 started by Ian Brandt. --------------------------------------- > Support configuration of the Tomcat system classpath from managed containers > ---------------------------------------------------------------------------- > > Key: ARQ-1846 > URL: https://issues.jboss.org/browse/ARQ-1846 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 21:54:59 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Fri, 5 Sep 2014 21:54:59 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1847) Support specifying JMX RMI server port In-Reply-To: References: Message-ID: Stephen Coy created ARQ-1847: -------------------------------- Summary: Support specifying JMX RMI server port Key: ARQ-1847 URL: https://issues.jboss.org/browse/ARQ-1847 Project: Arquillian Issue Type: Feature Request Components: Tomcat Containers Affects Versions: tomcat_1.0.0.CR7 Reporter: Stephen Coy This additional configuration is necessary to support remote deployments behind firewalls -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 21:55:00 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Fri, 5 Sep 2014 21:55:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1847) Support specifying JMX RMI server port In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Coy reassigned ARQ-1847: -------------------------------- Assignee: Stephen Coy > Support specifying JMX RMI server port > -------------------------------------- > > Key: ARQ-1847 > URL: https://issues.jboss.org/browse/ARQ-1847 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Stephen Coy > Assignee: Stephen Coy > > This additional configuration is necessary to support remote deployments behind firewalls -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 22:19:59 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Fri, 5 Sep 2014 22:19:59 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1847) Support specifying JMX RMI server port In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1847 started by Stephen Coy. ---------------------------------------- > Support specifying JMX RMI server port > -------------------------------------- > > Key: ARQ-1847 > URL: https://issues.jboss.org/browse/ARQ-1847 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Stephen Coy > Assignee: Stephen Coy > > This additional configuration is necessary to support remote deployments behind firewalls -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 22:25:59 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Fri, 5 Sep 2014 22:25:59 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1847) Support specifying JMX RMI server port In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999654#comment-12999654 ] Stephen Coy commented on ARQ-1847: ---------------------------------- Note: org.jboss.arquillian.container.tomcat.CommonTomcatConfiguration contains the following two public setters: {code:java} public void setJmxUri(URI jmxUri) public void setManagerUrl(URL managerUrl) {code:java} which implies that they are configurable from arquillian.xml. However, these are both overwritten during validation. Therefore I'm tempted to remove these setters altogether. > Support specifying JMX RMI server port > -------------------------------------- > > Key: ARQ-1847 > URL: https://issues.jboss.org/browse/ARQ-1847 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Stephen Coy > Assignee: Stephen Coy > > This additional configuration is necessary to support remote deployments behind firewalls -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 22:26:59 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Fri, 5 Sep 2014 22:26:59 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1847) Support specifying JMX RMI server port In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999654#comment-12999654 ] Stephen Coy edited comment on ARQ-1847 at 9/5/14 10:26 PM: ----------------------------------------------------------- Note: org.jboss.arquillian.container.tomcat.CommonTomcatConfiguration contains the following two public setters: {code:java} public void setJmxUri(URI jmxUri) public void setManagerUrl(URL managerUrl) {code} which implies that they are configurable from arquillian.xml. However, these are both overwritten during validation. Therefore I'm tempted to remove these setters altogether. was (Author: sfcoy): Note: org.jboss.arquillian.container.tomcat.CommonTomcatConfiguration contains the following two public setters: {code:java} public void setJmxUri(URI jmxUri) public void setManagerUrl(URL managerUrl) {code:java} which implies that they are configurable from arquillian.xml. However, these are both overwritten during validation. Therefore I'm tempted to remove these setters altogether. > Support specifying JMX RMI server port > -------------------------------------- > > Key: ARQ-1847 > URL: https://issues.jboss.org/browse/ARQ-1847 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Stephen Coy > Assignee: Stephen Coy > > This additional configuration is necessary to support remote deployments behind firewalls -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 6 16:44:00 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sat, 6 Sep 2014 16:44:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1848) Tomcat managed containers should start and stop Tomcat using the standard run scripts In-Reply-To: References: Message-ID: Ian Brandt created ARQ-1848: ------------------------------- Summary: Tomcat managed containers should start and stop Tomcat using the standard run scripts Key: ARQ-1848 URL: https://issues.jboss.org/browse/ARQ-1848 Project: Arquillian Issue Type: Feature Request Components: Tomcat Containers Affects Versions: tomcat_1.0.0.CR7 Reporter: Ian Brandt The [standard Tomcat run scripts|http://tomcat.apache.org/tomcat-8.0-doc/RUNNING.txt] contain a fair little bit of logic and features: * Multiple instance support (requiring the proper merging of resources from {{CATALINA_BASE}} and {{CATALINA_HOME}}). * Logging configuration. * Running with or without a security manager. * Support for configuration in the 'setenv' script. * Endorsed and temp directory configuration. * Launching with JPDA related configuration. * OS variant and TTY related configuration on UNIX. By building the Java command to launch Tomcat directly the current {{CommonTomcatManagedContainer}} forgoes the standard implementation of all this. There is a growing history of bug reports and feature requests that suggest this may not be the best approach: * ARQ-628 - Tomcat managed throws NullPointerException when application under test brings weld-servlet dependency * ARQ-866 - Allow catalina.base to be configured separately from catalina.home in the Tomcat managed adapters * ARQ-1650 - Managed container bypasses tomcat jul setup * ARQ-1843 - Tomcat managed container ignores javaHome configuration * ARQ-1846 - Support configuration of the Tomcat system classpath from managed containers * ARQ-1847 - Support specifying JMX RMI server port Rather than reinventing the wheel here, we should just launch and stop Tomcat with the standard run script for the current OS, exposing it's environment variable-driven configuration via arquillian.xml and the {{CommonTomcatManagedConfiguration}}. This will: * Add all the missing features and logic. * Be simpler and presumably cheaper to maintain over trying to mirror the standard scripts. * Encourage better fidelity between managed containers and their production counterparts (e.g. identical {{CATALINA_BASE}} and {{CATALINA_HOME}} merging, as well as setenv script support). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 6 16:44:01 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sat, 6 Sep 2014 16:44:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1848) Tomcat managed containers should start and stop Tomcat using the standard run scripts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt reassigned ARQ-1848: ------------------------------- Assignee: Ian Brandt > Tomcat managed containers should start and stop Tomcat using the standard run scripts > ------------------------------------------------------------------------------------- > > Key: ARQ-1848 > URL: https://issues.jboss.org/browse/ARQ-1848 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > The [standard Tomcat run scripts|http://tomcat.apache.org/tomcat-8.0-doc/RUNNING.txt] contain a fair little bit of logic and features: > * Multiple instance support (requiring the proper merging of resources from {{CATALINA_BASE}} and {{CATALINA_HOME}}). > * Logging configuration. > * Running with or without a security manager. > * Support for configuration in the 'setenv' script. > * Endorsed and temp directory configuration. > * Launching with JPDA related configuration. > * OS variant and TTY related configuration on UNIX. > By building the Java command to launch Tomcat directly the current {{CommonTomcatManagedContainer}} forgoes the standard implementation of all this. There is a growing history of bug reports and feature requests that suggest this may not be the best approach: > * ARQ-628 - Tomcat managed throws NullPointerException when application under test brings weld-servlet dependency > * ARQ-866 - Allow catalina.base to be configured separately from catalina.home in the Tomcat managed adapters > * ARQ-1650 - Managed container bypasses tomcat jul setup > * ARQ-1843 - Tomcat managed container ignores javaHome configuration > * ARQ-1846 - Support configuration of the Tomcat system classpath from managed containers > * ARQ-1847 - Support specifying JMX RMI server port > Rather than reinventing the wheel here, we should just launch and stop Tomcat with the standard run script for the current OS, exposing it's environment variable-driven configuration via arquillian.xml and the {{CommonTomcatManagedConfiguration}}. This will: > * Add all the missing features and logic. > * Be simpler and presumably cheaper to maintain over trying to mirror the standard scripts. > * Encourage better fidelity between managed containers and their production counterparts (e.g. identical {{CATALINA_BASE}} and {{CATALINA_HOME}} merging, as well as setenv script support). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 6 16:44:01 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sat, 6 Sep 2014 16:44:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1848) Tomcat managed containers should start and stop Tomcat using the standard run scripts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1848: ---------------------------- Fix Version/s: tomcat_1.0.0.Final > Tomcat managed containers should start and stop Tomcat using the standard run scripts > ------------------------------------------------------------------------------------- > > Key: ARQ-1848 > URL: https://issues.jboss.org/browse/ARQ-1848 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > The [standard Tomcat run scripts|http://tomcat.apache.org/tomcat-8.0-doc/RUNNING.txt] contain a fair little bit of logic and features: > * Multiple instance support (requiring the proper merging of resources from {{CATALINA_BASE}} and {{CATALINA_HOME}}). > * Logging configuration. > * Running with or without a security manager. > * Support for configuration in the 'setenv' script. > * Endorsed and temp directory configuration. > * Launching with JPDA related configuration. > * OS variant and TTY related configuration on UNIX. > By building the Java command to launch Tomcat directly the current {{CommonTomcatManagedContainer}} forgoes the standard implementation of all this. There is a growing history of bug reports and feature requests that suggest this may not be the best approach: > * ARQ-628 - Tomcat managed throws NullPointerException when application under test brings weld-servlet dependency > * ARQ-866 - Allow catalina.base to be configured separately from catalina.home in the Tomcat managed adapters > * ARQ-1650 - Managed container bypasses tomcat jul setup > * ARQ-1843 - Tomcat managed container ignores javaHome configuration > * ARQ-1846 - Support configuration of the Tomcat system classpath from managed containers > * ARQ-1847 - Support specifying JMX RMI server port > Rather than reinventing the wheel here, we should just launch and stop Tomcat with the standard run script for the current OS, exposing it's environment variable-driven configuration via arquillian.xml and the {{CommonTomcatManagedConfiguration}}. This will: > * Add all the missing features and logic. > * Be simpler and presumably cheaper to maintain over trying to mirror the standard scripts. > * Encourage better fidelity between managed containers and their production counterparts (e.g. identical {{CATALINA_BASE}} and {{CATALINA_HOME}} merging, as well as setenv script support). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 6 16:44:59 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sat, 6 Sep 2014 16:44:59 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1848) Tomcat managed containers should start and stop Tomcat using the standard run scripts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1848 started by Ian Brandt. --------------------------------------- > Tomcat managed containers should start and stop Tomcat using the standard run scripts > ------------------------------------------------------------------------------------- > > Key: ARQ-1848 > URL: https://issues.jboss.org/browse/ARQ-1848 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > The [standard Tomcat run scripts|http://tomcat.apache.org/tomcat-8.0-doc/RUNNING.txt] contain a fair little bit of logic and features: > * Multiple instance support (requiring the proper merging of resources from {{CATALINA_BASE}} and {{CATALINA_HOME}}). > * Logging configuration. > * Running with or without a security manager. > * Support for configuration in the 'setenv' script. > * Endorsed and temp directory configuration. > * Launching with JPDA related configuration. > * OS variant and TTY related configuration on UNIX. > By building the Java command to launch Tomcat directly the current {{CommonTomcatManagedContainer}} forgoes the standard implementation of all this. There is a growing history of bug reports and feature requests that suggest this may not be the best approach: > * ARQ-628 - Tomcat managed throws NullPointerException when application under test brings weld-servlet dependency > * ARQ-866 - Allow catalina.base to be configured separately from catalina.home in the Tomcat managed adapters > * ARQ-1650 - Managed container bypasses tomcat jul setup > * ARQ-1843 - Tomcat managed container ignores javaHome configuration > * ARQ-1846 - Support configuration of the Tomcat system classpath from managed containers > * ARQ-1847 - Support specifying JMX RMI server port > Rather than reinventing the wheel here, we should just launch and stop Tomcat with the standard run script for the current OS, exposing it's environment variable-driven configuration via arquillian.xml and the {{CommonTomcatManagedConfiguration}}. This will: > * Add all the missing features and logic. > * Be simpler and presumably cheaper to maintain over trying to mirror the standard scripts. > * Encourage better fidelity between managed containers and their production counterparts (e.g. identical {{CATALINA_BASE}} and {{CATALINA_HOME}} merging, as well as setenv script support). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 6 16:46:59 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sat, 6 Sep 2014 16:46:59 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1846 stopped by Ian Brandt. --------------------------------------- > Support configuration of the Tomcat system classpath from managed containers > ---------------------------------------------------------------------------- > > Key: ARQ-1846 > URL: https://issues.jboss.org/browse/ARQ-1846 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 6 16:47:59 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sat, 6 Sep 2014 16:47:59 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999661#comment-12999661 ] Ian Brandt commented on ARQ-1846: --------------------------------- This would be made obsolete by ARQ-1848. > Support configuration of the Tomcat system classpath from managed containers > ---------------------------------------------------------------------------- > > Key: ARQ-1846 > URL: https://issues.jboss.org/browse/ARQ-1846 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 6 16:51:59 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sat, 6 Sep 2014 16:51:59 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1848) Tomcat managed containers should start and stop Tomcat using the standard run scripts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999662#comment-12999662 ] Ian Brandt commented on ARQ-1848: --------------------------------- Given that we're on CR7, and this will entail a significant change to the arquillian.xml options for the Tomcat managed containers, I'm going to code this on a branch for review and discussion. I believe this is something that we should do before declaring the managed containers 1.0.0.Final, but others may feel differently. > Tomcat managed containers should start and stop Tomcat using the standard run scripts > ------------------------------------------------------------------------------------- > > Key: ARQ-1848 > URL: https://issues.jboss.org/browse/ARQ-1848 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > The [standard Tomcat run scripts|http://tomcat.apache.org/tomcat-8.0-doc/RUNNING.txt] contain a fair little bit of logic and features: > * Multiple instance support (requiring the proper merging of resources from {{CATALINA_BASE}} and {{CATALINA_HOME}}). > * Logging configuration. > * Running with or without a security manager. > * Support for configuration in the 'setenv' script. > * Endorsed and temp directory configuration. > * Launching with JPDA related configuration. > * OS variant and TTY related configuration on UNIX. > By building the Java command to launch Tomcat directly the current {{CommonTomcatManagedContainer}} forgoes the standard implementation of all this. There is a growing history of bug reports and feature requests that suggest this may not be the best approach: > * ARQ-628 - Tomcat managed throws NullPointerException when application under test brings weld-servlet dependency > * ARQ-866 - Allow catalina.base to be configured separately from catalina.home in the Tomcat managed adapters > * ARQ-1650 - Managed container bypasses tomcat jul setup > * ARQ-1843 - Tomcat managed container ignores javaHome configuration > * ARQ-1846 - Support configuration of the Tomcat system classpath from managed containers > * ARQ-1847 - Support specifying JMX RMI server port > Rather than reinventing the wheel here, we should just launch and stop Tomcat with the standard run script for the current OS, exposing it's environment variable-driven configuration via arquillian.xml and the {{CommonTomcatManagedConfiguration}}. This will: > * Add all the missing features and logic. > * Be simpler and presumably cheaper to maintain over trying to mirror the standard scripts. > * Encourage better fidelity between managed containers and their production counterparts (e.g. identical {{CATALINA_BASE}} and {{CATALINA_HOME}} merging, as well as setenv script support). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 6 22:03:00 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Sat, 6 Sep 2014 22:03:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1848) Tomcat managed containers should start and stop Tomcat using the standard run scripts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999665#comment-12999665 ] Stephen Coy commented on ARQ-1848: ---------------------------------- Normally I don't like calling scripts that invoke java from a java program. However there is some merit in this approach in this instance. I do feel that it should wait until post 1.0.0.Final though. The whole tomcat-container codebase is due for some substantial refactoring just to get rid of code duplication. > Tomcat managed containers should start and stop Tomcat using the standard run scripts > ------------------------------------------------------------------------------------- > > Key: ARQ-1848 > URL: https://issues.jboss.org/browse/ARQ-1848 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > The [standard Tomcat run scripts|http://tomcat.apache.org/tomcat-8.0-doc/RUNNING.txt] contain a fair little bit of logic and features: > * Multiple instance support (requiring the proper merging of resources from {{CATALINA_BASE}} and {{CATALINA_HOME}}). > * Logging configuration. > * Running with or without a security manager. > * Support for configuration in the 'setenv' script. > * Endorsed and temp directory configuration. > * Launching with JPDA related configuration. > * OS variant and TTY related configuration on UNIX. > By building the Java command to launch Tomcat directly the current {{CommonTomcatManagedContainer}} forgoes the standard implementation of all this. There is a growing history of bug reports and feature requests that suggest this may not be the best approach: > * ARQ-628 - Tomcat managed throws NullPointerException when application under test brings weld-servlet dependency > * ARQ-866 - Allow catalina.base to be configured separately from catalina.home in the Tomcat managed adapters > * ARQ-1650 - Managed container bypasses tomcat jul setup > * ARQ-1843 - Tomcat managed container ignores javaHome configuration > * ARQ-1846 - Support configuration of the Tomcat system classpath from managed containers > * ARQ-1847 - Support specifying JMX RMI server port > Rather than reinventing the wheel here, we should just launch and stop Tomcat with the standard run script for the current OS, exposing it's environment variable-driven configuration via arquillian.xml and the {{CommonTomcatManagedConfiguration}}. This will: > * Add all the missing features and logic. > * Be simpler and presumably cheaper to maintain over trying to mirror the standard scripts. > * Encourage better fidelity between managed containers and their production counterparts (e.g. identical {{CATALINA_BASE}} and {{CATALINA_HOME}} merging, as well as setenv script support). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 6 22:10:59 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Sat, 6 Sep 2014 22:10:59 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1847) Support specifying JMX RMI server port In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Coy updated ARQ-1847: ----------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/arquillian/arquillian-container-tomcat/pull/27 > Support specifying JMX RMI server port > -------------------------------------- > > Key: ARQ-1847 > URL: https://issues.jboss.org/browse/ARQ-1847 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Stephen Coy > Assignee: Stephen Coy > > This additional configuration is necessary to support remote deployments behind firewalls -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 11:41:00 2014 From: issues at jboss.org (Razvan Petre (JIRA)) Date: Mon, 8 Sep 2014 11:41:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1849) GlassFish container already boostrapped In-Reply-To: References: Message-ID: Razvan Petre created ARQ-1849: --------------------------------- Summary: GlassFish container already boostrapped Key: ARQ-1849 URL: https://issues.jboss.org/browse/ARQ-1849 Project: Arquillian Issue Type: Bug Components: Configuration Affects Versions: 1.1.5.Final Reporter: Razvan Petre after upgrading from 1.1.3.Final to 1.1.5.Final, was not able to run all the test in Eclipse... any ideas? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 15:43:00 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Mon, 8 Sep 2014 15:43:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1847) Support specifying JMX RMI server port In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1847: ---------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: tomcat_1.0.0.Final Resolution: Done Added some basic unit tests and merged: https://github.com/arquillian/arquillian-container-tomcat/commit/4dc65d10da1326875dcba7bb9d5e79344037b7d7 > Support specifying JMX RMI server port > -------------------------------------- > > Key: ARQ-1847 > URL: https://issues.jboss.org/browse/ARQ-1847 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Stephen Coy > Assignee: Stephen Coy > Fix For: tomcat_1.0.0.Final > > > This additional configuration is necessary to support remote deployments behind firewalls -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 17:14:00 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Mon, 8 Sep 2014 17:14:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1850) Setup static analysis/reporting options for Arquillian projects In-Reply-To: References: Message-ID: Ian Brandt created ARQ-1850: ------------------------------- Summary: Setup static analysis/reporting options for Arquillian projects Key: ARQ-1850 URL: https://issues.jboss.org/browse/ARQ-1850 Project: Arquillian Issue Type: Feature Request Components: Build Infrastructure Reporter: Ian Brandt It would be nice to add static analysis and reporting options to the current build infrastructure. There is already CI support via CloudBees [DEV at Cloud service|https://arquillian.ci.cloudbees.com/]. They also offer an integrated [Sonar as a service|https://developer.cloudbees.com/bin/view/DEV/Sonar] option that Arquillian modules could leverage. Also if the builds published the Maven Sites that would allow for [further reporting|http://www.sonarqube.org/maven-site-sonar-or-both-of-them/]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 17:14:00 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Mon, 8 Sep 2014 17:14:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1850) Setup static analysis/reporting options for Arquillian projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1850: ---------------------------- Assignee: Aslak Knutsen > Setup static analysis/reporting options for Arquillian projects > --------------------------------------------------------------- > > Key: ARQ-1850 > URL: https://issues.jboss.org/browse/ARQ-1850 > Project: Arquillian > Issue Type: Feature Request > Components: Build Infrastructure > Reporter: Ian Brandt > Assignee: Aslak Knutsen > > It would be nice to add static analysis and reporting options to the current build infrastructure. There is already CI support via CloudBees [DEV at Cloud service|https://arquillian.ci.cloudbees.com/]. They also offer an integrated [Sonar as a service|https://developer.cloudbees.com/bin/view/DEV/Sonar] option that Arquillian modules could leverage. Also if the builds published the Maven Sites that would allow for [further reporting|http://www.sonarqube.org/maven-site-sonar-or-both-of-them/]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 10 04:40:19 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Wed, 10 Sep 2014 04:40:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1851) Update Selenium to 2.43.0 In-Reply-To: References: Message-ID: Pavol Pitonak created ARQ-1851: ---------------------------------- Summary: Update Selenium to 2.43.0 Key: ARQ-1851 URL: https://issues.jboss.org/browse/ARQ-1851 Project: Arquillian Issue Type: Feature Request Components: Extension - Drone Affects Versions: drone_1.3.1.Final Reporter: Pavol Pitonak Update to latest Selenium - 2.43.0 supporting new versions of browsers, e.g. Firefox 31 ESR -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 10 07:33:19 2014 From: issues at jboss.org (Emond Papegaaij (JIRA)) Date: Wed, 10 Sep 2014 07:33:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1852) Move Warp's CommandService to Protocol In-Reply-To: References: Message-ID: Emond Papegaaij created ARQ-1852: ------------------------------------ Summary: Move Warp's CommandService to Protocol Key: ARQ-1852 URL: https://issues.jboss.org/browse/ARQ-1852 Project: Arquillian Issue Type: Enhancement Components: Extension - Warp, Test Protocol SPIs and Implementation Affects Versions: 1.1.5.Final Reporter: Emond Papegaaij Priority: Optional Warp provides are very nice SPI for running commands remotely. It would be very nice if this SPI became part of the Protocol classes, making it available to all Arquillian code. I'm writing an extension, which needs to execute some code in the container, but is triggered on events fired on the client. Warp's CommandService would allow me to do this, but it only works in Warp tests. Also, making the code part of Protocol should remove quite some duplication between Protocol and Warp's CommandService. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 10 07:35:19 2014 From: issues at jboss.org (Emond Papegaaij (JIRA)) Date: Wed, 10 Sep 2014 07:35:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1852) Move Warp's CommandService to Protocol In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emond Papegaaij updated ARQ-1852: --------------------------------- Description: Warp provides a very nice SPI for running commands remotely. I would love to see this this SPI become part of the Protocol classes, making it available to all Arquillian code. I'm writing an extension, which needs to execute some code in the container, but is triggered on events fired on the client. Warp's CommandService would allow me to do this, but it only works in Warp tests, which my tests are not. Also, making the code part of Protocol should remove quite some duplication between Protocol and Warp's CommandService. (was: Warp provides are very nice SPI for running commands remotely. It would be very nice if this SPI became part of the Protocol classes, making it available to all Arquillian code. I'm writing an extension, which needs to execute some code in the container, but is triggered on events fired on the client. Warp's CommandService would allow me to do this, but it only works in Warp tests. Also, making the code part of Protocol should remove quite some duplication between Protocol and Warp's CommandService.) > Move Warp's CommandService to Protocol > -------------------------------------- > > Key: ARQ-1852 > URL: https://issues.jboss.org/browse/ARQ-1852 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp, Test Protocol SPIs and Implementation > Affects Versions: 1.1.5.Final > Reporter: Emond Papegaaij > Priority: Optional > > Warp provides a very nice SPI for running commands remotely. I would love to see this this SPI become part of the Protocol classes, making it available to all Arquillian code. I'm writing an extension, which needs to execute some code in the container, but is triggered on events fired on the client. Warp's CommandService would allow me to do this, but it only works in Warp tests, which my tests are not. Also, making the code part of Protocol should remove quite some duplication between Protocol and Warp's CommandService. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 10 08:52:19 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 10 Sep 2014 08:52:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1852) Move Warp's CommandService to Protocol In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000821#comment-13000821 ] Aslak Knutsen commented on ARQ-1852: ------------------------------------ CommandService is part of Core already. Every Protocol has it's own implementation of it to allow InContainer to communicate with Client side: https://github.com/arquillian/arquillian-core/blob/master/container/test-spi/src/main/java/org/jboss/arquillian/container/test/spi/command/CommandService.java E.g. the ServletCommandService from the Servlet Protocol: https://github.com/arquillian/arquillian-core/blob/master/protocols/servlet/src/main/java/org/jboss/arquillian/protocol/servlet/runner/ServletCommandService.java ? > Move Warp's CommandService to Protocol > -------------------------------------- > > Key: ARQ-1852 > URL: https://issues.jboss.org/browse/ARQ-1852 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp, Test Protocol SPIs and Implementation > Affects Versions: 1.1.5.Final > Reporter: Emond Papegaaij > Priority: Optional > > Warp provides a very nice SPI for running commands remotely. I would love to see this this SPI become part of the Protocol classes, making it available to all Arquillian code. I'm writing an extension, which needs to execute some code in the container, but is triggered on events fired on the client. Warp's CommandService would allow me to do this, but it only works in Warp tests, which my tests are not. Also, making the code part of Protocol should remove quite some duplication between Protocol and Warp's CommandService. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 10 08:53:19 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 10 Sep 2014 08:53:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1852) Move Warp's CommandService to Protocol In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000821#comment-13000821 ] Aslak Knutsen edited comment on ARQ-1852 at 9/10/14 8:52 AM: ------------------------------------------------------------- CommandService is part of Core already. Every Protocol has it's own implementation of it to allow InContainer to communicate with Client side: https://github.com/arquillian/arquillian-core/blob/master/container/test-spi/src/main/java/org/jboss/arquillian/container/test/spi/command/CommandService.java E.g. the ServletCommandService from the Servlet Protocol: https://github.com/arquillian/arquillian-core/blob/master/protocols/servlet/src/main/java/org/jboss/arquillian/protocol/servlet/runner/ServletCommandService.java After re-reading, you want the opposite way? Client to send commands to Container at any point? was (Author: aslak): CommandService is part of Core already. Every Protocol has it's own implementation of it to allow InContainer to communicate with Client side: https://github.com/arquillian/arquillian-core/blob/master/container/test-spi/src/main/java/org/jboss/arquillian/container/test/spi/command/CommandService.java E.g. the ServletCommandService from the Servlet Protocol: https://github.com/arquillian/arquillian-core/blob/master/protocols/servlet/src/main/java/org/jboss/arquillian/protocol/servlet/runner/ServletCommandService.java ? > Move Warp's CommandService to Protocol > -------------------------------------- > > Key: ARQ-1852 > URL: https://issues.jboss.org/browse/ARQ-1852 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp, Test Protocol SPIs and Implementation > Affects Versions: 1.1.5.Final > Reporter: Emond Papegaaij > Priority: Optional > > Warp provides a very nice SPI for running commands remotely. I would love to see this this SPI become part of the Protocol classes, making it available to all Arquillian code. I'm writing an extension, which needs to execute some code in the container, but is triggered on events fired on the client. Warp's CommandService would allow me to do this, but it only works in Warp tests, which my tests are not. Also, making the code part of Protocol should remove quite some duplication between Protocol and Warp's CommandService. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 10 08:53:19 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 10 Sep 2014 08:53:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1852) Move Warp's CommandService to Protocol In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000821#comment-13000821 ] Aslak Knutsen edited comment on ARQ-1852 at 9/10/14 8:52 AM: ------------------------------------------------------------- CommandService is part of Core already. Every Protocol has it's own implementation of it to allow InContainer to communicate with Client side: https://github.com/arquillian/arquillian-core/blob/master/container/test-spi/src/main/java/org/jboss/arquillian/container/test/spi/command/CommandService.java E.g. the ServletCommandService from the Servlet Protocol: https://github.com/arquillian/arquillian-core/blob/master/protocols/servlet/src/main/java/org/jboss/arquillian/protocol/servlet/runner/ServletCommandService.java After re-reading, you want the opposite direction? Client to send commands to Container at any point? was (Author: aslak): CommandService is part of Core already. Every Protocol has it's own implementation of it to allow InContainer to communicate with Client side: https://github.com/arquillian/arquillian-core/blob/master/container/test-spi/src/main/java/org/jboss/arquillian/container/test/spi/command/CommandService.java E.g. the ServletCommandService from the Servlet Protocol: https://github.com/arquillian/arquillian-core/blob/master/protocols/servlet/src/main/java/org/jboss/arquillian/protocol/servlet/runner/ServletCommandService.java After re-reading, you want the opposite way? Client to send commands to Container at any point? > Move Warp's CommandService to Protocol > -------------------------------------- > > Key: ARQ-1852 > URL: https://issues.jboss.org/browse/ARQ-1852 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp, Test Protocol SPIs and Implementation > Affects Versions: 1.1.5.Final > Reporter: Emond Papegaaij > Priority: Optional > > Warp provides a very nice SPI for running commands remotely. I would love to see this this SPI become part of the Protocol classes, making it available to all Arquillian code. I'm writing an extension, which needs to execute some code in the container, but is triggered on events fired on the client. Warp's CommandService would allow me to do this, but it only works in Warp tests, which my tests are not. Also, making the code part of Protocol should remove quite some duplication between Protocol and Warp's CommandService. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 10 10:13:19 2014 From: issues at jboss.org (Emond Papegaaij (JIRA)) Date: Wed, 10 Sep 2014 10:13:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1852) Move Warp's CommandService to Protocol In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000881#comment-13000881 ] Emond Papegaaij commented on ARQ-1852: -------------------------------------- Yes, I Observe several events at the client side and need to execute code at the server in response. Warp has a CommandService, which, if I'm not mistaken, is used to execute its inspections. In our case, I need to container to generate a report at certain points and send it to the client. Only the client knows when. The easiest way to implement this, is using a servlet, but that would duplicate a lot of work already done in the protocols and in Warp. > Move Warp's CommandService to Protocol > -------------------------------------- > > Key: ARQ-1852 > URL: https://issues.jboss.org/browse/ARQ-1852 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp, Test Protocol SPIs and Implementation > Affects Versions: 1.1.5.Final > Reporter: Emond Papegaaij > Priority: Optional > > Warp provides a very nice SPI for running commands remotely. I would love to see this this SPI become part of the Protocol classes, making it available to all Arquillian code. I'm writing an extension, which needs to execute some code in the container, but is triggered on events fired on the client. Warp's CommandService would allow me to do this, but it only works in Warp tests, which my tests are not. Also, making the code part of Protocol should remove quite some duplication between Protocol and Warp's CommandService. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 07:04:19 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 12 Sep 2014 07:04:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1852) Move Warp's CommandService to Protocol In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001794#comment-13001794 ] Aslak Knutsen commented on ARQ-1852: ------------------------------------ At which points do the Client know? The normal execution flow in Arquillian is to for each @Test on client side execute the full In Container cycle(BeforeSuite/BeforeClass/Before/Test...), then take the result from container and move on. This is per say single threaded, so the Client can't really send anything at 'random' points to the container. It only sends one 'command'; run the complete test. It's from within the container side you can send fine grained commands back to the client within any of the events(BeforeSuite, BeforeClass.. ).. If you can explain in more detail what you're trying to do. > Move Warp's CommandService to Protocol > -------------------------------------- > > Key: ARQ-1852 > URL: https://issues.jboss.org/browse/ARQ-1852 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp, Test Protocol SPIs and Implementation > Affects Versions: 1.1.5.Final > Reporter: Emond Papegaaij > Priority: Optional > > Warp provides a very nice SPI for running commands remotely. I would love to see this this SPI become part of the Protocol classes, making it available to all Arquillian code. I'm writing an extension, which needs to execute some code in the container, but is triggered on events fired on the client. Warp's CommandService would allow me to do this, but it only works in Warp tests, which my tests are not. Also, making the code part of Protocol should remove quite some duplication between Protocol and Warp's CommandService. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 14:46:19 2014 From: issues at jboss.org (Emond Papegaaij (JIRA)) Date: Fri, 12 Sep 2014 14:46:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1852) Move Warp's CommandService to Protocol In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002023#comment-13002023 ] Emond Papegaaij commented on ARQ-1852: -------------------------------------- We are running selenium test with Arquillian with custom Wicket integration. These test run on the server to be able to access the Wicket state from within the selenium test itself. In this setting, I would like these commands for two purposes: reporting and resource management. The first I was able to solve with commands from the server to the client. But the second still remains open. Opening a new browser and setting up the user session is quite expensive compared to the actual test cases so I want to pool browsers with active sessions. However, these need to be closed after the last case. Because Arquillian triggers AfterSuite after every case, I can't use this event in the container. I would like to send a command from the client on AfterSuite to close all open browsers. In general, I think the ability to send commands from the client to the container can be useful in many other cases. From what I've seen in Warp's code, is that they implemented a separate servlet filter to implement this. A lot of code is duplicated between SevletProtocol and warp, including for example the code to get the right URL, causing bugs like ARQ-1592. > Move Warp's CommandService to Protocol > -------------------------------------- > > Key: ARQ-1852 > URL: https://issues.jboss.org/browse/ARQ-1852 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp, Test Protocol SPIs and Implementation > Affects Versions: 1.1.5.Final > Reporter: Emond Papegaaij > Priority: Optional > > Warp provides a very nice SPI for running commands remotely. I would love to see this this SPI become part of the Protocol classes, making it available to all Arquillian code. I'm writing an extension, which needs to execute some code in the container, but is triggered on events fired on the client. Warp's CommandService would allow me to do this, but it only works in Warp tests, which my tests are not. Also, making the code part of Protocol should remove quite some duplication between Protocol and Warp's CommandService. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:12:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:12:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1789) add tomcat 8 managed and/or remote container adapters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt reassigned ARQ-1789: ------------------------------- Assignee: Ian Brandt > add tomcat 8 managed and/or remote container adapters > ----------------------------------------------------- > > Key: ARQ-1789 > URL: https://issues.jboss.org/browse/ARQ-1789 > Project: Arquillian > Issue Type: Feature Request > Reporter: Peter Butkovic > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > I'd like to see managed and/or remote support for tomcat 8 available in arquillian. > As I need to do some container pre-configuration/patching before the run as well as to have clear classpath separation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:12:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:12:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1789) add tomcat 8 managed and/or remote container adapters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1789: ---------------------------- Fix Version/s: tomcat_1.0.0.Final > add tomcat 8 managed and/or remote container adapters > ----------------------------------------------------- > > Key: ARQ-1789 > URL: https://issues.jboss.org/browse/ARQ-1789 > Project: Arquillian > Issue Type: Feature Request > Reporter: Peter Butkovic > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > I'd like to see managed and/or remote support for tomcat 8 available in arquillian. > As I need to do some container pre-configuration/patching before the run as well as to have clear classpath separation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:16:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:16:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1789) add tomcat 8 managed and/or remote container adapters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002133#comment-13002133 ] Ian Brandt commented on ARQ-1789: --------------------------------- I'm planning to implement this in the coming days after I complete my current code cleanup push. > add tomcat 8 managed and/or remote container adapters > ----------------------------------------------------- > > Key: ARQ-1789 > URL: https://issues.jboss.org/browse/ARQ-1789 > Project: Arquillian > Issue Type: Feature Request > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Peter Butkovic > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > I'd like to see managed and/or remote support for tomcat 8 available in arquillian. > As I need to do some container pre-configuration/patching before the run as well as to have clear classpath separation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:16:03 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:16:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1789) add tomcat 8 managed and/or remote container adapters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1789: ---------------------------- Affects Version/s: tomcat_1.0.0.CR7 > add tomcat 8 managed and/or remote container adapters > ----------------------------------------------------- > > Key: ARQ-1789 > URL: https://issues.jboss.org/browse/ARQ-1789 > Project: Arquillian > Issue Type: Feature Request > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Peter Butkovic > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > I'd like to see managed and/or remote support for tomcat 8 available in arquillian. > As I need to do some container pre-configuration/patching before the run as well as to have clear classpath separation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:17:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:17:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1789) add tomcat 8 managed and/or remote container adapters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1789: ---------------------------- Component/s: Tomcat Containers > add tomcat 8 managed and/or remote container adapters > ----------------------------------------------------- > > Key: ARQ-1789 > URL: https://issues.jboss.org/browse/ARQ-1789 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Peter Butkovic > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > I'd like to see managed and/or remote support for tomcat 8 available in arquillian. > As I need to do some container pre-configuration/patching before the run as well as to have clear classpath separation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:17:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:17:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1789) Add tomcat 8 managed and/or remote container adapters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1789: ---------------------------- Summary: Add tomcat 8 managed and/or remote container adapters (was: add tomcat 8 managed and/or remote container adapters) > Add tomcat 8 managed and/or remote container adapters > ----------------------------------------------------- > > Key: ARQ-1789 > URL: https://issues.jboss.org/browse/ARQ-1789 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Peter Butkovic > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > I'd like to see managed and/or remote support for tomcat 8 available in arquillian. > As I need to do some container pre-configuration/patching before the run as well as to have clear classpath separation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:17:03 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:17:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1789) Add tomcat 8 managed and remote container adapters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1789: ---------------------------- Summary: Add tomcat 8 managed and remote container adapters (was: Add tomcat 8 managed and/or remote container adapters) > Add tomcat 8 managed and remote container adapters > -------------------------------------------------- > > Key: ARQ-1789 > URL: https://issues.jboss.org/browse/ARQ-1789 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Peter Butkovic > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > I'd like to see managed and/or remote support for tomcat 8 available in arquillian. > As I need to do some container pre-configuration/patching before the run as well as to have clear classpath separation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:18:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:18:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1853) Drop Tomcat 5.5 support In-Reply-To: References: Message-ID: Ian Brandt created ARQ-1853: ------------------------------- Summary: Drop Tomcat 5.5 support Key: ARQ-1853 URL: https://issues.jboss.org/browse/ARQ-1853 Project: Arquillian Issue Type: Task Components: Tomcat Containers Affects Versions: tomcat_1.0.0.CR7 Reporter: Ian Brandt Priority: Optional I'm making a big push to further DRY up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based, but that introduced a dependency conflict on the Servlet APIs. * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-lifed|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:19:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:19:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1853) Drop Tomcat 5.5 support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1853: ---------------------------- Description: I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based, but that introduced a dependency conflict on the Servlet APIs. * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-lifed|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. was: I'm making a big push to further DRY up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based, but that introduced a dependency conflict on the Servlet APIs. * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-lifed|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. > Drop Tomcat 5.5 support > ------------------------ > > Key: ARQ-1853 > URL: https://issues.jboss.org/browse/ARQ-1853 > Project: Arquillian > Issue Type: Task > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Priority: Optional > > I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: > * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based, but that introduced a dependency conflict on the Servlet APIs. > * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. > I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-lifed|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. > Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:19:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:19:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1853) Drop Tomcat 5.5 support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt reassigned ARQ-1853: ------------------------------- Assignee: Ian Brandt > Drop Tomcat 5.5 support > ------------------------ > > Key: ARQ-1853 > URL: https://issues.jboss.org/browse/ARQ-1853 > Project: Arquillian > Issue Type: Task > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Priority: Optional > > I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: > * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based, but that introduced a dependency conflict on the Servlet APIs. > * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. > I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-lifed|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. > Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:20:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:20:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1853) Drop Tomcat 5.5 support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1853: ---------------------------- Fix Version/s: tomcat_1.0.0.Final > Drop Tomcat 5.5 support > ------------------------ > > Key: ARQ-1853 > URL: https://issues.jboss.org/browse/ARQ-1853 > Project: Arquillian > Issue Type: Task > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Priority: Optional > Fix For: tomcat_1.0.0.Final > > > I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: > * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based, but that introduced a dependency conflict on the Servlet APIs. > * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. > I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-lifed|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. > Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:23:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:23:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-597) Add a Tomcat managed 5.5 container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002134#comment-13002134 ] Ian Brandt commented on ARQ-597: -------------------------------- Is this container still needed? I'm hoping to drop support for it going forward per ARQ-1853. If there are any objections please comment on that issue. > Add a Tomcat managed 5.5 container > ---------------------------------- > > Key: ARQ-597 > URL: https://issues.jboss.org/browse/ARQ-597 > Project: Arquillian > Issue Type: Task > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR1 > Reporter: Karel Piwko > Assignee: Juraj H?ska > Priority: Critical > Fix For: tomcat_1.0.0.CR2 > > > Tomcat 5.5 support is crucial for EWS, hence critical priority. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:24:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:24:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1853) Drop Tomcat 5.5 support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1853: ---------------------------- Description: I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based, but that introduced a dependency conflict on the Servlet APIs. * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-life'd|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. was: I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based, but that introduced a dependency conflict on the Servlet APIs. * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-lifed|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. > Drop Tomcat 5.5 support > ------------------------ > > Key: ARQ-1853 > URL: https://issues.jboss.org/browse/ARQ-1853 > Project: Arquillian > Issue Type: Task > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Priority: Optional > Fix For: tomcat_1.0.0.Final > > > I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: > * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based, but that introduced a dependency conflict on the Servlet APIs. > * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. > I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-life'd|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. > Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:25:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:25:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1853) Drop Tomcat 5.5 support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1853: ---------------------------- Description: I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based. That introduces a dependency conflict on the Servlet APIs. * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-life'd|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. was: I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based, but that introduced a dependency conflict on the Servlet APIs. * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-life'd|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. > Drop Tomcat 5.5 support > ------------------------ > > Key: ARQ-1853 > URL: https://issues.jboss.org/browse/ARQ-1853 > Project: Arquillian > Issue Type: Task > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Priority: Optional > Fix For: tomcat_1.0.0.Final > > > I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: > * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based. That introduces a dependency conflict on the Servlet APIs. > * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. > I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-life'd|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. > Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 11:26:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 14 Sep 2014 11:26:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1853) Drop Tomcat 5.5 support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1853: ---------------------------- Description: I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based. That introduces a dependency conflict on the Servlet APIs. * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-life'd|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. Please add your comments below if you disagree. was: I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based. That introduces a dependency conflict on the Servlet APIs. * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-life'd|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. > Drop Tomcat 5.5 support > ------------------------ > > Key: ARQ-1853 > URL: https://issues.jboss.org/browse/ARQ-1853 > Project: Arquillian > Issue Type: Task > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Priority: Optional > Fix For: tomcat_1.0.0.Final > > > I'm working on further DRY'ing up the Tomcat container code, continuing the work done in ARQ-598 and ARQ-600. The Tomcat 5.5 managed container is the only Tomcat 5.5.x container that has been requested or implemented (per ARQ-597), and it's a bit different from the others: > * Tomcat 5.5.x implements the [the Servlet 2.4 spec|http://tomcat.apache.org/whichversion.html]. The earliest Arquillian protocol is [Servlet 2.5|https://docs.jboss.org/author/display/ARQ/Servlet+2.5]. While the Arquillian Servlet 2.5 protocol has been shown to work with Tomcat 5.5.x, the test archives themselves should really be Servlet 2.4-based. That introduces a dependency conflict on the Servlet APIs. > * It's not supported by any version of Weld, which means its injection tests and related dependencies are different from those of every other Tomcat container implementation. > I'm finding these subtle differences are introducing impediments to sharing test and POM code between this particular container implementation and all the others. With extra effort I'm sure I can achieve some degree of reuse, and otherwise this container could just fork it's own code, but I have to question whether either is worth the trouble? [Tomcat 5.5 was end-of-life'd|http://tomcat.apache.org/tomcat-55-eol.html] two years ago now. > Short of any strong objections I propose we drop support for this container going forward to better focus on Tomcat 6, 7 and 8. Anyone still using Tomcat 5.5 with Arquillian could continue to do so with [org.jboss.arquillian.container:arquillian-tomcat-managed-5.5:1.0.0.CR7|http://search.maven.org/#artifactdetails%7Corg.jboss.arquillian.container%7Carquillian-tomcat-managed-5.5%7C1.0.0.CR7%7Cjar] or earlier. Please add your comments below if you disagree. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:32:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 15 Sep 2014 09:32:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-459) Allow to load Page Extensions from within deployment In-Reply-To: References: Message-ID: Luk?? Fry? created ARQGRA-459: --------------------------------- Summary: Allow to load Page Extensions from within deployment Key: ARQGRA-459 URL: https://issues.jboss.org/browse/ARQGRA-459 Project: Arquillian Graphene Issue Type: Feature Request Reporter: Luk?? Fry? Allows for debuggability -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:32:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 15 Sep 2014 09:32:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-459) Allow to load Page Extensions from within WAR deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-459: ------------------------------ Summary: Allow to load Page Extensions from within WAR deployment (was: Allow to load Page Extensions from within deployment) > Allow to load Page Extensions from within WAR deployment > -------------------------------------------------------- > > Key: ARQGRA-459 > URL: https://issues.jboss.org/browse/ARQGRA-459 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > > Allows for debuggability -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:33:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 15 Sep 2014 09:33:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-459) Allow to load Page Extensions from within WAR deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002375#comment-13002375 ] Luk?? Fry? commented on ARQGRA-459: ----------------------------------- Implementation base: https://github.com/arquillian/arquillian-graphene/tree/ARQGRA-459-load-page-extensions-from-war > Allow to load Page Extensions from within WAR deployment > -------------------------------------------------------- > > Key: ARQGRA-459 > URL: https://issues.jboss.org/browse/ARQGRA-459 > Project: Arquillian Graphene > Issue Type: Feature Request > Affects Versions: 2.0.0.Final > Reporter: Luk?? Fry? > > Allows for debuggability -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:33:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 15 Sep 2014 09:33:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-459) Allow to load Page Extensions from within WAR deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-459: ------------------------------ Affects Version/s: 2.0.0.Final > Allow to load Page Extensions from within WAR deployment > -------------------------------------------------------- > > Key: ARQGRA-459 > URL: https://issues.jboss.org/browse/ARQGRA-459 > Project: Arquillian Graphene > Issue Type: Feature Request > Affects Versions: 2.0.0.Final > Reporter: Luk?? Fry? > > Allows for debuggability -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:59:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 15 Sep 2014 09:59:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-460) Introduce Graphene.log page extension, than enables to log to browser console (both, from Java and JavaScript code) In-Reply-To: References: Message-ID: Luk?? Fry? created ARQGRA-460: --------------------------------- Summary: Introduce Graphene.log page extension, than enables to log to browser console (both, from Java and JavaScript code) Key: ARQGRA-460 URL: https://issues.jboss.org/browse/ARQGRA-460 Project: Arquillian Graphene Issue Type: Feature Request Reporter: Luk?? Fry? Enable services like XHRInterceptor, RequestGuard and XHRHalter to log via Graphene.log. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:49:02 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 15 Sep 2014 10:49:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1854) Support injecting rules on container side when running on client In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1854: ---------------------------------- Summary: Support injecting rules on container side when running on client Key: ARQ-1854 URL: https://issues.jboss.org/browse/ARQ-1854 Project: Arquillian Issue Type: Feature Request Components: Extension - Byteman Affects Versions: byteman_1.0.0.Alpha2 Reporter: Aslak Knutsen -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:20:03 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 15 Sep 2014 11:20:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1854) Support injecting rules on container side when running on client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1854: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-byteman/pull/4 > Support injecting rules on container side when running on client > ---------------------------------------------------------------- > > Key: ARQ-1854 > URL: https://issues.jboss.org/browse/ARQ-1854 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Byteman > Affects Versions: byteman_1.0.0.Alpha2 > Reporter: Aslak Knutsen > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:21:03 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 15 Sep 2014 11:21:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1854) Support injecting rules on container side when running on client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1854: ------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Ales Justin Fix Version/s: byteman_1.0.0.Alpha3 Resolution: Done > Support injecting rules on container side when running on client > ---------------------------------------------------------------- > > Key: ARQ-1854 > URL: https://issues.jboss.org/browse/ARQ-1854 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Byteman > Affects Versions: byteman_1.0.0.Alpha2 > Reporter: Aslak Knutsen > Assignee: Ales Justin > Fix For: byteman_1.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:23:02 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 15 Sep 2014 11:23:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1441) Binding value from @BMRule is ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1441: ------------------------------- Fix Version/s: byteman_1.0.0.Alpha3 (was: byteman_1.0.0.next) > Binding value from @BMRule is ignored > -------------------------------------- > > Key: ARQ-1441 > URL: https://issues.jboss.org/browse/ARQ-1441 > Project: Arquillian > Issue Type: Bug > Components: Extension - Byteman > Affects Versions: byteman_1.0.0.Alpha2 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: byteman_1.0.0.Alpha3 > > > Byteman extension does not use binding part to make it a part of the rule. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:23:03 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 15 Sep 2014 11:23:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1442) Update Arquillian Core, Byteman and Container versions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1442: ------------------------------- Fix Version/s: byteman_1.0.0.Alpha3 (was: byteman_1.0.0.next) > Update Arquillian Core, Byteman and Container versions > ------------------------------------------------------ > > Key: ARQ-1442 > URL: https://issues.jboss.org/browse/ARQ-1442 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Byteman > Affects Versions: byteman_1.0.0.Alpha2 > Reporter: Karel Piwko > Fix For: byteman_1.0.0.Alpha3 > > > Update components in the extension with recent versions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:26:02 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 15 Sep 2014 11:26:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1442) Update Arquillian Core, Byteman and Container versions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1442. ------------------------------ > Update Arquillian Core, Byteman and Container versions > ------------------------------------------------------ > > Key: ARQ-1442 > URL: https://issues.jboss.org/browse/ARQ-1442 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Byteman > Affects Versions: byteman_1.0.0.Alpha2 > Reporter: Karel Piwko > Fix For: byteman_1.0.0.Alpha3 > > > Update components in the extension with recent versions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:26:02 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 15 Sep 2014 11:26:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1441) Binding value from @BMRule is ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1441. ------------------------------ > Binding value from @BMRule is ignored > -------------------------------------- > > Key: ARQ-1441 > URL: https://issues.jboss.org/browse/ARQ-1441 > Project: Arquillian > Issue Type: Bug > Components: Extension - Byteman > Affects Versions: byteman_1.0.0.Alpha2 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: byteman_1.0.0.Alpha3 > > > Byteman extension does not use binding part to make it a part of the rule. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:26:02 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 15 Sep 2014 11:26:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1854) Support injecting rules on container side when running on client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1854. ------------------------------ > Support injecting rules on container side when running on client > ---------------------------------------------------------------- > > Key: ARQ-1854 > URL: https://issues.jboss.org/browse/ARQ-1854 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Byteman > Affects Versions: byteman_1.0.0.Alpha2 > Reporter: Aslak Knutsen > Assignee: Ales Justin > Fix For: byteman_1.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 03:20:02 2014 From: issues at jboss.org (Alex Soto (JIRA)) Date: Tue, 16 Sep 2014 03:20:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-461) Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. In-Reply-To: References: Message-ID: Alex Soto created ARQGRA-461: -------------------------------- Summary: Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. Key: ARQGRA-461 URL: https://issues.jboss.org/browse/ARQGRA-461 Project: Arquillian Graphene Issue Type: Bug Reporter: Alex Soto Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 03:27:03 2014 From: issues at jboss.org (Alex Soto (JIRA)) Date: Tue, 16 Sep 2014 03:27:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-461) Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Soto updated ARQGRA-461: ----------------------------- Description: Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. Basically the problem is when you want to get information about tables. You can iterate over elements in a foreach fashion, but you can also use new Java 8 stream API. This works: ession.findElements(xpath("//table/tbody/tr/td/span[@class='title']")).stream().map(WebElement::getText).collect(Collectors.toList()); But if table is big you will try to improve parsing speed by adding parallelSteam (session.findElements(xpath("//table/tbody/tr/td/span[@class='title']")).parallelStream().map(WebElement::getText).collect(Collectors.toList());) And in this case an exception is thrown. Internally parallelStream uses a pool of threads so probably Graphene instance is tight to thread of test case, so the threads used by parallelStream does not contains a valid instance of Graphene. Of course this is not blocking nor a big problem in the sense that you can use stream() without any problem, and moreover Java 8 is not spread yet, but it may be a problem in the future. Steps to Reproduce: Create a Graphene Page object which uses a WebElement inside a parallelStream. Labels: java8, threads (was: ) Workaround Description: Although you cannot use parallelStream() you can use stream() method. Workaround: Workaround Exists > Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-461 > URL: https://issues.jboss.org/browse/ARQGRA-461 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Alex Soto > Priority: Minor > Labels: java8,, threads > > Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. > Basically the problem is when you want to get information about tables. You can iterate over elements in a foreach fashion, but you can also use new Java 8 stream API. > This works: ession.findElements(xpath("//table/tbody/tr/td/span[@class='title']")).stream().map(WebElement::getText).collect(Collectors.toList()); > But if table is big you will try to improve parsing speed by adding parallelSteam (session.findElements(xpath("//table/tbody/tr/td/span[@class='title']")).parallelStream().map(WebElement::getText).collect(Collectors.toList());) > And in this case an exception is thrown. > Internally parallelStream uses a pool of threads so probably Graphene instance is tight to thread of test case, so the threads used by parallelStream does not contains a valid instance of Graphene. > Of course this is not blocking nor a big problem in the sense that you can use stream() without any problem, and moreover Java 8 is not spread yet, but it may be a problem in the future. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 06:10:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 16 Sep 2014 06:10:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-461) Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002737#comment-13002737 ] Luk?? Fry? commented on ARQGRA-461: ----------------------------------- Hey Alex, this behavior is expectable as {{parallelStream()}} causes the collection to evaluate outside of parental thread. You will end up with same issues for lot of Arquillian extensions. ---- In fact I think you won't get much gain with {{parallelStream()}} since the Selenium itself is likely serializing requests. *Idea:* In order to speed up bulk operations, you can use JavaScript-based retrieval logic (JavaScript can return JSON of table structure that you can parse on server-side). > Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-461 > URL: https://issues.jboss.org/browse/ARQGRA-461 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Alex Soto > Priority: Minor > Labels: java8,, threads > > Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. > Basically the problem is when you want to get information about tables. You can iterate over elements in a foreach fashion, but you can also use new Java 8 stream API. > This works: ession.findElements(xpath("//table/tbody/tr/td/span[@class='title']")).stream().map(WebElement::getText).collect(Collectors.toList()); > But if table is big you will try to improve parsing speed by adding parallelSteam (session.findElements(xpath("//table/tbody/tr/td/span[@class='title']")).parallelStream().map(WebElement::getText).collect(Collectors.toList());) > And in this case an exception is thrown. > Internally parallelStream uses a pool of threads so probably Graphene instance is tight to thread of test case, so the threads used by parallelStream does not contains a valid instance of Graphene. > Of course this is not blocking nor a big problem in the sense that you can use stream() without any problem, and moreover Java 8 is not spread yet, but it may be a problem in the future. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 06:27:02 2014 From: issues at jboss.org (Alex Soto (JIRA)) Date: Tue, 16 Sep 2014 06:27:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-461) Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002748#comment-13002748 ] Alex Soto commented on ARQGRA-461: ---------------------------------- Well in my case I can run with stream because there is no problem at all. But I have tried to calculate it and I have found this exception and I decided to report it. Maybe you can close it, but at least if anyone find the same exception in near future, the "solution" is documented somewhere. > Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-461 > URL: https://issues.jboss.org/browse/ARQGRA-461 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Alex Soto > Priority: Minor > Labels: java8,, threads > > Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. > Basically the problem is when you want to get information about tables. You can iterate over elements in a foreach fashion, but you can also use new Java 8 stream API. > This works: ession.findElements(xpath("//table/tbody/tr/td/span[@class='title']")).stream().map(WebElement::getText).collect(Collectors.toList()); > But if table is big you will try to improve parsing speed by adding parallelSteam (session.findElements(xpath("//table/tbody/tr/td/span[@class='title']")).parallelStream().map(WebElement::getText).collect(Collectors.toList());) > And in this case an exception is thrown. > Internally parallelStream uses a pool of threads so probably Graphene instance is tight to thread of test case, so the threads used by parallelStream does not contains a valid instance of Graphene. > Of course this is not blocking nor a big problem in the sense that you can use stream() without any problem, and moreover Java 8 is not spread yet, but it may be a problem in the future. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 07:47:03 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 16 Sep 2014 07:47:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-462) Polish AjaxHalter API In-Reply-To: References: Message-ID: Juraj H?ska created ARQGRA-462: ---------------------------------- Summary: Polish AjaxHalter API Key: ARQGRA-462 URL: https://issues.jboss.org/browse/ARQGRA-462 Project: Arquillian Graphene Issue Type: Feature Request Components: api, core Affects Versions: 2.1.0.Alpha2 Reporter: Juraj H?ska The API for AjaxHalter was porter from XHRHalter in Graphene1. We talked about polishing it based on the community feedback after releasing {{2.1.0.Alpha2}}. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 07:47:03 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 16 Sep 2014 07:47:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-462) Polish AjaxHalter API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated ARQGRA-462: ------------------------------- Description: The API for {{AjaxHalter}} was ported from {{XHRHalter}} in _Graphene1_. We talked about polishing it based on the community feedback after releasing {{2.1.0.Alpha2}}. was: The API for AjaxHalter was porter from XHRHalter in Graphene1. We talked about polishing it based on the community feedback after releasing {{2.1.0.Alpha2}}. > Polish AjaxHalter API > --------------------- > > Key: ARQGRA-462 > URL: https://issues.jboss.org/browse/ARQGRA-462 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: api, core > Affects Versions: 2.1.0.Alpha2 > Reporter: Juraj H?ska > > The API for {{AjaxHalter}} was ported from {{XHRHalter}} in _Graphene1_. > We talked about polishing it based on the community feedback after releasing {{2.1.0.Alpha2}}. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 00:09:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Wed, 17 Sep 2014 00:09:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1855) Tomcat 6 Embedded container should support deployment of ROOT.war to the default context In-Reply-To: References: Message-ID: Ian Brandt created ARQ-1855: ------------------------------- Summary: Tomcat 6 Embedded container should support deployment of ROOT.war to the default context Key: ARQ-1855 URL: https://issues.jboss.org/browse/ARQ-1855 Project: Arquillian Issue Type: Feature Request Components: Tomcat Containers Affects Versions: tomcat_1.0.0.CR7 Reporter: Ian Brandt -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 00:09:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Wed, 17 Sep 2014 00:09:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1855) Tomcat 6 Embedded container should support deployment of ROOT.war to the default context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt reassigned ARQ-1855: ------------------------------- Assignee: Ian Brandt > Tomcat 6 Embedded container should support deployment of ROOT.war to the default context > ---------------------------------------------------------------------------------------- > > Key: ARQ-1855 > URL: https://issues.jboss.org/browse/ARQ-1855 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 00:10:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Wed, 17 Sep 2014 00:10:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1855) Tomcat 6 Embedded container should support deployment of ROOT.war to the default context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1855: ---------------------------- Fix Version/s: tomcat_1.0.0.Final > Tomcat 6 Embedded container should support deployment of ROOT.war to the default context > ---------------------------------------------------------------------------------------- > > Key: ARQ-1855 > URL: https://issues.jboss.org/browse/ARQ-1855 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 00:10:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Wed, 17 Sep 2014 00:10:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1855) Tomcat 6 Embedded container should support deployment of ROOT.war to the default context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1855 started by Ian Brandt. --------------------------------------- > Tomcat 6 Embedded container should support deployment of ROOT.war to the default context > ---------------------------------------------------------------------------------------- > > Key: ARQ-1855 > URL: https://issues.jboss.org/browse/ARQ-1855 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 01:05:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Wed, 17 Sep 2014 01:05:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1855) Tomcat 6 Embedded container should support deployment of ROOT.war to the default context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt resolved ARQ-1855. ----------------------------- Resolution: Done Fixed by https://github.com/arquillian/arquillian-container-tomcat/commit/191e504777f261d47670bc6e672506658f0d14c3. > Tomcat 6 Embedded container should support deployment of ROOT.war to the default context > ---------------------------------------------------------------------------------------- > > Key: ARQ-1855 > URL: https://issues.jboss.org/browse/ARQ-1855 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 19:13:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Thu, 18 Sep 2014 19:13:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1619) Tomcat managed container ignores allowConnectingToRunningServer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt reassigned ARQ-1619: ------------------------------- Assignee: Ian Brandt > Tomcat managed container ignores allowConnectingToRunningServer > --------------------------------------------------------------- > > Key: ARQ-1619 > URL: https://issues.jboss.org/browse/ARQ-1619 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR5 > Reporter: Thomas Diesler > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > The flag is not checked > {code} > if(manager.isRunning()) > { > throw new LifecycleException( > "The server is already running! " + > "Managed containers does not support connecting to running server instances due to the " + > "possible harmful effect of connecting to the wrong server. Please stop server before running or " + > "change to another type of container.\n" + > "To disable this check and allow Arquillian to connect to a running server, " + > "set allowConnectingToRunningServer to true in the container configuration" > ); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 19:13:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Thu, 18 Sep 2014 19:13:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1619) Tomcat managed container ignores allowConnectingToRunningServer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1619: ---------------------------- Fix Version/s: tomcat_1.0.0.Final > Tomcat managed container ignores allowConnectingToRunningServer > --------------------------------------------------------------- > > Key: ARQ-1619 > URL: https://issues.jboss.org/browse/ARQ-1619 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR5 > Reporter: Thomas Diesler > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > The flag is not checked > {code} > if(manager.isRunning()) > { > throw new LifecycleException( > "The server is already running! " + > "Managed containers does not support connecting to running server instances due to the " + > "possible harmful effect of connecting to the wrong server. Please stop server before running or " + > "change to another type of container.\n" + > "To disable this check and allow Arquillian to connect to a running server, " + > "set allowConnectingToRunningServer to true in the container configuration" > ); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 21 21:00:04 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 21 Sep 2014 21:00:04 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1848) Tomcat managed containers should start and stop Tomcat using the standard run scripts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004536#comment-13004536 ] Ian Brandt commented on ARQ-1848: --------------------------------- [~sfcoy]: Thanks for the feedback. I made an effort to DRY up most of the codebase. It's not 100% yet, but I think I've made a substantial dent. I have a few more TODOs in mind, but I can tell tunnel vision is starting to set in. I'd welcome any ideas you might have for further cleanup. I chatted with [~aslak] on IRC, and he was ok with having a go at this JIRA for a 1.0.0.CR8 release on the condition that I maintain backwards compatibility. I've attempted to do just that, and pushed a first draft to https://github.com/arquillian/arquillian-container-tomcat/tree/ARQ-1848. This branch includes all the cleanup done on [master|https://github.com/arquillian/arquillian-container-tomcat/tree/master]. I'll be testing and tidying this branch up during the coming week. I don't readily have a way to test on Windows, so I could use help with that if anyone is available. Of course any other feedback or concerns are also welcomed. > Tomcat managed containers should start and stop Tomcat using the standard run scripts > ------------------------------------------------------------------------------------- > > Key: ARQ-1848 > URL: https://issues.jboss.org/browse/ARQ-1848 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > The [standard Tomcat run scripts|http://tomcat.apache.org/tomcat-8.0-doc/RUNNING.txt] contain a fair little bit of logic and features: > * Multiple instance support (requiring the proper merging of resources from {{CATALINA_BASE}} and {{CATALINA_HOME}}). > * Logging configuration. > * Running with or without a security manager. > * Support for configuration in the 'setenv' script. > * Endorsed and temp directory configuration. > * Launching with JPDA related configuration. > * OS variant and TTY related configuration on UNIX. > By building the Java command to launch Tomcat directly the current {{CommonTomcatManagedContainer}} forgoes the standard implementation of all this. There is a growing history of bug reports and feature requests that suggest this may not be the best approach: > * ARQ-628 - Tomcat managed throws NullPointerException when application under test brings weld-servlet dependency > * ARQ-866 - Allow catalina.base to be configured separately from catalina.home in the Tomcat managed adapters > * ARQ-1650 - Managed container bypasses tomcat jul setup > * ARQ-1843 - Tomcat managed container ignores javaHome configuration > * ARQ-1846 - Support configuration of the Tomcat system classpath from managed containers > * ARQ-1847 - Support specifying JMX RMI server port > Rather than reinventing the wheel here, we should just launch and stop Tomcat with the standard run script for the current OS, exposing it's environment variable-driven configuration via arquillian.xml and the {{CommonTomcatManagedConfiguration}}. This will: > * Add all the missing features and logic. > * Be simpler and presumably cheaper to maintain over trying to mirror the standard scripts. > * Encourage better fidelity between managed containers and their production counterparts (e.g. identical {{CATALINA_BASE}} and {{CATALINA_HOME}} merging, as well as setenv script support). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 21 21:01:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 21 Sep 2014 21:01:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt updated ARQ-1846: ---------------------------- Fix Version/s: (was: tomcat_1.0.0.Final) > Support configuration of the Tomcat system classpath from managed containers > ---------------------------------------------------------------------------- > > Key: ARQ-1846 > URL: https://issues.jboss.org/browse/ARQ-1846 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > > In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 21 21:03:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 21 Sep 2014 21:03:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt resolved ARQ-1846. ----------------------------- Resolution: Duplicate Issue Considering this as superseded by ARQ-1848 and resolving as a duplicate. > Support configuration of the Tomcat system classpath from managed containers > ---------------------------------------------------------------------------- > > Key: ARQ-1846 > URL: https://issues.jboss.org/browse/ARQ-1846 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > > In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 21 21:05:02 2014 From: issues at jboss.org (Ian Brandt (JIRA)) Date: Sun, 21 Sep 2014 21:05:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Brandt closed ARQ-1846. --------------------------- > Support configuration of the Tomcat system classpath from managed containers > ---------------------------------------------------------------------------- > > Key: ARQ-1846 > URL: https://issues.jboss.org/browse/ARQ-1846 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > > In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 07:46:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 07:46:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-427) Support for AngularJS locators and interaction synchronization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004677#comment-13004677 ] Luk?? Fry? commented on ARQGRA-427: ----------------------------------- This is enabled by extension https://github.com/arquillian/arquillian-extension-angularjs > Support for AngularJS locators and interaction synchronization > -------------------------------------------------------------- > > Key: ARQGRA-427 > URL: https://issues.jboss.org/browse/ARQGRA-427 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Luk?? Fry? > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 07:47:03 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 07:47:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-427) Support for AngularJS locators and interaction synchronization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? closed ARQGRA-427. ----------------------------- Assignee: Luk?? Fry? Resolution: Out of Date > Support for AngularJS locators and interaction synchronization > -------------------------------------------------------------- > > Key: ARQGRA-427 > URL: https://issues.jboss.org/browse/ARQGRA-427 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 07:49:03 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 07:49:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-409) Support for Ember.js In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004682#comment-13004682 ] Luk?? Fry? commented on ARQGRA-409: ----------------------------------- [~smikloso] [~kpiwko] I believe this extension is not requires at this point? Can I resolve this and see whether there will be a need for that in the future? > Support for Ember.js > -------------------- > > Key: ARQGRA-409 > URL: https://issues.jboss.org/browse/ARQGRA-409 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.0.Final > Reporter: Karel Piwko > > Ember.js dynamically updates view based on various action. This makes usage of locators and guards pretty complicated. > It would be great it Graphene could provide: > * A way how to stability ids for elements in DOM generated as a part of view > * Guards that are able to guard DOM update without any request. > [~smikloso] can provide more details, additional discussions at: > http://stackoverflow.com/questions/12933422/ember-best-practices-with-selenium-to-make-integration-tests-in-browser > http://stackoverflow.com/questions/16639384/how-to-test-a-javascript-based-application-for-example-ember-js-with-selenium-2 > I believe that such tools might be handy for angular.js testing as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 07:50:03 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 07:50:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-411) GrapheneElement methods should wait until element is present In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-411. ------------------------------- Assignee: Luk?? Fry? Resolution: Incomplete Description > GrapheneElement methods should wait until element is present > ------------------------------------------------------------ > > Key: ARQGRA-411 > URL: https://issues.jboss.org/browse/ARQGRA-411 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Emil Cervenan > Assignee: Luk?? Fry? > > Scenarios when element is generated by javascript and performance is low leads to situations when method of element which is not present is called. Unwanted exception is thrown. When you are trying to simulate users behaviour it is clear you are not expecting clicking, typing and so on to elements which are not present. Therefore each GrapheneElement method should wait until element is present. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 07:54:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 07:54:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-461) Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-461. ------------------------------- Assignee: Luk?? Fry? Resolution: Rejected Agree, {{parallelStream()}} is in Selenium / Graphene 2.x a misuse that is expected to lead into threading issues. If there would be really an elevated need, we may re-consider allowing such a usage by propagating contexts. Thanks for describing the issue though, Alex, at least for future reference, as you say! > Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-461 > URL: https://issues.jboss.org/browse/ARQGRA-461 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Alex Soto > Assignee: Luk?? Fry? > Priority: Minor > Labels: java8,, threads > > Running Graphene tests and use parallelStream method makes test fail with java.lang.IllegalStateException: The Graphene runtime isn't initialized. Exception. > Basically the problem is when you want to get information about tables. You can iterate over elements in a foreach fashion, but you can also use new Java 8 stream API. > This works: ession.findElements(xpath("//table/tbody/tr/td/span[@class='title']")).stream().map(WebElement::getText).collect(Collectors.toList()); > But if table is big you will try to improve parsing speed by adding parallelSteam (session.findElements(xpath("//table/tbody/tr/td/span[@class='title']")).parallelStream().map(WebElement::getText).collect(Collectors.toList());) > And in this case an exception is thrown. > Internally parallelStream uses a pool of threads so probably Graphene instance is tight to thread of test case, so the threads used by parallelStream does not contains a valid instance of Graphene. > Of course this is not blocking nor a big problem in the sense that you can use stream() without any problem, and moreover Java 8 is not spread yet, but it may be a problem in the future. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 07:54:03 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 07:54:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-430) Setup continous integration of 2.1 branch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-430. ------------------------------- Assignee: Luk?? Fry? Resolution: Won't Fix > Setup continous integration of 2.1 branch > ----------------------------------------- > > Key: ARQGRA-430 > URL: https://issues.jboss.org/browse/ARQGRA-430 > Project: Arquillian Graphene > Issue Type: Task > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 07:54:03 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 07:54:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-415) Cloudbees matrix job fails with NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-415. ------------------------------- Assignee: Luk?? Fry? Resolution: Won't Fix > Cloudbees matrix job fails with NPE > ----------------------------------- > > Key: ARQGRA-415 > URL: https://issues.jboss.org/browse/ARQGRA-415 > Project: Arquillian Graphene > Issue Type: Task > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > > https://arquillian.ci.cloudbees.com/job/arquillian-graphene-webdriver-ftest-browsers/ > {code} > Error Message > Could not invoke deployment method: public static org.jboss.shrinkwrap.api.spec.WebArchive org.jboss.arquillian.graphene.ftest.condition.ConditionsTestCase.createTestArchive() > Stacktrace > java.lang.RuntimeException: Could not invoke deployment method: public static org.jboss.shrinkwrap.api.spec.WebArchive org.jboss.arquillian.graphene.ftest.condition.ConditionsTestCase.createTestArchive() > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.invoke(AnnotationDeploymentScenarioGenerator.java:177) > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generateDeployment(AnnotationDeploymentScenarioGenerator.java:99) > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generate(AnnotationDeploymentScenarioGenerator.java:62) > at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:100) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.invoke(AnnotationDeploymentScenarioGenerator.java:173) > ... 54 more > Caused by: java.lang.NullPointerException > at org.jboss.arquillian.graphene.ftest.Resource$ResourceBuilder.all(Resource.java:81) > at org.jboss.arquillian.graphene.ftest.Resources.all(Resources.java:65) > at org.jboss.arquillian.graphene.ftest.condition.ConditionsTestCase.createTestArchive(ConditionsTestCase.java:79) > ... 59 more > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:00:21 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:00:21 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-438) Using multiple qualifiers for @Page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004688#comment-13004688 ] Luk?? Fry? commented on ARQGRA-438: ----------------------------------- [~smikloso] currently a Graphene handler is injected with static knowledge about the injection point - i.e. it knows what qualifier and what type was requested. You would need to change this knowledge on per-test basis, i.e. before {{test()}} proceeds, you need to set up that SomePage should use @OperatesOnDeployment. TBH I don't believe this feature is enough needed to support it, but I would certainly help you if it is big enough for you that you would like to implement it at own and contribute it to Graphene. > Using multiple qualifiers for @Page > ----------------------------------- > > Key: ARQGRA-438 > URL: https://issues.jboss.org/browse/ARQGRA-438 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.1-Tracking > Reporter: Stefan Miklosovic > Priority: Optional > > In case I have one application deployed to multiple devices (apks to Android) and I use @Page abstraction, I end up with this: > {code} > @Drone @Mobile AndroidDriver mobile; > @Drone @Tablet AndroidDriver tablet; > @Page @Mobile SomePage mobilePage; > @Page @Tablet SomePage tabletPage; > {code} > Event that page is same I have to declare it twice. It could be done as > {code} > @Page @Mobile @Tablet SomePage page; > {code} > In this case, there has to be some distinction between webdrivers and it seems this could be done on deployment level when you use @OperatesOnDeployment annotaion on webdriver injection. In case you have some test method which uses the same @OperatesOnDeployment value, Graphene will inject "right" driver to handle that @Page bean. > Example: > {code} > @Drone @Tablet @OperatesOnDeployment("android_1") AndroidDriver tablet; > @Drone @Mobile @OperatesOnDeployment("android_2") AndroidDriver mobile; > @Page @Tablet @Mobile SomePage somePage; > @Test > @OperatesOnDeployment("android_1") > public void test() > { > somePage will be backed by @Tablet browser > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:01:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:01:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-417) Support for automatic scrolling to element before its usage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-417: ------------------------------ Fix Version/s: 2.1-Tracking > Support for automatic scrolling to element before its usage > ----------------------------------------------------------- > > Key: ARQGRA-417 > URL: https://issues.jboss.org/browse/ARQGRA-417 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Priority: Minor > Fix For: 2.1-Tracking > > > It would be nice if Graphene supports automatic scrolling of browser window to {{WebElement}} / Page Fragment before its is used. > It can be useful for interactions with various popups web components: contextMenu, tooltip, ... > Those components can not be interacted correctly when they are not in the viewport, and thus one needs to scroll to them manually in his test. > It is often problem in CI environment, where tests run on screens with lower resolution (smaller part of the page fit the browser window, and lot of elements are not in the viewport). > My naive implementation of this would look like: > * intercept all calls to {{WebElements}} and PageFragments root elements > * in the interceptor method get the location of the element by: {{Point location = element.getLocation();}} > * a then scroll to it: {{jsExecutor.executeScript("window.scrollTo("" + location.getX() +", " + location.getY() + ")");}} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:02:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:02:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-417) Support for automatic scrolling to element before its usage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004691#comment-13004691 ] Luk?? Fry? commented on ARQGRA-417: ----------------------------------- This would be very useful for ScreenShooter extension as well. > Support for automatic scrolling to element before its usage > ----------------------------------------------------------- > > Key: ARQGRA-417 > URL: https://issues.jboss.org/browse/ARQGRA-417 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Priority: Minor > Fix For: 2.1-Tracking > > > It would be nice if Graphene supports automatic scrolling of browser window to {{WebElement}} / Page Fragment before its is used. > It can be useful for interactions with various popups web components: contextMenu, tooltip, ... > Those components can not be interacted correctly when they are not in the viewport, and thus one needs to scroll to them manually in his test. > It is often problem in CI environment, where tests run on screens with lower resolution (smaller part of the page fit the browser window, and lot of elements are not in the viewport). > My naive implementation of this would look like: > * intercept all calls to {{WebElements}} and PageFragments root elements > * in the interceptor method get the location of the element by: {{Point location = element.getLocation();}} > * a then scroll to it: {{jsExecutor.executeScript("window.scrollTo("" + location.getX() +", " + location.getY() + ")");}} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:02:03 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:02:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-417) Support for automatic scrolling to element before its usage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004692#comment-13004692 ] Luk?? Fry? commented on ARQGRA-417: ----------------------------------- Graphene should be configured to do so. > Support for automatic scrolling to element before its usage > ----------------------------------------------------------- > > Key: ARQGRA-417 > URL: https://issues.jboss.org/browse/ARQGRA-417 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Priority: Minor > Fix For: 2.1-Tracking > > > It would be nice if Graphene supports automatic scrolling of browser window to {{WebElement}} / Page Fragment before its is used. > It can be useful for interactions with various popups web components: contextMenu, tooltip, ... > Those components can not be interacted correctly when they are not in the viewport, and thus one needs to scroll to them manually in his test. > It is often problem in CI environment, where tests run on screens with lower resolution (smaller part of the page fit the browser window, and lot of elements are not in the viewport). > My naive implementation of this would look like: > * intercept all calls to {{WebElements}} and PageFragments root elements > * in the interceptor method get the location of the element by: {{Point location = element.getLocation();}} > * a then scroll to it: {{jsExecutor.executeScript("window.scrollTo("" + location.getX() +", " + location.getY() + ")");}} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:02:03 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:02:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-462) Polish AjaxHalter API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-462: ------------------------------ Fix Version/s: 2.1-Tracking > Polish AjaxHalter API > --------------------- > > Key: ARQGRA-462 > URL: https://issues.jboss.org/browse/ARQGRA-462 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: api, core > Affects Versions: 2.1.0.Alpha2 > Reporter: Juraj H?ska > Fix For: 2.1-Tracking > > > The API for {{AjaxHalter}} was ported from {{XHRHalter}} in _Graphene1_. > We talked about polishing it based on the community feedback after releasing {{2.1.0.Alpha2}}. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:03:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:03:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-460) Introduce Graphene.log page extension, than enables to log to browser console (both, from Java and JavaScript code) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-460: ------------------------------ Fix Version/s: 2.1-Tracking > Introduce Graphene.log page extension, than enables to log to browser console (both, from Java and JavaScript code) > ------------------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-460 > URL: https://issues.jboss.org/browse/ARQGRA-460 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > Fix For: 2.1-Tracking > > > Enable services like XHRInterceptor, RequestGuard and XHRHalter to log via Graphene.log. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:03:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:03:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-440) Upgrade Drone to 2.0.0.Alpha1 and Arquillian core to 1.1.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-440: ------------------------------ Fix Version/s: 2.1.0.Alpha2 > Upgrade Drone to 2.0.0.Alpha1 and Arquillian core to 1.1.4 > ---------------------------------------------------------- > > Key: ARQGRA-440 > URL: https://issues.jboss.org/browse/ARQGRA-440 > Project: Arquillian Graphene > Issue Type: Task > Components: core > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj H?ska > Fix For: 2.1.0.Alpha2 > > > IMHO we should upgrade to new Drone {{2.0.0.Alpha1}} as well as to Arquillian core {{1.1.4.Final}} in a non stable 2.1.x branch to try compatibility with these versions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:04:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:04:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-440) Upgrade Drone to 2.0.0.Alpha1 and Arquillian core to 1.1.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004693#comment-13004693 ] Luk?? Fry? commented on ARQGRA-440: ----------------------------------- [~jhuska] does it make sense to upgrade to Drone 2.0 from RichFaces tests perspective? We should really help Drone test the compatibility. At least we could enable a profile that would help test Drone 2.0 compatibility. > Upgrade Drone to 2.0.0.Alpha1 and Arquillian core to 1.1.4 > ---------------------------------------------------------- > > Key: ARQGRA-440 > URL: https://issues.jboss.org/browse/ARQGRA-440 > Project: Arquillian Graphene > Issue Type: Task > Components: core > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj H?ska > Fix For: 2.1.0.Alpha2 > > > IMHO we should upgrade to new Drone {{2.0.0.Alpha1}} as well as to Arquillian core {{1.1.4.Final}} in a non stable 2.1.x branch to try compatibility with these versions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:05:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:05:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-434) Browser screenshooter acts only on @Default Drone In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-434: ------------------------------ Fix Version/s: 2.1-Tracking > Browser screenshooter acts only on @Default Drone > ------------------------------------------------- > > Key: ARQGRA-434 > URL: https://issues.jboss.org/browse/ARQGRA-434 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1-Tracking > Reporter: Stefan Miklosovic > Assignee: Juraj H?ska > Fix For: 2.1-Tracking > > > Browser screenshooter acts only on Drone instances which do not have any qualifier but @Default since current implementation does this check: > {code} > GrapheneContext.getContextFor(Default.class) > {code} > This usage prevents user to use screenshooter in multibrowser scenarios like having Android browser and ordinary Firefox browser in one test class since they can (and must) be differentiated by additional qualifier put on @Drone instances. > Check should be done on instance level and not on qualifier level - meaning we should take context of Drone with ordinary (not mobile) browser which can have any qualifier possible. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:08:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:08:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-458) Graphene can't be compiled in Maven 3.1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-458: ------------------------------ Fix Version/s: 2.1-Tracking > Graphene can't be compiled in Maven 3.1.1 > ----------------------------------------- > > Key: ARQGRA-458 > URL: https://issues.jboss.org/browse/ARQGRA-458 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Luk?? Fry? > Fix For: 2.1-Tracking > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:08:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:08:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-459) Allow to load Page Extensions from within WAR deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-459: ------------------------------ Fix Version/s: 2.1-Tracking > Allow to load Page Extensions from within WAR deployment > -------------------------------------------------------- > > Key: ARQGRA-459 > URL: https://issues.jboss.org/browse/ARQGRA-459 > Project: Arquillian Graphene > Issue Type: Feature Request > Affects Versions: 2.0.0.Final > Reporter: Luk?? Fry? > Fix For: 2.1-Tracking > > > Allows for debuggability -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:08:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:08:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-380) Debugging in Eclipse throw InvocationException when inspecting fields enriched by Graphene In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-380: ------------------------------ Fix Version/s: 2.1-Tracking > Debugging in Eclipse throw InvocationException when inspecting fields enriched by Graphene > ------------------------------------------------------------------------------------------ > > Key: ARQGRA-380 > URL: https://issues.jboss.org/browse/ARQGRA-380 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.0.Beta2 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Fix For: 2.1-Tracking > > > During debugging in Eclipse, when inspecting the values of the fields which are enriched by Graphene, an {{InvocationException}} is thrown. > We should investigate why it is so, and improve it if it is feasible. It can enhance the usability. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:09:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:09:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-426) Provide API for dynamic @Location In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-426: ------------------------------ Fix Version/s: 2.1-Tracking > Provide API for dynamic @Location > --------------------------------- > > Key: ARQGRA-426 > URL: https://issues.jboss.org/browse/ARQGRA-426 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Fix For: 2.1-Tracking > > > There are use cases when the same page object has different URLs. One of such use cases is described in [this|https://community.jboss.org/message/861996#861996] post. > To enhance re-usability, we should IMHO provide an API for dynamic @Location resolutions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:15:06 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 22 Sep 2014 08:15:06 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-409) Support for Ember.js In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004700#comment-13004700 ] Stefan Miklosovic commented on ARQGRA-409: ------------------------------------------ [~lfryc] +1 or resolving this > Support for Ember.js > -------------------- > > Key: ARQGRA-409 > URL: https://issues.jboss.org/browse/ARQGRA-409 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.0.Final > Reporter: Karel Piwko > > Ember.js dynamically updates view based on various action. This makes usage of locators and guards pretty complicated. > It would be great it Graphene could provide: > * A way how to stability ids for elements in DOM generated as a part of view > * Guards that are able to guard DOM update without any request. > [~smikloso] can provide more details, additional discussions at: > http://stackoverflow.com/questions/12933422/ember-best-practices-with-selenium-to-make-integration-tests-in-browser > http://stackoverflow.com/questions/16639384/how-to-test-a-javascript-based-application-for-example-ember-js-with-selenium-2 > I believe that such tools might be handy for angular.js testing as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:15:06 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 22 Sep 2014 08:15:06 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-409) Support for Ember.js In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004700#comment-13004700 ] Stefan Miklosovic edited comment on ARQGRA-409 at 9/22/14 8:14 AM: ------------------------------------------------------------------- [~lfryc] +1 on resolving this was (Author: smikloso): [~lfryc] +1 or resolving this > Support for Ember.js > -------------------- > > Key: ARQGRA-409 > URL: https://issues.jboss.org/browse/ARQGRA-409 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.0.Final > Reporter: Karel Piwko > > Ember.js dynamically updates view based on various action. This makes usage of locators and guards pretty complicated. > It would be great it Graphene could provide: > * A way how to stability ids for elements in DOM generated as a part of view > * Guards that are able to guard DOM update without any request. > [~smikloso] can provide more details, additional discussions at: > http://stackoverflow.com/questions/12933422/ember-best-practices-with-selenium-to-make-integration-tests-in-browser > http://stackoverflow.com/questions/16639384/how-to-test-a-javascript-based-application-for-example-ember-js-with-selenium-2 > I believe that such tools might be handy for angular.js testing as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:28:03 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:28:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-374) Allow to setup custom Location URL via arquillian.xml configuration with CustmizableURLResourceProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-374: ------------------------------ Summary: Allow to setup custom Location URL via arquillian.xml configuration with CustmizableURLResourceProvider (was: Allow to setup custom URL via arquillian.xml configuration with CustmizableURLResourceProvider) > Allow to setup custom Location URL via arquillian.xml configuration with CustmizableURLResourceProvider > ------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-374 > URL: https://issues.jboss.org/browse/ARQGRA-374 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > {code:xml} > > > http://localhost:8080/app/ > > > {code} > The provider will obtain URL from {{URLResourceProvider}} and use it if no other URL is provided. > Configuring this provider should also block deploying application, since its unnecessary. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:28:04 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:28:04 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-374) Allow to setup custom Location URL via arquillian.xml configuration with CustmizableURLResourceProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004710#comment-13004710 ] Luk?? Fry? commented on ARQGRA-374: ----------------------------------- Hey [~smikloso] have you made any progress here? > Allow to setup custom Location URL via arquillian.xml configuration with CustmizableURLResourceProvider > ------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-374 > URL: https://issues.jboss.org/browse/ARQGRA-374 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > {code:xml} > > > http://localhost:8080/app/ > > > {code} > The provider will obtain URL from {{URLResourceProvider}} and use it if no other URL is provided. > Configuring this provider should also block deploying application, since its unnecessary. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:29:04 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:29:04 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-374) Allow to setup custom Location URL via arquillian.xml configuration with CustomizableURLResourceProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-374: ------------------------------ Summary: Allow to setup custom Location URL via arquillian.xml configuration with CustomizableURLResourceProvider (was: Allow to setup custom Location URL via arquillian.xml configuration with CustmizableURLResourceProvider) > Allow to setup custom Location URL via arquillian.xml configuration with CustomizableURLResourceProvider > -------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-374 > URL: https://issues.jboss.org/browse/ARQGRA-374 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > {code:xml} > > > http://localhost:8080/app/ > > > {code} > The provider will obtain URL from {{URLResourceProvider}} and use it if no other URL is provided. > Configuring this provider should also block deploying application, since its unnecessary. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:29:05 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:29:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-425) Allow @Location with relative URL when there is no deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004712#comment-13004712 ] Luk?? Fry? commented on ARQGRA-425: ----------------------------------- This is duplicate of ARQGRA-374 > Allow @Location with relative URL when there is no deployment > ------------------------------------------------------------- > > Key: ARQGRA-425 > URL: https://issues.jboss.org/browse/ARQGRA-425 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Stefan Miklosovic > > There are some use cases when there is no {{@Deployment}} method, and we still need to treat {{URL}} in {{@Location}} as relative. > E.g. we are testing an application already deployed somewhere, but still the context root of the application can change, and we do not want to hardcode it. > As [~kpiwko] suggested, we can support his in Graphene like this: > # wrap {{org.jboss.arquillian.container.test.impl.enricher.resource.URLResourceProvider}} > # make it returns some default value of {{contextRoot}} if the {{contextRoot}} is null > # make that value configurable via Graphene configuration -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:29:06 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:29:06 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-425) Allow @Location with relative URL when there is no deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-425. ------------------------------- Assignee: Luk?? Fry? (was: Stefan Miklosovic) Fix Version/s: (was: 2.1-Tracking) Resolution: Duplicate Issue > Allow @Location with relative URL when there is no deployment > ------------------------------------------------------------- > > Key: ARQGRA-425 > URL: https://issues.jboss.org/browse/ARQGRA-425 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Luk?? Fry? > > There are some use cases when there is no {{@Deployment}} method, and we still need to treat {{URL}} in {{@Location}} as relative. > E.g. we are testing an application already deployed somewhere, but still the context root of the application can change, and we do not want to hardcode it. > As [~kpiwko] suggested, we can support his in Graphene like this: > # wrap {{org.jboss.arquillian.container.test.impl.enricher.resource.URLResourceProvider}} > # make it returns some default value of {{contextRoot}} if the {{contextRoot}} is null > # make that value configurable via Graphene configuration -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:30:04 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:30:04 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-426) Provide API for dynamic @Location In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004714#comment-13004714 ] Luk?? Fry? commented on ARQGRA-426: ----------------------------------- This is duplicate of ARQGRA-374 > Provide API for dynamic @Location > --------------------------------- > > Key: ARQGRA-426 > URL: https://issues.jboss.org/browse/ARQGRA-426 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > > There are use cases when the same page object has different URLs. One of such use cases is described in [this|https://community.jboss.org/message/861996#861996] post. > To enhance re-usability, we should IMHO provide an API for dynamic @Location resolutions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:30:04 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:30:04 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-426) Provide API for dynamic @Location In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-426. ------------------------------- Assignee: Luk?? Fry? Resolution: Duplicate Issue > Provide API for dynamic @Location > --------------------------------- > > Key: ARQGRA-426 > URL: https://issues.jboss.org/browse/ARQGRA-426 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Luk?? Fry? > Fix For: 2.1-Tracking > > > There are use cases when the same page object has different URLs. One of such use cases is described in [this|https://community.jboss.org/message/861996#861996] post. > To enhance re-usability, we should IMHO provide an API for dynamic @Location resolutions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:30:05 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:30:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-426) Provide API for dynamic @Location In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-426: ------------------------------ Fix Version/s: (was: 2.1-Tracking) > Provide API for dynamic @Location > --------------------------------- > > Key: ARQGRA-426 > URL: https://issues.jboss.org/browse/ARQGRA-426 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Luk?? Fry? > > There are use cases when the same page object has different URLs. One of such use cases is described in [this|https://community.jboss.org/message/861996#861996] post. > To enhance re-usability, we should IMHO provide an API for dynamic @Location resolutions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:31:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:31:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-453) takeOnEveryAction acts only on methods from WebDriver object, add support for PO & PF & WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-453: ------------------------------ Fix Version/s: 2.1-Tracking > takeOnEveryAction acts only on methods from WebDriver object, add support for PO & PF & WebElement > -------------------------------------------------------------------------------------------------- > > Key: ARQGRA-453 > URL: https://issues.jboss.org/browse/ARQGRA-453 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core, screenshooter > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Fix For: 2.1-Tracking > > > {{takeOnEveryAction}} now takes screenshot only when a method on {{WebDriver}} object is invoked. > To achieve something like visual testing, it would need to support also intercepting methods invoked on: > * {{WebElement}} > * Page objects > * Page fragments -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:32:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:32:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-421) Graphene Interceptors: allow logging of invoked intercepted methods including interceptor chain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-421: ------------------------------ Fix Version/s: 2.1-Tracking > Graphene Interceptors: allow logging of invoked intercepted methods including interceptor chain > ----------------------------------------------------------------------------------------------- > > Key: ARQGRA-421 > URL: https://issues.jboss.org/browse/ARQGRA-421 > Project: Arquillian Graphene > Issue Type: Enhancement > Reporter: Luk?? Fry? > Fix For: 2.1-Tracking > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:33:02 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 08:33:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-409) Support for Ember.js In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-409. ------------------------------- Assignee: Luk?? Fry? Resolution: Rejected > Support for Ember.js > -------------------- > > Key: ARQGRA-409 > URL: https://issues.jboss.org/browse/ARQGRA-409 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.0.Final > Reporter: Karel Piwko > Assignee: Luk?? Fry? > > Ember.js dynamically updates view based on various action. This makes usage of locators and guards pretty complicated. > It would be great it Graphene could provide: > * A way how to stability ids for elements in DOM generated as a part of view > * Guards that are able to guard DOM update without any request. > [~smikloso] can provide more details, additional discussions at: > http://stackoverflow.com/questions/12933422/ember-best-practices-with-selenium-to-make-integration-tests-in-browser > http://stackoverflow.com/questions/16639384/how-to-test-a-javascript-based-application-for-example-ember-js-with-selenium-2 > I believe that such tools might be handy for angular.js testing as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 08:50:03 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 22 Sep 2014 08:50:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-374) Allow to setup custom Location URL via arquillian.xml configuration with CustomizableURLResourceProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004728#comment-13004728 ] Stefan Miklosovic commented on ARQGRA-374: ------------------------------------------ [~lfryc] so implementing this would practically mean that super.lookup() could return null and in that case I would construct url manually from injected GrapheneConfiguration where I would look for "url" property? > Allow to setup custom Location URL via arquillian.xml configuration with CustomizableURLResourceProvider > -------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-374 > URL: https://issues.jboss.org/browse/ARQGRA-374 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > {code:xml} > > > http://localhost:8080/app/ > > > {code} > The provider will obtain URL from {{URLResourceProvider}} and use it if no other URL is provided. > Configuring this provider should also block deploying application, since its unnecessary. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 09:06:03 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 09:06:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-374) Allow to setup custom Location URL via arquillian.xml configuration with CustomizableURLResourceProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004741#comment-13004741 ] Luk?? Fry? commented on ARQGRA-374: ----------------------------------- Exactly > Allow to setup custom Location URL via arquillian.xml configuration with CustomizableURLResourceProvider > -------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-374 > URL: https://issues.jboss.org/browse/ARQGRA-374 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > {code:xml} > > > http://localhost:8080/app/ > > > {code} > The provider will obtain URL from {{URLResourceProvider}} and use it if no other URL is provided. > Configuring this provider should also block deploying application, since its unnecessary. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 09:15:07 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 09:15:07 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-237) Allow setting Chrome browser profile to disable cache In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-237. ------------------------------- Resolution: Deferred Fix Version/s: (was: 2.1-Tracking) > Allow setting Chrome browser profile to disable cache > ----------------------------------------------------- > > Key: ARQGRA-237 > URL: https://issues.jboss.org/browse/ARQGRA-237 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > Attachments: disable-cache.png > > > When cache is enabled then one cannot change e.g. JavaScript resource and see changes immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 09:15:07 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 09:15:07 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-340) Allow instantiate JavaScript interfaces with constructor's parameters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-340. ------------------------------- Resolution: Deferred Fix Version/s: (was: 2.1-Tracking) > Allow instantiate JavaScript interfaces with constructor's parameters > --------------------------------------------------------------------- > > Key: ARQGRA-340 > URL: https://issues.jboss.org/browse/ARQGRA-340 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > > {code} > // definition > @JavaScript("getObject({0}") > class Interface { > } > @JavaScript(arguments = "my_argument") > Interface myInterface; > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 09:15:08 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 09:15:08 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-361) Reimplement WebElement/PageFragment/ElementWrapper Enrichers to have one enrichment base which delegates to factories In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-361. ------------------------------- Resolution: Deferred Fix Version/s: (was: 2.1-Tracking) > Reimplement WebElement/PageFragment/ElementWrapper Enrichers to have one enrichment base which delegates to factories > --------------------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-361 > URL: https://issues.jboss.org/browse/ARQGRA-361 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Luk?? Fry? > > All of these enrichers scans for FindBy annotations: > * [WebElementEnricher|https://github.com/arquillian/arquillian-graphene/blob/2.0.0.Alpha5/graphene-webdriver/graphene-webdriver-impl/src/main/java/org/jboss/arquillian/graphene/enricher/WebElementEnricher.java#L41] > * [PageFragmentEnricher|https://github.com/arquillian/arquillian-graphene/blob/2.0.0.Alpha5/graphene-webdriver/graphene-webdriver-impl/src/main/java/org/jboss/arquillian/graphene/enricher/PageFragmentEnricher.java#L58] > * [WebElementWrapperEnricher|https://github.com/arquillian/arquillian-graphene/blob/2.0.0.Alpha5/graphene-webdriver/graphene-webdriver-impl/src/main/java/org/jboss/arquillian/graphene/enricher/WebElementWrapperEnricher.java#L28] > That leads into disambiguity since the solution is not readable. It also brings code duplication. > ---- > The suggested refactoring should lead into one enricher, which delegates to particular factories. > It will evaluate which type of injection should happen: > * interface / abstract class (needs to check newly created registry for implementation) > ** this is suitable for WebElement or GrapheneElement injections (GrapheneElement needs to be refactored to interface) > ** it's also case of page fragments with interface and implementation > * element wrapper: MyWrapper(WebElement) > ** this is case of e.g. Select(WebElement) > * page fragment implementation > When interface / abstract class doesn't find suitable implementation or it is a final class, exception should be thrown. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 09:15:08 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 09:15:08 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-280) Refactor handling of staleness to improve performance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-280. ------------------------------- Resolution: Deferred Fix Version/s: (was: 2.1-Tracking) > Refactor handling of staleness to improve performance > ----------------------------------------------------- > > Key: ARQGRA-280 > URL: https://issues.jboss.org/browse/ARQGRA-280 > Project: Arquillian Graphene > Issue Type: Task > Affects Versions: 2.0.0.Alpha3 > Reporter: Jan Papousek > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The current situation of handling staleness is it works purely accidentally in some cases and it prevents any caching of web elements. > Imagine the following code: > {code} > Action action = new Actions(driver).moveToElement(element).build(); > ... // some action causing staleness > action.perform(); > {code} > The previous code doesn't throw StaleElementReferenceException only in the case when the action causing staleness finishes before the requested action starts performing and when there is no caching of web elements. Currently Graphene can't force the action to perform again when StaleElementReferenceException is thrown. > In the case of caching the scenerio would be: > # element is loaded and put to the cache > # ... some actions ... > # action causing staleness is performed > # the requested action starts performing > -- cached element is used => StaleElementReferenceException -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 09:15:08 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 09:15:08 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-292) Extend fluent wating API to support page fragments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-292. ------------------------------- Resolution: Deferred Fix Version/s: (was: 2.1-Tracking) > Extend fluent wating API to support page fragments > -------------------------------------------------- > > Key: ARQGRA-292 > URL: https://issues.jboss.org/browse/ARQGRA-292 > Project: Arquillian Graphene > Issue Type: Feature Request > Affects Versions: 2.0.0.Alpha4 > Reporter: Jan Papousek > > Provide reasonable interfaces for page fragments to be able to extend fluent API for them, e.g. _Visible_: > {code} > Visible pf = ...; > Graphene.waitAjax().until().pageFragment(pf).is().visible(); > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 09:15:08 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 09:15:08 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-314) Allow to reuse jQuery from the page for speeding up jquery location strategy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-314. ------------------------------- Resolution: Deferred Fix Version/s: (was: 2.1-Tracking) > Allow to reuse jQuery from the page for speeding up jquery location strategy > ---------------------------------------------------------------------------- > > Key: ARQGRA-314 > URL: https://issues.jboss.org/browse/ARQGRA-314 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > > Currently JQuery needs to be checked for presense in the page and then injected when necessary to Graphene.jQuery object. > However we should allow to reuse jQuery and fall back to using own one when necessary. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 09:15:08 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 09:15:08 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-117) Create JBoss Forge plugin for Graphene In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-117. ------------------------------- Resolution: Deferred Fix Version/s: (was: 2.1-Tracking) > Create JBoss Forge plugin for Graphene > -------------------------------------- > > Key: ARQGRA-117 > URL: https://issues.jboss.org/browse/ARQGRA-117 > Project: Arquillian Graphene > Issue Type: Task > Components: integration > Reporter: Luk?? Fry? > Priority: Critical > Labels: devconf > > This could be rather Arquillian/Drone plugin. > Requirements: > * scaffolding new Graphene project > * start remote selenium server (ARQ-1032) > * ability to export @Deployment > ** the export of deployment is afaik done in Arquillian Forge plugin > * ability to deploy @Deployment (export + deploy) (ARQGRA-213) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 09:15:08 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 09:15:08 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-196) Retrieve text/attribute of an element with @FindBy annotated fields of alternative types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-196. ------------------------------- Resolution: Deferred Fix Version/s: (was: 2.1-Tracking) > Retrieve text/attribute of an element with @FindBy annotated fields of alternative types > ---------------------------------------------------------------------------------------- > > Key: ARQGRA-196 > URL: https://issues.jboss.org/browse/ARQGRA-196 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.0.Alpha2 > Reporter: Aslak Knutsen > > {code} > @FindBy(xpath = "//a[@id='name']") > private String name; > {code} > When annotating a field of type String a WebElement.getText could be automatically invoked and the result set on the field. > Other possible supported types could be: Integer, int, Boolean, Date? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 09:15:09 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 22 Sep 2014 09:15:09 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-231) consider usage of javascript compressor/optimizer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-231. ------------------------------- Resolution: Deferred Fix Version/s: (was: 2.1-Tracking) > consider usage of javascript compressor/optimizer > ------------------------------------------------- > > Key: ARQGRA-231 > URL: https://issues.jboss.org/browse/ARQGRA-231 > Project: Arquillian Graphene > Issue Type: Enhancement > Reporter: Jan Papousek > > Javascript source executed on AndroidDriver can't contain line breaks, so they have to be eliminated. Consider the utility class for removing comments, line breaks and other optimization. > This issue should overcome upstream issue http://code.google.com/p/selenium/issues/detail?id=4816 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 10:07:03 2014 From: issues at jboss.org (Moinz Moinzen (JIRA)) Date: Mon, 22 Sep 2014 10:07:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1828) Replace Testrunner with a JUnit-Rule In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004783#comment-13004783 ] Moinz Moinzen commented on ARQ-1828: ------------------------------------ A Junit Rule would also make it a lot easier to make some default setup, and then allowing the individual tests to add further information. Example: {code:java} private static class MyTestRule implements TestRule { ArquillianTestRule arquillianTestRule = new ArquillianTestRule(); private final WebArchive warModule = ShrinkWrap.create(WebArchive.class, "test.war") .addPackages(true, "some.default.package") .addAsManifestResource("MANIFEST.MF") .addAsWebResource(EmptyAsset.INSTANCE, "beans.xml") .addClass(ServerUserContext.class); private final JavaArchive beansModule = ShrinkWrap.create(JavaArchive.class).addClass(ApiProducer.class); public void addWarClass(Class clazz) { warModule.addClass(clazz); } @Override public Statement apply(Statement base, Description description) { arquillianTestRule.setArchive(ShrinkWrap.create(EnterpriseArchive.class, "test.ear") .addAsModule(warModule) .addAsModule(beansModule)); return arquillianTestRule.apply(base, description); } } {code} Usage: {code:java} public class MyTest { @Rule MyTestRule rule = new MyTestRule(); @Setup public void setup(){ rule.addWarClass(MyOtherClass.class); } @Test public void myTest() { //Go! } } {code} > Replace Testrunner with a JUnit-Rule > ------------------------------------ > > Key: ARQ-1828 > URL: https://issues.jboss.org/browse/ARQ-1828 > Project: Arquillian > Issue Type: Feature Request > Reporter: Niels Niels > > At the moment all tests must run with > @RunWith(Arquillian.class) > This makes trouble if you need a runner with add or remove tests like Parameterized. I can't see what Arquillian.class do which can not be done with a JUnit-Rule. JUnit-Rules can be easily combined. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 23 06:24:02 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 23 Sep 2014 06:24:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-374) Allow to setup custom Location URL via arquillian.xml configuration with CustomizableURLResourceProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQGRA-374: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/123 > Allow to setup custom Location URL via arquillian.xml configuration with CustomizableURLResourceProvider > -------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-374 > URL: https://issues.jboss.org/browse/ARQGRA-374 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Luk?? Fry? > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > {code:xml} > > > http://localhost:8080/app/ > > > {code} > The provider will obtain URL from {{URLResourceProvider}} and use it if no other URL is provided. > Configuring this provider should also block deploying application, since its unnecessary. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 23 09:03:02 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Tue, 23 Sep 2014 09:03:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1856) Remove dynamic import from arquillian-bundle In-Reply-To: References: Message-ID: Thomas Diesler created ARQ-1856: ----------------------------------- Summary: Remove dynamic import from arquillian-bundle Key: ARQ-1856 URL: https://issues.jboss.org/browse/ARQ-1856 Project: Arquillian Issue Type: Feature Request Components: OSGi Containers Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: osgi_2.0.0.Final Currently, the arquillian bundle contains a dynamic import "*" which may lead to undesired package wiring. Theoretically, it should possible to embed all required dependencies in the arq-bundle and load the test classes from the test-bundle(s) via Bundle.loadClass(...) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 02:47:03 2014 From: issues at jboss.org (Markus Heberling (JIRA)) Date: Thu, 25 Sep 2014 02:47:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1309) Persistence extension does not work with Jacoco extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005923#comment-13005923 ] Markus Heberling commented on ARQ-1309: --------------------------------------- I fixed it locally for me by converting the Exception into a warning. https://github.com/arquillian/arquillian-extension-persistence/pull/40 > Persistence extension does not work with Jacoco extension > --------------------------------------------------------- > > Key: ARQ-1309 > URL: https://issues.jboss.org/browse/ARQ-1309 > Project: Arquillian > Issue Type: Bug > Components: Extension - Persistence > Affects Versions: 1.0.0.Alpha5 > Reporter: Peter Schonhofen > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > When the Jacoco and persistence extension is used together in a project, a "PersistenceExtensionInitializationException: Unable to create persistence configuration" is thrown. > The cause of the exception is that in the ConfigurationImporter class the createConfiguration method receives a fieldsWithValues map with a "$jacocoData" item in it. Because the method cannot process this item, it fails. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 09:46:04 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Thu, 25 Sep 2014 09:46:04 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1857) Extract JavaScript in AngularJSDroneExtension to separete file for better maintainability In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1857: -------------------------------------- Summary: Extract JavaScript in AngularJSDroneExtension to separete file for better maintainability Key: ARQ-1857 URL: https://issues.jboss.org/browse/ARQ-1857 Project: Arquillian Issue Type: Enhancement Components: Extension - AngularJS Affects Versions: angularjs_1.2.0.Alpha1 Reporter: Stefan Miklosovic Assignee: Ken Finnigan Priority: Optional https://github.com/arquillian/arquillian-extension-angularjs/blob/master/graphene/impl/src/main/java/org/jboss/arquillian/graphene/angular/AngularJSDroneExtension.java#L107-L111 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 10:06:03 2014 From: issues at jboss.org (=?UTF-8?Q?Oliver_Ki=C5=A1=C5=A1_=28JIRA=29?=) Date: Thu, 25 Sep 2014 10:06:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1858) AngularJS extension throws angular.element(...).injector(...) is undefined In-Reply-To: References: Message-ID: Oliver Ki?? created ARQ-1858: -------------------------------- Summary: AngularJS extension throws angular.element(...).injector(...) is undefined Key: ARQ-1858 URL: https://issues.jboss.org/browse/ARQ-1858 Project: Arquillian Issue Type: Bug Components: Extension - AngularJS Affects Versions: angularjs_1.2.0.Alpha1 Reporter: Oliver Ki?? Assignee: Ken Finnigan AngularJS extension sometimes fails on UnifiedPush server login page with {{angular.element(...).injector(...) is undefined}}. The login page doesn't use AngularJS but is redirected to from a AngularJS page, which sometimes seems to cause problems. this pull request fixes the issue: https://github.com/arquillian/arquillian-extension-angularjs/pull/3/files -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 10:06:04 2014 From: issues at jboss.org (=?UTF-8?Q?Oliver_Ki=C5=A1=C5=A1_=28JIRA=29?=) Date: Thu, 25 Sep 2014 10:06:04 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1858) AngularJS extension throws angular.element(...).injector(...) is undefined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Ki?? updated ARQ-1858: ----------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-angularjs/pull/3 > AngularJS extension throws angular.element(...).injector(...) is undefined > -------------------------------------------------------------------------- > > Key: ARQ-1858 > URL: https://issues.jboss.org/browse/ARQ-1858 > Project: Arquillian > Issue Type: Bug > Components: Extension - AngularJS > Affects Versions: angularjs_1.2.0.Alpha1 > Reporter: Oliver Ki?? > Assignee: Ken Finnigan > > AngularJS extension sometimes fails on UnifiedPush server login page with > {{angular.element(...).injector(...) is undefined}}. The login page doesn't use AngularJS but is redirected to from a AngularJS page, which sometimes seems to cause problems. > this pull request fixes the issue: > https://github.com/arquillian/arquillian-extension-angularjs/pull/3/files -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 07:48:02 2014 From: issues at jboss.org (Martin Basovnik (JIRA)) Date: Fri, 26 Sep 2014 07:48:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1778) Add OSGi container support for bundle autostart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Basovnik updated ARQ-1778: --------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done merged > Add OSGi container support for bundle autostart > ----------------------------------------------- > > Key: ARQ-1778 > URL: https://issues.jboss.org/browse/ARQ-1778 > Project: Arquillian > Issue Type: Feature Request > Components: OSGi Containers > Reporter: Martin Basovnik > Assignee: Thomas Diesler > > Add OSGi container support for bundle autostart. > Container configuration will contain new property *autostartBundle*. This will cause autostart of every deployed bundle. Property type will be {{boolean}} and default value {{false}}. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:40:02 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 26 Sep 2014 16:40:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1859) Arquillian SecurityActions fail under actual security manager In-Reply-To: References: Message-ID: David Lloyd created ARQ-1859: -------------------------------- Summary: Arquillian SecurityActions fail under actual security manager Key: ARQ-1859 URL: https://issues.jboss.org/browse/ARQ-1859 Project: Arquillian Issue Type: Bug Components: Base Implementation Affects Versions: 1.1.2.Final Reporter: David Lloyd Priority: Critical The {{org.jboss.arquillian.core.impl.loadable.SecurityActions#newInstance(java.lang.Class, java.lang.Class[], java.lang.Object[])}} method takes extra care to reflectively acquire an object constructor in a privileged block. However, it then calls setAccessible(true) outside of a privileged block, rendering previous efforts useless and causing execution failures. The fix is to move that statement to within the privileged block as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 14:03:02 2014 From: issues at jboss.org (Ken Finnigan (JIRA)) Date: Mon, 29 Sep 2014 14:03:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1858) AngularJS extension throws angular.element(...).injector(...) is undefined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Finnigan updated ARQ-1858: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: angularjs_1.2.0.Beta1 Resolution: Done > AngularJS extension throws angular.element(...).injector(...) is undefined > -------------------------------------------------------------------------- > > Key: ARQ-1858 > URL: https://issues.jboss.org/browse/ARQ-1858 > Project: Arquillian > Issue Type: Bug > Components: Extension - AngularJS > Affects Versions: angularjs_1.2.0.Alpha1 > Reporter: Oliver Ki?? > Assignee: Ken Finnigan > Fix For: angularjs_1.2.0.Beta1 > > > AngularJS extension sometimes fails on UnifiedPush server login page with > {{angular.element(...).injector(...) is undefined}}. The login page doesn't use AngularJS but is redirected to from a AngularJS page, which sometimes seems to cause problems. > this pull request fixes the issue: > https://github.com/arquillian/arquillian-extension-angularjs/pull/3/files -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 14:04:02 2014 From: issues at jboss.org (Ken Finnigan (JIRA)) Date: Mon, 29 Sep 2014 14:04:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1860) Release AngularJS Extension 1.2.0.Beta1 In-Reply-To: References: Message-ID: Ken Finnigan created ARQ-1860: --------------------------------- Summary: Release AngularJS Extension 1.2.0.Beta1 Key: ARQ-1860 URL: https://issues.jboss.org/browse/ARQ-1860 Project: Arquillian Issue Type: Release Components: Extension - AngularJS Reporter: Ken Finnigan Assignee: Ken Finnigan -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 16:36:02 2014 From: issues at jboss.org (Ken Finnigan (JIRA)) Date: Mon, 29 Sep 2014 16:36:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1860) Release AngularJS Extension 1.2.0.Beta1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Finnigan resolved ARQ-1860. ------------------------------- Fix Version/s: angularjs_1.2.0.Beta1 Resolution: Done Tag: https://github.com/arquillian/arquillian-extension-angularjs/tree/1.2.0.Beta1 > Release AngularJS Extension 1.2.0.Beta1 > --------------------------------------- > > Key: ARQ-1860 > URL: https://issues.jboss.org/browse/ARQ-1860 > Project: Arquillian > Issue Type: Release > Components: Extension - AngularJS > Reporter: Ken Finnigan > Assignee: Ken Finnigan > Fix For: angularjs_1.2.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 16:38:02 2014 From: issues at jboss.org (Ken Finnigan (JIRA)) Date: Mon, 29 Sep 2014 16:38:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1858) AngularJS extension throws angular.element(...).injector(...) is undefined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Finnigan closed ARQ-1858. ----------------------------- > AngularJS extension throws angular.element(...).injector(...) is undefined > -------------------------------------------------------------------------- > > Key: ARQ-1858 > URL: https://issues.jboss.org/browse/ARQ-1858 > Project: Arquillian > Issue Type: Bug > Components: Extension - AngularJS > Affects Versions: angularjs_1.2.0.Alpha1 > Reporter: Oliver Ki?? > Assignee: Ken Finnigan > Fix For: angularjs_1.2.0.Beta1 > > > AngularJS extension sometimes fails on UnifiedPush server login page with > {{angular.element(...).injector(...) is undefined}}. The login page doesn't use AngularJS but is redirected to from a AngularJS page, which sometimes seems to cause problems. > this pull request fixes the issue: > https://github.com/arquillian/arquillian-extension-angularjs/pull/3/files -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 20:51:02 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 30 Sep 2014 20:51:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1859) Arquillian SecurityActions fail under actual security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated ARQ-1859: ----------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/71 > Arquillian SecurityActions fail under actual security manager > ------------------------------------------------------------- > > Key: ARQ-1859 > URL: https://issues.jboss.org/browse/ARQ-1859 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation > Affects Versions: 1.1.2.Final > Reporter: David Lloyd > Priority: Critical > > The {{org.jboss.arquillian.core.impl.loadable.SecurityActions#newInstance(java.lang.Class, java.lang.Class[], java.lang.Object[])}} method takes extra care to reflectively acquire an object constructor in a privileged block. However, it then calls setAccessible(true) outside of a privileged block, rendering previous efforts useless and causing execution failures. The fix is to move that statement to within the privileged block as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 22:27:02 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 30 Sep 2014 22:27:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1861) ContainerDeployer should be running commands in a privileged context In-Reply-To: References: Message-ID: David Lloyd created ARQ-1861: -------------------------------- Summary: ContainerDeployer should be running commands in a privileged context Key: ARQ-1861 URL: https://issues.jboss.org/browse/ARQ-1861 Project: Arquillian Issue Type: Bug Affects Versions: 1.1.2.Final Reporter: David Lloyd The ContainerDeployer should run commands in a privileged context, because the deployment (which is typically unprivileged) may be on the call stack. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 22:36:02 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 30 Sep 2014 22:36:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1861) ContainerDeployer should be running commands in a privileged context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated ARQ-1861: ----------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/72 > ContainerDeployer should be running commands in a privileged context > -------------------------------------------------------------------- > > Key: ARQ-1861 > URL: https://issues.jboss.org/browse/ARQ-1861 > Project: Arquillian > Issue Type: Bug > Affects Versions: 1.1.2.Final > Reporter: David Lloyd > > The ContainerDeployer should run commands in a privileged context, because the deployment (which is typically unprivileged) may be on the call stack. -- This message was sent by Atlassian JIRA (v6.3.1#6329)