From issues at jboss.org Fri May 1 00:00:48 2015 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Fri, 1 May 2015 00:00:48 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1883) Arquillian Persistence Extension: Cucumber integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064550#comment-13064550 ] Rafael Pestano commented on ARQ-1883: ------------------------------------- Hi there, I've created a project which you can use to reproduce the problem: https://github.com/rmpestano/cdi-crud/tree/cdi-crud-it In this sample project I have a test which calls dbunit api manually and it works fine: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudBdd.java and next I have the same tests using arquillian persistence here: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudPersistenceBdd.java [Atlassian|http://atlassian.com] We have one cucumber feature (you can [see it here|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/features/search-cars.feature]) with two scenarios: *The first scenario:* {code:java} @Given("^search car with model \"([^\"]*)\"$") @UsingDataSet("car.yml")//dataset has car with model = "Ferrari", @Transactional(TransactionMode.DISABLED) public void searchCarWithModel(String model) { assertEquals(4,carService.crud().count());//dataset has 4 cars Car carExample = new Car().model(model); carFound = carService.findByExample(carExample); assertNotNull(carFound); //everything ok with first step } @When("^update model to \"([^\"]*)\"$") @Transactional(TransactionMode.DISABLED) public void updateModel(String model) { carFound.model(model); carService.update(carFound);//exception is thrown cause } {code} here is the error when update method is called: Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 [full stacktrace is here|http://pastebin.com/jbReEjBe]. Looks like database was modified between cucumber steps given|when. In fact when the step *when* is performed the database is already clean although I set cleanup strategy NONE in [arquillian.xml|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/arquillian.xml#L43] *The second scenario:* In this scenario database is not being feed by persistence extension, see image below: !http://s13.postimg.org/5nf85tx93/cucumber_persistence_01.png! Just let me know if you need any help > Arquillian Persistence Extension: Cucumber integration > ------------------------------------------------------ > > Key: ARQ-1883 > URL: https://issues.jboss.org/browse/ARQ-1883 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Rafael Pestano > Assignee: Bartosz Majsak > > Currently we cannot use persistence extension in a Cucumber test. > Cukespace extension added events that other extensions can observe in order to e.g.: do something before a step. > see this issue for more details: https://github.com/cukespace/cukespace/issues/37 > Also there this blog post which details the limitations of using both extensions: http://rpestano.wordpress.com/2014/11/08/arquillian-cucumber-dbunit/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 1 00:01:45 2015 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Fri, 1 May 2015 00:01:45 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1883) Arquillian Persistence Extension: Cucumber integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064550#comment-13064550 ] Rafael Pestano edited comment on ARQ-1883 at 5/1/15 12:01 AM: -------------------------------------------------------------- Hi there, I've created a project which you can use to reproduce the problem: https://github.com/rmpestano/cdi-crud/tree/cdi-crud-it In this sample project I have a test which calls dbunit api manually and it works fine: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudBdd.java and next I have the same tests using arquillian persistence here: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudPersistenceBdd.java We have one cucumber feature (you can [see it here|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/features/search-cars.feature]) with two scenarios: *The first scenario:* {code:java} @Given("^search car with model \"([^\"]*)\"$") @UsingDataSet("car.yml")//dataset has car with model = "Ferrari", @Transactional(TransactionMode.DISABLED) public void searchCarWithModel(String model) { assertEquals(4,carService.crud().count());//dataset has 4 cars Car carExample = new Car().model(model); carFound = carService.findByExample(carExample); assertNotNull(carFound); //everything ok with first step } @When("^update model to \"([^\"]*)\"$") @Transactional(TransactionMode.DISABLED) public void updateModel(String model) { carFound.model(model); carService.update(carFound);//exception is thrown cause } {code} here is the error when update method is called: Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 [full stacktrace is here|http://pastebin.com/jbReEjBe]. Looks like database was modified between cucumber steps given|when. In fact when the step *when* is performed the database is already clean although I set cleanup strategy NONE in [arquillian.xml|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/arquillian.xml#L43] *The second scenario:* In this scenario database is not being feed by persistence extension, see image below: !http://s13.postimg.org/5nf85tx93/cucumber_persistence_01.png! Just let me know if you need any help was (Author: kwintesencja): Hi there, I've created a project which you can use to reproduce the problem: https://github.com/rmpestano/cdi-crud/tree/cdi-crud-it In this sample project I have a test which calls dbunit api manually and it works fine: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudBdd.java and next I have the same tests using arquillian persistence here: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudPersistenceBdd.java [Atlassian|http://atlassian.com] We have one cucumber feature (you can [see it here|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/features/search-cars.feature]) with two scenarios: *The first scenario:* {code:java} @Given("^search car with model \"([^\"]*)\"$") @UsingDataSet("car.yml")//dataset has car with model = "Ferrari", @Transactional(TransactionMode.DISABLED) public void searchCarWithModel(String model) { assertEquals(4,carService.crud().count());//dataset has 4 cars Car carExample = new Car().model(model); carFound = carService.findByExample(carExample); assertNotNull(carFound); //everything ok with first step } @When("^update model to \"([^\"]*)\"$") @Transactional(TransactionMode.DISABLED) public void updateModel(String model) { carFound.model(model); carService.update(carFound);//exception is thrown cause } {code} here is the error when update method is called: Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 [full stacktrace is here|http://pastebin.com/jbReEjBe]. Looks like database was modified between cucumber steps given|when. In fact when the step *when* is performed the database is already clean although I set cleanup strategy NONE in [arquillian.xml|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/arquillian.xml#L43] *The second scenario:* In this scenario database is not being feed by persistence extension, see image below: !http://s13.postimg.org/5nf85tx93/cucumber_persistence_01.png! Just let me know if you need any help > Arquillian Persistence Extension: Cucumber integration > ------------------------------------------------------ > > Key: ARQ-1883 > URL: https://issues.jboss.org/browse/ARQ-1883 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Rafael Pestano > Assignee: Bartosz Majsak > > Currently we cannot use persistence extension in a Cucumber test. > Cukespace extension added events that other extensions can observe in order to e.g.: do something before a step. > see this issue for more details: https://github.com/cukespace/cukespace/issues/37 > Also there this blog post which details the limitations of using both extensions: http://rpestano.wordpress.com/2014/11/08/arquillian-cucumber-dbunit/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 1 00:05:45 2015 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Fri, 1 May 2015 00:05:45 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1883) Arquillian Persistence Extension: Cucumber integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064550#comment-13064550 ] Rafael Pestano edited comment on ARQ-1883 at 5/1/15 12:04 AM: -------------------------------------------------------------- Hi there, I've created a project which you can use to reproduce the problem: https://github.com/rmpestano/cdi-crud/tree/cdi-crud-it In this sample project I have a test which calls dbunit api manually and it works fine: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudBdd.java and next I have the same tests using arquillian persistence here: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudPersistenceBdd.java We have one cucumber feature (you can [see it here|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/features/search-cars.feature]) with two scenarios: *The first scenario:* {code:java} @Given("^search car with model \"([^\"]*)\"$") @UsingDataSet("car.yml")//dataset has car with model = "Ferrari", @Transactional(TransactionMode.DISABLED) public void searchCarWithModel(String model) { assertEquals(4,carService.crud().count());//dataset has 4 cars Car carExample = new Car().model(model); carFound = carService.findByExample(carExample); assertNotNull(carFound); //everything ok with first step } @When("^update model to \"([^\"]*)\"$") @Transactional(TransactionMode.DISABLED) public void updateModel(String model) { carFound.model(model); carService.update(carFound);//exception is thrown cause } {code} here is the error when update method is called: Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 [full stacktrace is here|http://pastebin.com/jbReEjBe]. Looks like database was modified between cucumber steps given|when. In fact when the step *when* is performed the database is already clean although I set cleanup strategy NONE in [arquillian.xml|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/arquillian.xml#L43] Just let me know if you need any help was (Author: kwintesencja): Hi there, I've created a project which you can use to reproduce the problem: https://github.com/rmpestano/cdi-crud/tree/cdi-crud-it In this sample project I have a test which calls dbunit api manually and it works fine: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudBdd.java and next I have the same tests using arquillian persistence here: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudPersistenceBdd.java We have one cucumber feature (you can [see it here|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/features/search-cars.feature]) with two scenarios: *The first scenario:* {code:java} @Given("^search car with model \"([^\"]*)\"$") @UsingDataSet("car.yml")//dataset has car with model = "Ferrari", @Transactional(TransactionMode.DISABLED) public void searchCarWithModel(String model) { assertEquals(4,carService.crud().count());//dataset has 4 cars Car carExample = new Car().model(model); carFound = carService.findByExample(carExample); assertNotNull(carFound); //everything ok with first step } @When("^update model to \"([^\"]*)\"$") @Transactional(TransactionMode.DISABLED) public void updateModel(String model) { carFound.model(model); carService.update(carFound);//exception is thrown cause } {code} here is the error when update method is called: Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 [full stacktrace is here|http://pastebin.com/jbReEjBe]. Looks like database was modified between cucumber steps given|when. In fact when the step *when* is performed the database is already clean although I set cleanup strategy NONE in [arquillian.xml|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/arquillian.xml#L43] *The second scenario:* In this scenario database is not being feed by persistence extension, see image below: !http://s13.postimg.org/5nf85tx93/cucumber_persistence_01.png! Just let me know if you need any help > Arquillian Persistence Extension: Cucumber integration > ------------------------------------------------------ > > Key: ARQ-1883 > URL: https://issues.jboss.org/browse/ARQ-1883 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Rafael Pestano > Assignee: Bartosz Majsak > > Currently we cannot use persistence extension in a Cucumber test. > Cukespace extension added events that other extensions can observe in order to e.g.: do something before a step. > see this issue for more details: https://github.com/cukespace/cukespace/issues/37 > Also there this blog post which details the limitations of using both extensions: http://rpestano.wordpress.com/2014/11/08/arquillian-cucumber-dbunit/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 1 00:05:46 2015 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Fri, 1 May 2015 00:05:46 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1883) Arquillian Persistence Extension: Cucumber integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064550#comment-13064550 ] Rafael Pestano edited comment on ARQ-1883 at 5/1/15 12:05 AM: -------------------------------------------------------------- Hi there, I've created a project which you can use to reproduce the problem: https://github.com/rmpestano/cdi-crud/tree/cdi-crud-it In this sample project I have a test which calls dbunit api manually and it works fine: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudBdd.java and next I have the same tests using arquillian persistence here: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudPersistenceBdd.java We have one cucumber feature (you can [see it here|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/features/search-cars.feature]) with two scenarios: *The first scenario:* {code:java} @Given("^search car with model \"([^\"]*)\"$") @UsingDataSet("car.yml")//dataset has car with model = "Ferrari", @Transactional(TransactionMode.DISABLED) public void searchCarWithModel(String model) { assertEquals(4,carService.crud().count());//dataset has 4 cars Car carExample = new Car().model(model); carFound = carService.findByExample(carExample); assertNotNull(carFound); //everything ok with first step } @When("^update model to \"([^\"]*)\"$") @Transactional(TransactionMode.DISABLED) public void updateModel(String model) { carFound.model(model); carService.update(carFound); } {code} here is the error when update method is called: Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 [full stacktrace is here|http://pastebin.com/jbReEjBe]. Looks like database was modified between cucumber steps given|when. In fact when the step *when* is performed the database is already clean although I set cleanup strategy NONE in [arquillian.xml|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/arquillian.xml#L43] Just let me know if you need any help was (Author: kwintesencja): Hi there, I've created a project which you can use to reproduce the problem: https://github.com/rmpestano/cdi-crud/tree/cdi-crud-it In this sample project I have a test which calls dbunit api manually and it works fine: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudBdd.java and next I have the same tests using arquillian persistence here: https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/java/com/cdi/crud/test/CrudPersistenceBdd.java We have one cucumber feature (you can [see it here|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/features/search-cars.feature]) with two scenarios: *The first scenario:* {code:java} @Given("^search car with model \"([^\"]*)\"$") @UsingDataSet("car.yml")//dataset has car with model = "Ferrari", @Transactional(TransactionMode.DISABLED) public void searchCarWithModel(String model) { assertEquals(4,carService.crud().count());//dataset has 4 cars Car carExample = new Car().model(model); carFound = carService.findByExample(carExample); assertNotNull(carFound); //everything ok with first step } @When("^update model to \"([^\"]*)\"$") @Transactional(TransactionMode.DISABLED) public void updateModel(String model) { carFound.model(model); carService.update(carFound);//exception is thrown cause } {code} here is the error when update method is called: Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 [full stacktrace is here|http://pastebin.com/jbReEjBe]. Looks like database was modified between cucumber steps given|when. In fact when the step *when* is performed the database is already clean although I set cleanup strategy NONE in [arquillian.xml|https://github.com/rmpestano/cdi-crud/blob/cdi-crud-it/src/test/resources/arquillian.xml#L43] Just let me know if you need any help > Arquillian Persistence Extension: Cucumber integration > ------------------------------------------------------ > > Key: ARQ-1883 > URL: https://issues.jboss.org/browse/ARQ-1883 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Rafael Pestano > Assignee: Bartosz Majsak > > Currently we cannot use persistence extension in a Cucumber test. > Cukespace extension added events that other extensions can observe in order to e.g.: do something before a step. > see this issue for more details: https://github.com/cukespace/cukespace/issues/37 > Also there this blog post which details the limitations of using both extensions: http://rpestano.wordpress.com/2014/11/08/arquillian-cucumber-dbunit/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 1 10:08:45 2015 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 1 May 2015 10:08:45 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1883) Arquillian Persistence Extension: Cucumber integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064639#comment-13064639 ] Romain Manni-Bucau commented on ARQ-1883: ----------------------------------------- Happy to help as well if needed > Arquillian Persistence Extension: Cucumber integration > ------------------------------------------------------ > > Key: ARQ-1883 > URL: https://issues.jboss.org/browse/ARQ-1883 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Rafael Pestano > Assignee: Bartosz Majsak > > Currently we cannot use persistence extension in a Cucumber test. > Cukespace extension added events that other extensions can observe in order to e.g.: do something before a step. > see this issue for more details: https://github.com/cukespace/cukespace/issues/37 > Also there this blog post which details the limitations of using both extensions: http://rpestano.wordpress.com/2014/11/08/arquillian-cucumber-dbunit/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 1 10:43:46 2015 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Fri, 1 May 2015 10:43:46 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1883) Arquillian Persistence Extension: Cucumber integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064653#comment-13064653 ] Rafael Pestano commented on ARQ-1883: ------------------------------------- I've also tried to setup an example in persistense-extension project ([see here|https://github.com/rmpestano/arquillian-extension-persistence/blob/master/int-tests/src/test/java/org/jboss/arquillian/integration/persistence/cucumber/SeedingStrategyTest.java]) but its failing (i think its a detail) because persistence unit is not found. I've changed the deployment from *jar* to *war* cause i think cukespace doesn't work in jar project (in fact I didnt tried to flat the jar so changed to war) but the [@PersistenceContext inside test|https://github.com/rmpestano/arquillian-extension-persistence/blob/master/int-tests/src/test/java/org/jboss/arquillian/integration/persistence/cucumber/SeedingStrategyTest.java#L52] isn't working, here is test output: {noformat} org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83) at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 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:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:86) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:199) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:377) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:52) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:216) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:164) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68) Caused by: java.lang.Exception: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"test.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".WeldStartService: Failed to start service Caused by: java.lang.IllegalArgumentException: JBAS016069: Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named test in deployment test.war"}} at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) ... 88 more {noformat} I think it would be nice to have this test inside persistence-extension project to assure the integration will work with the project evolution > Arquillian Persistence Extension: Cucumber integration > ------------------------------------------------------ > > Key: ARQ-1883 > URL: https://issues.jboss.org/browse/ARQ-1883 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Rafael Pestano > Assignee: Bartosz Majsak > > Currently we cannot use persistence extension in a Cucumber test. > Cukespace extension added events that other extensions can observe in order to e.g.: do something before a step. > see this issue for more details: https://github.com/cukespace/cukespace/issues/37 > Also there this blog post which details the limitations of using both extensions: http://rpestano.wordpress.com/2014/11/08/arquillian-cucumber-dbunit/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 1 10:54:45 2015 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 1 May 2015 10:54:45 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1883) Arquillian Persistence Extension: Cucumber integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064661#comment-13064661 ] Romain Manni-Bucau commented on ARQ-1883: ----------------------------------------- Yes cukespace works only when enrichment can be done ie not with jars. side note: em enricher should be deactivable IMO for container doing it well by default like tomee and openejb > Arquillian Persistence Extension: Cucumber integration > ------------------------------------------------------ > > Key: ARQ-1883 > URL: https://issues.jboss.org/browse/ARQ-1883 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Rafael Pestano > Assignee: Bartosz Majsak > > Currently we cannot use persistence extension in a Cucumber test. > Cukespace extension added events that other extensions can observe in order to e.g.: do something before a step. > see this issue for more details: https://github.com/cukespace/cukespace/issues/37 > Also there this blog post which details the limitations of using both extensions: http://rpestano.wordpress.com/2014/11/08/arquillian-cucumber-dbunit/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 1 11:29:45 2015 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Fri, 1 May 2015 11:29:45 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1883) Arquillian Persistence Extension: Cucumber integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064694#comment-13064694 ] Rafael Pestano commented on ARQ-1883: ------------------------------------- ok, fixed the "Can't find a persistence unit" problem. Now the first step runs ok but i receive the error below on the [second step|https://github.com/rmpestano/arquillian-extension-persistence/blob/master/int-tests/src/test/java/org/jboss/arquillian/integration/persistence/cucumber/SeedingStrategyTest.java#L68] is faling the error below: {noformat} org.jboss.arquillian.persistence.dbunit.exception.DBUnitDataSetHandlingException: Unable to clean database. at org.jboss.arquillian.persistence.dbunit.cleanup.StrictCleanupStrategyExecutor.cleanupDatabase(StrictCleanupStrategyExecutor.java:60) at org.jboss.arquillian.persistence.dbunit.DBUnitDataHandler.cleanDatabase(DBUnitDataHandler.java:184) at org.jboss.arquillian.persistence.dbunit.DBUnitDataHandler.cleanup(DBUnitDataHandler.java:122) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 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.persistence.dbunit.DBUnitDataStateLogger.aroundCleanup(DBUnitDataStateLogger.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) ... ... Caused by: java.sql.SQLException: Connection is not associated with a managed connection.org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 1bc5bf4a at org.jboss.jca.adapters.jdbc.WrappedConnection.lock(WrappedConnection.java:155) at org.jboss.jca.adapters.jdbc.WrappedConnection.createStatement(WrappedConnection.java:296) at org.dbunit.database.statement.AbstractBatchStatement.(AbstractBatchStatement.java:50) at org.dbunit.database.statement.SimpleStatement.(SimpleStatement.java:49) at org.dbunit.database.statement.PreparedStatementFactory.createBatchStatement(PreparedStatementFactory.java:57) at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:85) at org.jboss.arquillian.persistence.dbunit.cleanup.StrictCleanupStrategyExecutor.cleanupDatabase(StrictCleanupStrategyExecutor.java:56) ... 218 more {noformat} > Arquillian Persistence Extension: Cucumber integration > ------------------------------------------------------ > > Key: ARQ-1883 > URL: https://issues.jboss.org/browse/ARQ-1883 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Rafael Pestano > Assignee: Bartosz Majsak > > Currently we cannot use persistence extension in a Cucumber test. > Cukespace extension added events that other extensions can observe in order to e.g.: do something before a step. > see this issue for more details: https://github.com/cukespace/cukespace/issues/37 > Also there this blog post which details the limitations of using both extensions: http://rpestano.wordpress.com/2014/11/08/arquillian-cucumber-dbunit/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 1 11:29:46 2015 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Fri, 1 May 2015 11:29:46 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1883) Arquillian Persistence Extension: Cucumber integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064694#comment-13064694 ] Rafael Pestano edited comment on ARQ-1883 at 5/1/15 11:29 AM: -------------------------------------------------------------- ok, fixed the "Can't find a persistence unit" problem. Now the first step runs ok but i receive the error below on the [second step|https://github.com/rmpestano/arquillian-extension-persistence/blob/master/int-tests/src/test/java/org/jboss/arquillian/integration/persistence/cucumber/SeedingStrategyTest.java#L68] is failing the error below: {noformat} org.jboss.arquillian.persistence.dbunit.exception.DBUnitDataSetHandlingException: Unable to clean database. at org.jboss.arquillian.persistence.dbunit.cleanup.StrictCleanupStrategyExecutor.cleanupDatabase(StrictCleanupStrategyExecutor.java:60) at org.jboss.arquillian.persistence.dbunit.DBUnitDataHandler.cleanDatabase(DBUnitDataHandler.java:184) at org.jboss.arquillian.persistence.dbunit.DBUnitDataHandler.cleanup(DBUnitDataHandler.java:122) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 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.persistence.dbunit.DBUnitDataStateLogger.aroundCleanup(DBUnitDataStateLogger.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) ... ... Caused by: java.sql.SQLException: Connection is not associated with a managed connection.org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 1bc5bf4a at org.jboss.jca.adapters.jdbc.WrappedConnection.lock(WrappedConnection.java:155) at org.jboss.jca.adapters.jdbc.WrappedConnection.createStatement(WrappedConnection.java:296) at org.dbunit.database.statement.AbstractBatchStatement.(AbstractBatchStatement.java:50) at org.dbunit.database.statement.SimpleStatement.(SimpleStatement.java:49) at org.dbunit.database.statement.PreparedStatementFactory.createBatchStatement(PreparedStatementFactory.java:57) at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:85) at org.jboss.arquillian.persistence.dbunit.cleanup.StrictCleanupStrategyExecutor.cleanupDatabase(StrictCleanupStrategyExecutor.java:56) ... 218 more {noformat} was (Author: kwintesencja): ok, fixed the "Can't find a persistence unit" problem. Now the first step runs ok but i receive the error below on the [second step|https://github.com/rmpestano/arquillian-extension-persistence/blob/master/int-tests/src/test/java/org/jboss/arquillian/integration/persistence/cucumber/SeedingStrategyTest.java#L68] is faling the error below: {noformat} org.jboss.arquillian.persistence.dbunit.exception.DBUnitDataSetHandlingException: Unable to clean database. at org.jboss.arquillian.persistence.dbunit.cleanup.StrictCleanupStrategyExecutor.cleanupDatabase(StrictCleanupStrategyExecutor.java:60) at org.jboss.arquillian.persistence.dbunit.DBUnitDataHandler.cleanDatabase(DBUnitDataHandler.java:184) at org.jboss.arquillian.persistence.dbunit.DBUnitDataHandler.cleanup(DBUnitDataHandler.java:122) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 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.persistence.dbunit.DBUnitDataStateLogger.aroundCleanup(DBUnitDataStateLogger.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) ... ... Caused by: java.sql.SQLException: Connection is not associated with a managed connection.org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 1bc5bf4a at org.jboss.jca.adapters.jdbc.WrappedConnection.lock(WrappedConnection.java:155) at org.jboss.jca.adapters.jdbc.WrappedConnection.createStatement(WrappedConnection.java:296) at org.dbunit.database.statement.AbstractBatchStatement.(AbstractBatchStatement.java:50) at org.dbunit.database.statement.SimpleStatement.(SimpleStatement.java:49) at org.dbunit.database.statement.PreparedStatementFactory.createBatchStatement(PreparedStatementFactory.java:57) at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:85) at org.jboss.arquillian.persistence.dbunit.cleanup.StrictCleanupStrategyExecutor.cleanupDatabase(StrictCleanupStrategyExecutor.java:56) ... 218 more {noformat} > Arquillian Persistence Extension: Cucumber integration > ------------------------------------------------------ > > Key: ARQ-1883 > URL: https://issues.jboss.org/browse/ARQ-1883 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Rafael Pestano > Assignee: Bartosz Majsak > > Currently we cannot use persistence extension in a Cucumber test. > Cukespace extension added events that other extensions can observe in order to e.g.: do something before a step. > see this issue for more details: https://github.com/cukespace/cukespace/issues/37 > Also there this blog post which details the limitations of using both extensions: http://rpestano.wordpress.com/2014/11/08/arquillian-cucumber-dbunit/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 1 11:35:46 2015 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Fri, 1 May 2015 11:35:46 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1883) Arquillian Persistence Extension: Cucumber integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064694#comment-13064694 ] Rafael Pestano edited comment on ARQ-1883 at 5/1/15 11:35 AM: -------------------------------------------------------------- ok, fixed the "Can't find a persistence unit" problem. Now the first step runs ok but the [second step|https://github.com/rmpestano/arquillian-extension-persistence/blob/master/int-tests/src/test/java/org/jboss/arquillian/integration/persistence/cucumber/SeedingStrategyTest.java#L68] is failing with the error below: {noformat} org.jboss.arquillian.persistence.dbunit.exception.DBUnitDataSetHandlingException: Unable to clean database. at org.jboss.arquillian.persistence.dbunit.cleanup.StrictCleanupStrategyExecutor.cleanupDatabase(StrictCleanupStrategyExecutor.java:60) at org.jboss.arquillian.persistence.dbunit.DBUnitDataHandler.cleanDatabase(DBUnitDataHandler.java:184) at org.jboss.arquillian.persistence.dbunit.DBUnitDataHandler.cleanup(DBUnitDataHandler.java:122) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 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.persistence.dbunit.DBUnitDataStateLogger.aroundCleanup(DBUnitDataStateLogger.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) ... ... Caused by: java.sql.SQLException: Connection is not associated with a managed connection.org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 1bc5bf4a at org.jboss.jca.adapters.jdbc.WrappedConnection.lock(WrappedConnection.java:155) at org.jboss.jca.adapters.jdbc.WrappedConnection.createStatement(WrappedConnection.java:296) at org.dbunit.database.statement.AbstractBatchStatement.(AbstractBatchStatement.java:50) at org.dbunit.database.statement.SimpleStatement.(SimpleStatement.java:49) at org.dbunit.database.statement.PreparedStatementFactory.createBatchStatement(PreparedStatementFactory.java:57) at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:85) at org.jboss.arquillian.persistence.dbunit.cleanup.StrictCleanupStrategyExecutor.cleanupDatabase(StrictCleanupStrategyExecutor.java:56) ... 218 more {noformat} was (Author: kwintesencja): ok, fixed the "Can't find a persistence unit" problem. Now the first step runs ok but i receive the error below on the [second step|https://github.com/rmpestano/arquillian-extension-persistence/blob/master/int-tests/src/test/java/org/jboss/arquillian/integration/persistence/cucumber/SeedingStrategyTest.java#L68] is failing the error below: {noformat} org.jboss.arquillian.persistence.dbunit.exception.DBUnitDataSetHandlingException: Unable to clean database. at org.jboss.arquillian.persistence.dbunit.cleanup.StrictCleanupStrategyExecutor.cleanupDatabase(StrictCleanupStrategyExecutor.java:60) at org.jboss.arquillian.persistence.dbunit.DBUnitDataHandler.cleanDatabase(DBUnitDataHandler.java:184) at org.jboss.arquillian.persistence.dbunit.DBUnitDataHandler.cleanup(DBUnitDataHandler.java:122) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 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.persistence.dbunit.DBUnitDataStateLogger.aroundCleanup(DBUnitDataStateLogger.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) ... ... Caused by: java.sql.SQLException: Connection is not associated with a managed connection.org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 1bc5bf4a at org.jboss.jca.adapters.jdbc.WrappedConnection.lock(WrappedConnection.java:155) at org.jboss.jca.adapters.jdbc.WrappedConnection.createStatement(WrappedConnection.java:296) at org.dbunit.database.statement.AbstractBatchStatement.(AbstractBatchStatement.java:50) at org.dbunit.database.statement.SimpleStatement.(SimpleStatement.java:49) at org.dbunit.database.statement.PreparedStatementFactory.createBatchStatement(PreparedStatementFactory.java:57) at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:85) at org.jboss.arquillian.persistence.dbunit.cleanup.StrictCleanupStrategyExecutor.cleanupDatabase(StrictCleanupStrategyExecutor.java:56) ... 218 more {noformat} > Arquillian Persistence Extension: Cucumber integration > ------------------------------------------------------ > > Key: ARQ-1883 > URL: https://issues.jboss.org/browse/ARQ-1883 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Rafael Pestano > Assignee: Bartosz Majsak > > Currently we cannot use persistence extension in a Cucumber test. > Cukespace extension added events that other extensions can observe in order to e.g.: do something before a step. > see this issue for more details: https://github.com/cukespace/cukespace/issues/37 > Also there this blog post which details the limitations of using both extensions: http://rpestano.wordpress.com/2014/11/08/arquillian-cucumber-dbunit/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed May 6 08:14:46 2015 From: issues at jboss.org (=?UTF-8?Q?Tom=C3=A1=C5=A1_Turek_=28JIRA=29?=) Date: Wed, 6 May 2015 08:14:46 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1947) Unable to use JUnit Matchers and assertThat In-Reply-To: References: Message-ID: Tom?? Turek created ARQ-1947: -------------------------------- Summary: Unable to use JUnit Matchers and assertThat Key: ARQ-1947 URL: https://issues.jboss.org/browse/ARQ-1947 Project: Arquillian Issue Type: Bug Components: OSGi Containers Reporter: Tom?? Turek Assignee: Thomas Diesler Unable to use _Matchers_ and _Assert.assertThat_ because the _arquillian-osgi-bundle_ does not export the package _org.hamcrest_. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed May 6 09:29:46 2015 From: issues at jboss.org (=?UTF-8?Q?Tom=C3=A1=C5=A1_Turek_=28JIRA=29?=) Date: Wed, 6 May 2015 09:29:46 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1947) Unable to use JUnit Matchers and assertThat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom?? Turek updated ARQ-1947: ----------------------------- Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/43 > Unable to use JUnit Matchers and assertThat > ------------------------------------------- > > Key: ARQ-1947 > URL: https://issues.jboss.org/browse/ARQ-1947 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Tom?? Turek > Assignee: Thomas Diesler > > Unable to use _Matchers_ and _Assert.assertThat_ because the _arquillian-osgi-bundle_ does not export the package _org.hamcrest_. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed May 6 11:41:46 2015 From: issues at jboss.org (Max Sinelnikov (JIRA)) Date: Wed, 6 May 2015 11:41:46 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1938) wildfly container does not support serverConfig parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065908#comment-13065908 ] Max Sinelnikov commented on ARQ-1938: ------------------------------------- It seems that only embedded wildfly container does not support serverConfig parameter. I tried it with managed container and it works. > wildfly container does not support serverConfig parameter > --------------------------------------------------------- > > Key: ARQ-1938 > URL: https://issues.jboss.org/browse/ARQ-1938 > Project: Arquillian > Issue Type: Feature Request > Reporter: Karl Pietrzak > > h3. arquillian.xml snippet > {code:xml} > > > does_not_matter.xml > target/wildfly-embedded/wildfly-8.2.0.Final/ > target/wildfly-embedded/wildfly-8.2.0.Final/modules > > > > {code} > h3. Details > * It doesn't matter what I put for {{serverConfig}}, which leads me to believe it isn't used. > * the JBoss container supports this parameter, so it would be great if the Wildfly one did too. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 7 00:46:45 2015 From: issues at jboss.org (Dhiraj Dwarapudi (JIRA)) Date: Thu, 7 May 2015 00:46:45 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1948) Documentation page of Aruillian TomEE Embedded Container Adapter shows incorrect released version In-Reply-To: References: Message-ID: Dhiraj Dwarapudi created ARQ-1948: ------------------------------------- Summary: Documentation page of Aruillian TomEE Embedded Container Adapter shows incorrect released version Key: ARQ-1948 URL: https://issues.jboss.org/browse/ARQ-1948 Project: Arquillian Issue Type: Bug Components: Documentation, Tomcat Containers Reporter: Dhiraj Dwarapudi Priority: Minor The documentation page for TomEE Embedded Container Adapter over here:- http://arquillian.org/modules/arquillian-tomee-embedded-container-adapter/ Has the wrong version number in the releases section. The last two versions are 4.7.2 and 1.7.1. I believe this should have been 1.7.2 instead of 4.7.2 Also the hyperlink to the Github page is incorrect under the 'Source repository>Web URL' section. It is 'https://github.com/apache/tomee/tree//arquillian' instead of 'https://github.com/apache/tomee/tree/arquillian' -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 7 03:58:46 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Thu, 7 May 2015 03:58:46 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1947) Unable to use JUnit Matchers and assertThat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler resolved ARQ-1947. --------------------------------- Resolution: Done Done > Unable to use JUnit Matchers and assertThat > ------------------------------------------- > > Key: ARQ-1947 > URL: https://issues.jboss.org/browse/ARQ-1947 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Tom?? Turek > Assignee: Thomas Diesler > > Unable to use _Matchers_ and _Assert.assertThat_ because the _arquillian-osgi-bundle_ does not export the package _org.hamcrest_. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 8 04:52:47 2015 From: issues at jboss.org (Falko M. (JIRA)) Date: Fri, 8 May 2015 04:52:47 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1949) Memory leak in DeploymentContextImpl.stores In-Reply-To: References: Message-ID: Falko M. created ARQ-1949: ----------------------------- Summary: Memory leak in DeploymentContextImpl.stores Key: ARQ-1949 URL: https://issues.jboss.org/browse/ARQ-1949 Project: Arquillian Issue Type: Bug Affects Versions: 1.1.7.Final, 1.1.3.Final Environment: Maven 3.2.5 Surefire-Plugin 2.18.1 Windows7 x64 and CentOS 6.5 Reporter: Falko M. The {{Deployment}} (which also holds the {{Archive}}) for each test class is added to {{DeploymentContextImpl.stores}}. A {{Deployment}} is deactivated properly but it is *not* getting removed until the {{Manager}} shuts down. This can easily blow the heap of the executing JVM in case you have *many* test classes and/or *large* archives to deploy. In our environment the JVM forked by maven surefire dies with an OOM after just ~20 test classes. Xmx is set to 512m. PS: Another user came across this problem too: https://developer.jboss.org/thread/250124 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 8 04:55:45 2015 From: issues at jboss.org (Falko M. (JIRA)) Date: Fri, 8 May 2015 04:55:45 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1949) Memory leak in DeploymentContextImpl.stores In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066427#comment-13066427 ] Falko M. commented on ARQ-1949: ------------------------------- A workaround is to call destroy explicitly: {code:java} public class LeakFixHandler { @Inject private Instance deploymentContext; public void destroyDeployment(@Observes(precedence = Integer.MIN_VALUE) final UnDeployDeployment event) { deploymentContext.get().destroy(event.getDeployment()); } } {code} > Memory leak in DeploymentContextImpl.stores > ------------------------------------------- > > Key: ARQ-1949 > URL: https://issues.jboss.org/browse/ARQ-1949 > Project: Arquillian > Issue Type: Bug > Affects Versions: 1.1.3.Final, 1.1.7.Final > Environment: Maven 3.2.5 > Surefire-Plugin 2.18.1 > Windows7 x64 and CentOS 6.5 > Reporter: Falko M. > > The {{Deployment}} (which also holds the {{Archive}}) for each test class is added to {{DeploymentContextImpl.stores}}. A {{Deployment}} is deactivated properly but it is *not* getting removed until the {{Manager}} shuts down. > This can easily blow the heap of the executing JVM in case you have *many* test classes and/or *large* archives to deploy. > In our environment the JVM forked by maven surefire dies with an OOM after just ~20 test classes. Xmx is set to 512m. > PS: Another user came across this problem too: https://developer.jboss.org/thread/250124 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 8 06:37:45 2015 From: issues at jboss.org (Falko M. (JIRA)) Date: Fri, 8 May 2015 06:37:45 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1949) Memory leak in DeploymentContextImpl.stores In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Falko M. updated ARQ-1949: -------------------------- Environment: Java 1.7.0_80 Maven 3.2.5 Surefire-Plugin 2.18.1 Windows7 x64 and CentOS 6.5 was: Maven 3.2.5 Surefire-Plugin 2.18.1 Windows7 x64 and CentOS 6.5 > Memory leak in DeploymentContextImpl.stores > ------------------------------------------- > > Key: ARQ-1949 > URL: https://issues.jboss.org/browse/ARQ-1949 > Project: Arquillian > Issue Type: Bug > Affects Versions: 1.1.3.Final, 1.1.7.Final > Environment: Java 1.7.0_80 > Maven 3.2.5 > Surefire-Plugin 2.18.1 > Windows7 x64 and CentOS 6.5 > Reporter: Falko M. > > The {{Deployment}} (which also holds the {{Archive}}) for each test class is added to {{DeploymentContextImpl.stores}}. A {{Deployment}} is deactivated properly but it is *not* getting removed until the {{Manager}} shuts down. > This can easily blow the heap of the executing JVM in case you have *many* test classes and/or *large* archives to deploy. > In our environment the JVM forked by maven surefire dies with an OOM after just ~20 test classes. Xmx is set to 512m. > PS: Another user came across this problem too: https://developer.jboss.org/thread/250124 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 14 13:24:19 2015 From: issues at jboss.org (Alex Soto (JIRA)) Date: Thu, 14 May 2015 13:24:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1950) Blur screenshots In-Reply-To: References: Message-ID: Alex Soto created ARQ-1950: ------------------------------ Summary: Blur screenshots Key: ARQ-1950 URL: https://issues.jboss.org/browse/ARQ-1950 Project: Arquillian Issue Type: Feature Request Affects Versions: recorder_1.0.0.Beta1 Reporter: Alex Soto Priority: Minor Sometimes you need to take screenshots of a website to globally see how is looking but it may contain sensitive data. In this case would be great to have a way to blur the screenshot. Something like an annotation that when is put on a test, the screenshots taken during the execution of that test are blurred. @BlurScreenshot(mode=LIGHT) And you can also set MEDIUM or HARD. https://github.com/arquillian/arquillian-recorder/issues/13 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 14 13:38:19 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Thu, 14 May 2015 13:38:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1950) Blur screenshots In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1950. ------------------------------------ Assignee: Alex Soto Resolution: Done https://github.com/arquillian/arquillian-recorder/commit/d87a617cc1b2434898581e287959936fb6a14877 > Blur screenshots > ---------------- > > Key: ARQ-1950 > URL: https://issues.jboss.org/browse/ARQ-1950 > Project: Arquillian > Issue Type: Feature Request > Affects Versions: recorder_1.0.0.Beta1 > Reporter: Alex Soto > Assignee: Alex Soto > Priority: Minor > > Sometimes you need to take screenshots of a website to globally see how is looking but it may contain sensitive data. In this case would be great to have a way to blur the screenshot. > Something like an annotation that when is put on a test, the screenshots taken during the execution of that test are blurred. > @BlurScreenshot(mode=LIGHT) > And you can also set MEDIUM or HARD. > https://github.com/arquillian/arquillian-recorder/issues/13 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 18 08:02:21 2015 From: issues at jboss.org (Martin Meyer (JIRA)) Date: Mon, 18 May 2015 08:02:21 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-814) Should support injection of EJBs (as CDI Beans) in Weld Embedded In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068783#comment-13068783 ] Martin Meyer commented on ARQ-814: ---------------------------------- Would be nice to get some update on this, maybe as a 3 years birthday gift to the issue? :o > Should support injection of EJBs (as CDI Beans) in Weld Embedded > ---------------------------------------------------------------- > > Key: ARQ-814 > URL: https://issues.jboss.org/browse/ARQ-814 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Affects Versions: weld_1.0.0.CR3 > Reporter: Anthony O. > Assignee: Marko Luk?a > Attachments: EJBTest.java > > > As seen in [this post on the Arquillian forum|https://community.jboss.org/message/723563], we cannot test that simple class as an NPE is thrown from {{org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.MockEjBServices}} which seems to be a copy of Weld code as [Aslak Knutsen|https://community.jboss.org/people/aslak] said. > {code} > @RunWith(Arquillian.class) > public class EJBTest { > @Deployment > public static JavaArchive createTestArchive() { > return ShrinkWrap > .create(JavaArchive.class, "test.jar") > .addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")); > } > @Stateless > public static class SomeService { > public String someMethod() { > return "test"; > } > } > @Inject > SomeService someService; > @Test > public void testStatelessCall() { > Assert.assertEquals("test", someService.someMethod()); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 18 09:49:19 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 18 May 2015 09:49:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1951) Tomcat managed container doesn't start when catalinaBase is not set In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-1951: ----------------------------------- Summary: Tomcat managed container doesn't start when catalinaBase is not set Key: ARQ-1951 URL: https://issues.jboss.org/browse/ARQ-1951 Project: Arquillian Issue Type: Bug Components: Tomcat Containers Affects Versions: tomcat_1.0.0.CR7 Reporter: Matous Jobanek Fix For: tomcat_1.0.0.Final The Tomcat managed container doesn't start when the property catalinaBase is not set. It throws NPE at this point \[1\]. {noformat} org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Caused by: java.lang.NullPointerException at java.io.File.(File.java:277) at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) ... 67 more {noformat} This affects all the Tomcat managed containers (5, 6 and 7). \[1\] https://github.com/arquillian/arquillian-container-tomcat/blob/1.0.0.CR7/tomcat-managed-7/src/main/java/org/jboss/arquillian/container/tomcat/managed_7/TomcatManagedContainer.java#L105 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 18 09:51:19 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 18 May 2015 09:51:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1951) Tomcat managed container doesn't start when catalinaBase is not set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068856#comment-13068856 ] Matous Jobanek commented on ARQ-1951: ------------------------------------- This is fixed in the new implementation on github: https://github.com/arquillian/arquillian-container-tomcat/blob/master/tomcat-managed-common/src/main/java/org/jboss/arquillian/container/tomcat/managed/TomcatManagedConfiguration.java#L99-L106 > Tomcat managed container doesn't start when catalinaBase is not set > ------------------------------------------------------------------- > > Key: ARQ-1951 > URL: https://issues.jboss.org/browse/ARQ-1951 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Matous Jobanek > Fix For: tomcat_1.0.0.Final > > > The Tomcat managed container doesn't start when the property catalinaBase is not set. It throws NPE at this point \[1\]. > {noformat} > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:277) > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) > ... 67 more > {noformat} > This affects all the Tomcat managed containers (5, 6 and 7). > \[1\] https://github.com/arquillian/arquillian-container-tomcat/blob/1.0.0.CR7/tomcat-managed-7/src/main/java/org/jboss/arquillian/container/tomcat/managed_7/TomcatManagedContainer.java#L105 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 18 10:17:19 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 18 May 2015 10:17:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1951) Tomcat managed container doesn't start when catalinaBase is not set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek resolved ARQ-1951. --------------------------------- Resolution: Done > Tomcat managed container doesn't start when catalinaBase is not set > ------------------------------------------------------------------- > > Key: ARQ-1951 > URL: https://issues.jboss.org/browse/ARQ-1951 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Matous Jobanek > Fix For: tomcat_1.0.0.Final > > > The Tomcat managed container doesn't start when the property catalinaBase is not set. It throws NPE at this point \[1\]. > {noformat} > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:277) > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) > ... 67 more > {noformat} > This affects all the Tomcat managed containers (5, 6 and 7). > \[1\] https://github.com/arquillian/arquillian-container-tomcat/blob/1.0.0.CR7/tomcat-managed-7/src/main/java/org/jboss/arquillian/container/tomcat/managed_7/TomcatManagedContainer.java#L105 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 18 18:30:19 2015 From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=) Date: Mon, 18 May 2015 18:30:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one In-Reply-To: References: Message-ID: P?tr Andreev created ARQ-1952: --------------------------------- Summary: Warp requests hit the application port instead of LittleProxy`s one Key: ARQ-1952 URL: https://issues.jboss.org/browse/ARQ-1952 Project: Arquillian Issue Type: Bug Components: Extension - Warp Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 Reporter: P?tr Andreev Warp observer intermittently fails while inspecting the requests with: "There were no requests matched by observer \[containsParameter(XXXX)\] ". The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 18 18:33:19 2015 From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=) Date: Mon, 18 May 2015 18:33:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069005#comment-13069005 ] P?tr Andreev commented on ARQ-1952: ----------------------------------- I think it is related > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: P?tr Andreev > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 18 18:39:19 2015 From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=) Date: Mon, 18 May 2015 18:39:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] P?tr Andreev updated ARQ-1952: ------------------------------ Attachment: ARQ-1952-failure.log Sniffed with [httpry|https://github.com/jbittel/httpry] Failed test, see lines 141 & 147-> wrong port 8080! > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: P?tr Andreev > Attachments: ARQ-1952-failure.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 18 18:41:19 2015 From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=) Date: Mon, 18 May 2015 18:41:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] P?tr Andreev updated ARQ-1952: ------------------------------ Attachment: ARQ-1952-success.log See lines 149 & 159: the request hits proxy @ port 18080! > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: P?tr Andreev > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 18 18:46:19 2015 From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=) Date: Mon, 18 May 2015 18:46:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069009#comment-13069009 ] P?tr Andreev commented on ARQ-1952: ----------------------------------- [~lfryc]] I didn`t inspect the client site yet, do you have any suggestions on the probable cause? > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: P?tr Andreev > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 18 18:46:19 2015 From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=) Date: Mon, 18 May 2015 18:46:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069009#comment-13069009 ] P?tr Andreev edited comment on ARQ-1952 at 5/18/15 6:46 PM: ------------------------------------------------------------ [~lfryc] I didn`t inspect the client site yet, do you have any suggestions on the probable cause? was (Author: pjotrovsky): [~lfryc]] I didn`t inspect the client site yet, do you have any suggestions on the probable cause? > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: P?tr Andreev > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 19 06:11:19 2015 From: issues at jboss.org (Alex Soto (JIRA)) Date: Tue, 19 May 2015 06:11:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1953) Adding attributes file on AsciiDoc header In-Reply-To: References: Message-ID: Alex Soto created ARQ-1953: ------------------------------ Summary: Adding attributes file on AsciiDoc header Key: ARQ-1953 URL: https://issues.jboss.org/browse/ARQ-1953 Project: Arquillian Issue Type: Feature Request Components: Extension - Recorder Reporter: Alex Soto Priority: Minor Sometimes you may want to customize the attributes set in AsciiDoc document. For this reason a new attribute called asciiDocAttributesFile is created so when this property is set to a file location, this file will be included using include macro in header. Github issue: https://github.com/arquillian/arquillian-recorder/issues/16 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 21 08:15:20 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 21 May 2015 08:15:20 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-470) Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent In-Reply-To: References: Message-ID: Matous Jobanek created ARQGRA-470: ------------------------------------- Summary: Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent Key: ARQGRA-470 URL: https://issues.jboss.org/browse/ARQGRA-470 Project: Arquillian Graphene Issue Type: Bug Affects Versions: 2.1.0.Alpha2 Reporter: Matous Jobanek There in the org.jboss.arquillian.graphene:graphene-parent pom is defined a dependency: {code:xml} org.jboss.logging jboss-logging ${version.jboss.logging} {code} however the variable {{version.jboss.logging}} is not defined neither it this pom nor in the parent pom. see: [org.jboss.arquillian.graphene:graphene-parent:2.1.0.Alpha2|https://repo1.maven.org/maven2/org/jboss/arquillian/graphene/graphene-parent/2.1.0.Alpha2/graphene-parent-2.1.0.Alpha2.pom] [github|https://github.com/arquillian/arquillian-graphene/blob/master/pom.xml] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 21 11:58:19 2015 From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=) Date: Thu, 21 May 2015 11:58:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070110#comment-13070110 ] P?tr Andreev commented on ARQ-1952: ----------------------------------- I think, I can describe what causing the problem: the new feature for customizable URLs was introduced with [ARQGRA-374|https://issues.jboss.org/browse/ARQGRA-374]. The [GrapheneExtension|https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/GrapheneExtension.java#L85-90] overrides the default _URLResourceProvider_. It works well until Warp comes into the play (which is the case while ITesting the RichFaces): the [WarpExtension|https://github.com/arquillian/arquillian-extension-warp/blob/master/impl/src/main/java/org/jboss/arquillian/warp/WarpExtension.java#L75-76] overrides the default _URLResourceProvider_ too. So actually both URLProviders coexist in the ServiceRegistry. What happens during the Warp request processing is: while storing the location in [ContextRootStoreInitializer|https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L52-56] the _ServiceRegistryLoader_ is asked for all available URLProviders and both, the Warp AND Graphene ones, _canProvide_ URL. Since the order of the _Set_ entries returned by _ServiceLoader_ depends on _weather_, the Graphene` _CustomizableURLProvider_ returns the non-proxied URL (port 8080). The suggested solution can be found [here|https://github.com/petrandreev/arquillian-graphene/commit/c8ff5a2096174ab68e618adf97877af1b2829676], it skips the registration of any _CustomizableURLResourceProvider_s in the Warp environment. I think this should not interfere with use cases in the standalone Graphene environment. I can provide a PR. > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: P?tr Andreev > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 21 12:04:19 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 21 May 2015 12:04:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070112#comment-13070112 ] Aslak Knutsen commented on ARQ-1952: ------------------------------------ Wondering if this feature would be helpful in this case; https://github.com/aslakknutsen/arquillian-core/commit/9a1ec4bc1d1f5c817675be4293aff38c6116cb06 > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: P?tr Andreev > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 25 07:44:19 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 25 May 2015 07:44:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-470) Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-470: ------------------------------ Fix Version/s: 2.1-Tracking > Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent > --------------------------------------------------------------------------------------------------- > > Key: ARQGRA-470 > URL: https://issues.jboss.org/browse/ARQGRA-470 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > There in the org.jboss.arquillian.graphene:graphene-parent pom is defined a dependency: > {code:xml} > > org.jboss.logging > jboss-logging > ${version.jboss.logging} > > {code} > however the variable {{version.jboss.logging}} is not defined neither it this pom nor in the parent pom. > see: > [org.jboss.arquillian.graphene:graphene-parent:2.1.0.Alpha2|https://repo1.maven.org/maven2/org/jboss/arquillian/graphene/graphene-parent/2.1.0.Alpha2/graphene-parent-2.1.0.Alpha2.pom] > [github|https://github.com/arquillian/arquillian-graphene/blob/master/pom.xml] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 25 07:47:20 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 25 May 2015 07:47:20 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-470) Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070691#comment-13070691 ] Luk?? Fry? commented on ARQGRA-470: ----------------------------------- Yes, let's remove that definition if that is not required anymore. [~mjobanek] would you try to simply build with the remove dependency management for jboss-logging and if yes, send a PR? > Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent > --------------------------------------------------------------------------------------------------- > > Key: ARQGRA-470 > URL: https://issues.jboss.org/browse/ARQGRA-470 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > There in the org.jboss.arquillian.graphene:graphene-parent pom is defined a dependency: > {code:xml} > > org.jboss.logging > jboss-logging > ${version.jboss.logging} > > {code} > however the variable {{version.jboss.logging}} is not defined neither it this pom nor in the parent pom. > see: > [org.jboss.arquillian.graphene:graphene-parent:2.1.0.Alpha2|https://repo1.maven.org/maven2/org/jboss/arquillian/graphene/graphene-parent/2.1.0.Alpha2/graphene-parent-2.1.0.Alpha2.pom] > [github|https://github.com/arquillian/arquillian-graphene/blob/master/pom.xml] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 25 18:30:19 2015 From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=) Date: Mon, 25 May 2015 18:30:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070819#comment-13070819 ] P?tr Andreev commented on ARQ-1952: ----------------------------------- [~aslak] I think the ResourceWrapper could be a very useful feature, I even tried to implement [one for Warp|https://github.com/petrandreev/arquillian-extension-warp/blob/ARQ-1952%2Bresource_wrapper/impl/src/main/java/org/jboss/arquillian/warp/impl/client/proxy/ProxyURLWrapper.java]. But it doesn`t help for the current issue. What I can propose for the solution is to make the [URLResourceResolver|https://github.com/petrandreev/arquillian-core/blob/ARQ-1952/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/enricher/resource/URLResourceProvider.java#L49-51] more cooperative. The whole picture in the environment of Aquillian Core, Warp and Graphene would then look like: 1. ARQ registers the URLResourceProvider 2. Warp overrides the URLResourceProvider by the proxied (ProxyURLProvider) one (and delegates to URLResourceProvider for non-Warp tests) 3. Graphene` [CustomizableURLResourceProvider|https://github.com/petrandreev/arquillian-graphene/blob/ARQ-1952/impl/src/main/java/org/jboss/arquillian/graphene/location/CustomizableURLResourceProvider.java] is only usable in non-deployment scenarios, so the [GrapheneExtension|https://github.com/petrandreev/arquillian-graphene/blob/ARQ-1952/impl/src/main/java/org/jboss/arquillian/graphene/GrapheneExtension.java#L84] just needs to register it additionally and all tasks for deployments are done by the default URLREsourceProvider [~aslak] and [~lfryc] what do you think about it? > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: P?tr Andreev > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 26 09:24:02 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 26 May 2015 09:24:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-470) Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQGRA-470: ---------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/131 > Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent > --------------------------------------------------------------------------------------------------- > > Key: ARQGRA-470 > URL: https://issues.jboss.org/browse/ARQGRA-470 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > There in the org.jboss.arquillian.graphene:graphene-parent pom is defined a dependency: > {code:xml} > > org.jboss.logging > jboss-logging > ${version.jboss.logging} > > {code} > however the variable {{version.jboss.logging}} is not defined neither it this pom nor in the parent pom. > see: > [org.jboss.arquillian.graphene:graphene-parent:2.1.0.Alpha2|https://repo1.maven.org/maven2/org/jboss/arquillian/graphene/graphene-parent/2.1.0.Alpha2/graphene-parent-2.1.0.Alpha2.pom] > [github|https://github.com/arquillian/arquillian-graphene/blob/master/pom.xml] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 26 09:24:02 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 26 May 2015 09:24:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-470) Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071045#comment-13071045 ] Matous Jobanek commented on ARQGRA-470: --------------------------------------- PR sent and merged https://github.com/arquillian/arquillian-graphene/pull/131 > Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent > --------------------------------------------------------------------------------------------------- > > Key: ARQGRA-470 > URL: https://issues.jboss.org/browse/ARQGRA-470 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > There in the org.jboss.arquillian.graphene:graphene-parent pom is defined a dependency: > {code:xml} > > org.jboss.logging > jboss-logging > ${version.jboss.logging} > > {code} > however the variable {{version.jboss.logging}} is not defined neither it this pom nor in the parent pom. > see: > [org.jboss.arquillian.graphene:graphene-parent:2.1.0.Alpha2|https://repo1.maven.org/maven2/org/jboss/arquillian/graphene/graphene-parent/2.1.0.Alpha2/graphene-parent-2.1.0.Alpha2.pom] > [github|https://github.com/arquillian/arquillian-graphene/blob/master/pom.xml] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 26 09:25:02 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 26 May 2015 09:25:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-470) Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek resolved ARQGRA-470. ----------------------------------- Resolution: Done > Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent > --------------------------------------------------------------------------------------------------- > > Key: ARQGRA-470 > URL: https://issues.jboss.org/browse/ARQGRA-470 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > There in the org.jboss.arquillian.graphene:graphene-parent pom is defined a dependency: > {code:xml} > > org.jboss.logging > jboss-logging > ${version.jboss.logging} > > {code} > however the variable {{version.jboss.logging}} is not defined neither it this pom nor in the parent pom. > see: > [org.jboss.arquillian.graphene:graphene-parent:2.1.0.Alpha2|https://repo1.maven.org/maven2/org/jboss/arquillian/graphene/graphene-parent/2.1.0.Alpha2/graphene-parent-2.1.0.Alpha2.pom] > [github|https://github.com/arquillian/arquillian-graphene/blob/master/pom.xml] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 26 13:47:02 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 26 May 2015 13:47:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-470) Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071203#comment-13071203 ] Luk?? Fry? commented on ARQGRA-470: ----------------------------------- Thanks Matous! > Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent > --------------------------------------------------------------------------------------------------- > > Key: ARQGRA-470 > URL: https://issues.jboss.org/browse/ARQGRA-470 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > There in the org.jboss.arquillian.graphene:graphene-parent pom is defined a dependency: > {code:xml} > > org.jboss.logging > jboss-logging > ${version.jboss.logging} > > {code} > however the variable {{version.jboss.logging}} is not defined neither it this pom nor in the parent pom. > see: > [org.jboss.arquillian.graphene:graphene-parent:2.1.0.Alpha2|https://repo1.maven.org/maven2/org/jboss/arquillian/graphene/graphene-parent/2.1.0.Alpha2/graphene-parent-2.1.0.Alpha2.pom] > [github|https://github.com/arquillian/arquillian-graphene/blob/master/pom.xml] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 26 13:48:05 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 26 May 2015 13:48:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-470) Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-470: --------------------------------- Assignee: Matous Jobanek > Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent > --------------------------------------------------------------------------------------------------- > > Key: ARQGRA-470 > URL: https://issues.jboss.org/browse/ARQGRA-470 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 2.1-Tracking > > > There in the org.jboss.arquillian.graphene:graphene-parent pom is defined a dependency: > {code:xml} > > org.jboss.logging > jboss-logging > ${version.jboss.logging} > > {code} > however the variable {{version.jboss.logging}} is not defined neither it this pom nor in the parent pom. > see: > [org.jboss.arquillian.graphene:graphene-parent:2.1.0.Alpha2|https://repo1.maven.org/maven2/org/jboss/arquillian/graphene/graphene-parent/2.1.0.Alpha2/graphene-parent-2.1.0.Alpha2.pom] > [github|https://github.com/arquillian/arquillian-graphene/blob/master/pom.xml] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 26 22:22:02 2015 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 26 May 2015 22:22:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071291#comment-13071291 ] Brian Leathem commented on ARQ-1952: ------------------------------------ [~ppitonak] does anyone in your group have feedback on this Warp issue? > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: P?tr Andreev > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 28 07:13:02 2015 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Thu, 28 May 2015 07:13:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1954) Support @Rule enrichement In-Reply-To: References: Message-ID: Karel Piwko created ARQ-1954: -------------------------------- Summary: Support @Rule enrichement Key: ARQ-1954 URL: https://issues.jboss.org/browse/ARQ-1954 Project: Arquillian Issue Type: Feature Request Components: Base Implementation Affects Versions: 1.1.8.Final Reporter: Karel Piwko Arquillian should by default enrich JUnit @Rule statements. Similarly to https://github.com/aerogear/aerogear-testing-tools/blob/master/arquillian-rule/src/test/java/org/jboss/aerogear/arquillian/junit/RuleInjectionTest.java -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 05:34:02 2015 From: issues at jboss.org (Michael Kotten (JIRA)) Date: Fri, 29 May 2015 05:34:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1955) Screenshot not taken when eception occurs during @Before In-Reply-To: References: Message-ID: Michael Kotten created ARQ-1955: ----------------------------------- Summary: Screenshot not taken when eception occurs during @Before Key: ARQ-1955 URL: https://issues.jboss.org/browse/ARQ-1955 Project: Arquillian Issue Type: Bug Components: Extension - Recorder Affects Versions: recorder_1.0.0.Final Reporter: Michael Kotten If a test fails with an exception during the @Before method, there is no screenshot taken, even with takeWhenTestFailed=true. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 07:50:02 2015 From: issues at jboss.org (Szymek Pindelski (JIRA)) Date: Fri, 29 May 2015 07:50:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-326) Support for full initialization of outer class instance of a page fragment declared as inner class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072221#comment-13072221 ] Szymek Pindelski commented on ARQGRA-326: ----------------------------------------- hello there, are there any plans to get round to fixing this issue ? It's simetimes handy to use a nested class as a page fragment - for example when a specific section of a web page may occur once or multiple times -- as with JSF tag? -- and unlike a widget-type page fragment, the section is not reusable (it doesn't make sense to reference it from other page objects / page fragments across your test suite). With and outer class reference you can for instance call your custom assertOnPage() method to ensure you're at the right web page or reuse your enclosing page object's drone reference. > Support for full initialization of outer class instance of a page fragment declared as inner class > -------------------------------------------------------------------------------------------------- > > Key: ARQGRA-326 > URL: https://issues.jboss.org/browse/ARQGRA-326 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.0.Alpha4 > Reporter: Juraj H?ska > Priority: Minor > Fix For: 2.0-Tracking > > > If a Page Fragment is declared as inner class, then it can not access the fields of its outer class, as their are not inicialized by Graphene Enrichers, thus are {{null}}. > The possible ugly workaround for such initialization can be: > {code} > if (pageFragment.getClass().getEnclosingClass() != null) { > Field field = pageFragment.getClass().getDeclaredField("this$0"); > field.setAccessible(true); > Object outer = field.get(pageFragment); > enrichRecursively(root, outer); > } > {code} > It should be placed in some utility class, so it can be easily unit tested. > There is one drawback of this method and that is, the outer class can not contain injection point for the inner class, otherwise it will cycle. The inner class can be obtained only dynamically via {{Graphene.createPageFragment}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 08:48:02 2015 From: issues at jboss.org (Szymek Pindelski (JIRA)) Date: Fri, 29 May 2015 08:48:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-326) Support for full initialization of outer class instance of a page fragment declared as inner class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072221#comment-13072221 ] Szymek Pindelski edited comment on ARQGRA-326 at 5/29/15 8:47 AM: ------------------------------------------------------------------ hello there, are there any plans to get round to fixing this issue ? It's simetimes handy to use a nested class as a page fragment - for example when a specific section of a web page may occur once or multiple times -- as with JSF tag -- and unlike a widget-type page fragment, the section is not reusable (it doesn't make sense to reference it from other page objects / page fragments across your test suite). With and outer class reference you can for instance call your custom assertOnPage() method to ensure you're at the right web page or reuse your enclosing page object's drone reference. was (Author: spine): hello there, are there any plans to get round to fixing this issue ? It's simetimes handy to use a nested class as a page fragment - for example when a specific section of a web page may occur once or multiple times -- as with JSF tag? -- and unlike a widget-type page fragment, the section is not reusable (it doesn't make sense to reference it from other page objects / page fragments across your test suite). With and outer class reference you can for instance call your custom assertOnPage() method to ensure you're at the right web page or reuse your enclosing page object's drone reference. > Support for full initialization of outer class instance of a page fragment declared as inner class > -------------------------------------------------------------------------------------------------- > > Key: ARQGRA-326 > URL: https://issues.jboss.org/browse/ARQGRA-326 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.0.Alpha4 > Reporter: Juraj H?ska > Priority: Minor > Fix For: 2.0-Tracking > > > If a Page Fragment is declared as inner class, then it can not access the fields of its outer class, as their are not inicialized by Graphene Enrichers, thus are {{null}}. > The possible ugly workaround for such initialization can be: > {code} > if (pageFragment.getClass().getEnclosingClass() != null) { > Field field = pageFragment.getClass().getDeclaredField("this$0"); > field.setAccessible(true); > Object outer = field.get(pageFragment); > enrichRecursively(root, outer); > } > {code} > It should be placed in some utility class, so it can be easily unit tested. > There is one drawback of this method and that is, the outer class can not contain injection point for the inner class, otherwise it will cycle. The inner class can be obtained only dynamically via {{Graphene.createPageFragment}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 09:13:02 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Fri, 29 May 2015 09:13:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1179) Mark a test so it will only run against certain browsers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072253#comment-13072253 ] Stefan Miklosovic commented on ARQ-1179: ---------------------------------------- this could be implemented on Arquillian Governor level, you would have to scan your test class beforehand and skip respective test methods which would be otherwise run by some to-be-injected Drone. > Mark a test so it will only run against certain browsers > -------------------------------------------------------- > > Key: ARQ-1179 > URL: https://issues.jboss.org/browse/ARQ-1179 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Reporter: Brian Leathem > Fix For: drone_2.0.0.Beta1 > > > It would be useful to be able to annotate a particular test so it will only run when driven by a particular set of browsers. > Some sample use cases: > # Some tests cannot target the incomplete js impl found in html unit. I would mark such tests not to run when htmlunit is the configured browser (in CI for instance) > # Some tests may target non-standard behaviour in certain browsers (older IE versions for instance) and may not make sense to run in all browsers. I would mark such tests not to run only when IE is the configured browser. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 09:13:03 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Fri, 29 May 2015 09:13:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1176) automatically take screenshot and capture the html output on Assert failure or Exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072254#comment-13072254 ] Stefan Miklosovic commented on ARQ-1176: ---------------------------------------- rejecting +1, we have Recorder for this. > automatically take screenshot and capture the html output on Assert failure or Exception > ---------------------------------------------------------------------------------------- > > Key: ARQ-1176 > URL: https://issues.jboss.org/browse/ARQ-1176 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Reporter: Mark Struberg > Fix For: drone_2.0.0.Beta1 > > > Some testing frameworks like cucumber automatically takes a screenshot and stores the current html output when test failure occurs. > Imo this is a great feature as it is really hard to find out what went wrong without having any information at hand. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 09:16:02 2015 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Fri, 29 May 2015 09:16:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1884) Update Selenium to 2.44.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072258#comment-13072258 ] Stefan Miklosovic commented on ARQ-1884: ---------------------------------------- there is already Selenium 2.45.0 in Drone 2.0.0.Alpha4, I believe this issue is obsolete by now. > Update Selenium to 2.44.0 > ------------------------- > > Key: ARQ-1884 > URL: https://issues.jboss.org/browse/ARQ-1884 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Affects Versions: drone_2.0.0.Alpha2, drone_1.3.1.Final > Reporter: Karel Piwko > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 10:28:04 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 29 May 2015 10:28:04 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1956) Add Instance to Before|AfterEnrichment events In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1956: ---------------------------------- Summary: Add Instance to Before|AfterEnrichment events Key: ARQ-1956 URL: https://issues.jboss.org/browse/ARQ-1956 Project: Arquillian Issue Type: Feature Request Components: Base Implementation Affects Versions: 1.1.8.Final Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.2.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 16:27:01 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 29 May 2015 16:27:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1956) Add Instance to Before|AfterEnrichment events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1956: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/84 > Add Instance to Before|AfterEnrichment events > --------------------------------------------- > > Key: ARQ-1956 > URL: https://issues.jboss.org/browse/ARQ-1956 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.8.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.2.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 17:56:05 2015 From: issues at jboss.org (Patrick Fink (JIRA)) Date: Fri, 29 May 2015 17:56:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1077) Persistence Plugin does not work with Drone/Graphene In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072499#comment-13072499 ] Patrick Fink commented on ARQ-1077: ----------------------------------- I think currently the best workaround for this is to set the defaultCleanupStrategy to "BEFORE" and do something like this: Test class: {code:java} @Test @InSequence(1) @UsingDataSet("myDroneTest-seeding.yml") public void populateDatabaseWorkaround() {} @Test @InSequence(2) @RunAsClient public void myDroneTest() { //Do GUI testing here } @Test @InSequence(3) @UsingDataSet("myDroneTest-checking.yml") @Cleanup(phase = TestExecutionPhase.NONE) public void checkDatabaseWorkaround() {} {code} arquillian.xml: {code:xml} BEFORE {code} At least this workaround isolates your persistence+drone tests better from the rest of your test suite then just using @Cleanup(phase = TestExecutionPhase.NONE). > Persistence Plugin does not work with Drone/Graphene > ---------------------------------------------------- > > Key: ARQ-1077 > URL: https://issues.jboss.org/browse/ARQ-1077 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone, Extension - Persistence > Environment: JBoss AS 7 Container > Reporter: Bryan Saunders > Assignee: Bartosz Majsak > Labels: drone, persistence > Fix For: drone_2.0.0.Beta1 > > > Persistence Extension does not execute when being used with the Drone/Graphene extensions. When you run the tests in Client Mode the @UsingDataSet annotations do not trigger and populate the database. @ApplyScriptBefore also does not work. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 17:56:07 2015 From: issues at jboss.org (Patrick Fink (JIRA)) Date: Fri, 29 May 2015 17:56:07 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1077) Persistence Plugin does not work with Drone/Graphene In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072499#comment-13072499 ] Patrick Fink edited comment on ARQ-1077 at 5/29/15 5:55 PM: ------------------------------------------------------------ I think currently the best workaround for this is to set the defaultCleanupStrategy to "BEFORE" and do something like this: Test class: {code:java} @Test @InSequence(1) @UsingDataSet("myDroneTest-seeding.yml") public void populateDatabaseWorkaround() {} @Test @InSequence(2) @RunAsClient public void myDroneTest() { //Do GUI testing here } @Test @InSequence(3) @ShouldMatchDataset("myDroneTest-checking.yml") @Cleanup(phase = TestExecutionPhase.NONE) public void checkDatabaseWorkaround() {} {code} arquillian.xml: {code:xml} BEFORE {code} At least this workaround isolates your persistence+drone tests better from the rest of your test suite then just using @Cleanup(phase = TestExecutionPhase.NONE). was (Author: patrick.fink): I think currently the best workaround for this is to set the defaultCleanupStrategy to "BEFORE" and do something like this: Test class: {code:java} @Test @InSequence(1) @UsingDataSet("myDroneTest-seeding.yml") public void populateDatabaseWorkaround() {} @Test @InSequence(2) @RunAsClient public void myDroneTest() { //Do GUI testing here } @Test @InSequence(3) @UsingDataSet("myDroneTest-checking.yml") @Cleanup(phase = TestExecutionPhase.NONE) public void checkDatabaseWorkaround() {} {code} arquillian.xml: {code:xml} BEFORE {code} At least this workaround isolates your persistence+drone tests better from the rest of your test suite then just using @Cleanup(phase = TestExecutionPhase.NONE). > Persistence Plugin does not work with Drone/Graphene > ---------------------------------------------------- > > Key: ARQ-1077 > URL: https://issues.jboss.org/browse/ARQ-1077 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone, Extension - Persistence > Environment: JBoss AS 7 Container > Reporter: Bryan Saunders > Assignee: Bartosz Majsak > Labels: drone, persistence > Fix For: drone_2.0.0.Beta1 > > > Persistence Extension does not execute when being used with the Drone/Graphene extensions. When you run the tests in Client Mode the @UsingDataSet annotations do not trigger and populate the database. @ApplyScriptBefore also does not work. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 17:57:04 2015 From: issues at jboss.org (Patrick Fink (JIRA)) Date: Fri, 29 May 2015 17:57:04 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1077) Persistence Plugin does not work with Drone/Graphene In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072499#comment-13072499 ] Patrick Fink edited comment on ARQ-1077 at 5/29/15 5:56 PM: ------------------------------------------------------------ I think currently the best workaround for this is to set the defaultCleanupPhase to "BEFORE" and do something like this: Test class: {code:java} @Test @InSequence(1) @UsingDataSet("myDroneTest-seeding.yml") public void populateDatabaseWorkaround() {} @Test @InSequence(2) @RunAsClient public void myDroneTest() { //Do GUI testing here } @Test @InSequence(3) @ShouldMatchDataset("myDroneTest-checking.yml") @Cleanup(phase = TestExecutionPhase.NONE) public void checkDatabaseWorkaround() {} {code} arquillian.xml: {code:xml} BEFORE {code} At least this workaround isolates your persistence+drone tests better from the rest of your test suite then just using @Cleanup(phase = TestExecutionPhase.NONE). was (Author: patrick.fink): I think currently the best workaround for this is to set the defaultCleanupStrategy to "BEFORE" and do something like this: Test class: {code:java} @Test @InSequence(1) @UsingDataSet("myDroneTest-seeding.yml") public void populateDatabaseWorkaround() {} @Test @InSequence(2) @RunAsClient public void myDroneTest() { //Do GUI testing here } @Test @InSequence(3) @ShouldMatchDataset("myDroneTest-checking.yml") @Cleanup(phase = TestExecutionPhase.NONE) public void checkDatabaseWorkaround() {} {code} arquillian.xml: {code:xml} BEFORE {code} At least this workaround isolates your persistence+drone tests better from the rest of your test suite then just using @Cleanup(phase = TestExecutionPhase.NONE). > Persistence Plugin does not work with Drone/Graphene > ---------------------------------------------------- > > Key: ARQ-1077 > URL: https://issues.jboss.org/browse/ARQ-1077 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone, Extension - Persistence > Environment: JBoss AS 7 Container > Reporter: Bryan Saunders > Assignee: Bartosz Majsak > Labels: drone, persistence > Fix For: drone_2.0.0.Beta1 > > > Persistence Extension does not execute when being used with the Drone/Graphene extensions. When you run the tests in Client Mode the @UsingDataSet annotations do not trigger and populate the database. @ApplyScriptBefore also does not work. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 17:58:04 2015 From: issues at jboss.org (Patrick Fink (JIRA)) Date: Fri, 29 May 2015 17:58:04 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1077) Persistence Plugin does not work with Drone/Graphene In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072499#comment-13072499 ] Patrick Fink edited comment on ARQ-1077 at 5/29/15 5:57 PM: ------------------------------------------------------------ I think currently the best workaround for this is to do something like this: Test class: {code:java} @Test @InSequence(1) @UsingDataSet("myDroneTest-seeding.yml") public void populateDatabaseWorkaround() {} @Test @InSequence(2) @RunAsClient public void myDroneTest() { //Do GUI testing here } @Test @InSequence(3) @ShouldMatchDataset("myDroneTest-checking.yml") @Cleanup(phase = TestExecutionPhase.NONE) public void checkDatabaseWorkaround() {} {code} arquillian.xml: {code:xml} BEFORE {code} At least this workaround isolates your persistence+drone tests better from the rest of your test suite then just using @Cleanup(phase = TestExecutionPhase.NONE). was (Author: patrick.fink): I think currently the best workaround for this is to set the defaultCleanupPhase to "BEFORE" and do something like this: Test class: {code:java} @Test @InSequence(1) @UsingDataSet("myDroneTest-seeding.yml") public void populateDatabaseWorkaround() {} @Test @InSequence(2) @RunAsClient public void myDroneTest() { //Do GUI testing here } @Test @InSequence(3) @ShouldMatchDataset("myDroneTest-checking.yml") @Cleanup(phase = TestExecutionPhase.NONE) public void checkDatabaseWorkaround() {} {code} arquillian.xml: {code:xml} BEFORE {code} At least this workaround isolates your persistence+drone tests better from the rest of your test suite then just using @Cleanup(phase = TestExecutionPhase.NONE). > Persistence Plugin does not work with Drone/Graphene > ---------------------------------------------------- > > Key: ARQ-1077 > URL: https://issues.jboss.org/browse/ARQ-1077 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone, Extension - Persistence > Environment: JBoss AS 7 Container > Reporter: Bryan Saunders > Assignee: Bartosz Majsak > Labels: drone, persistence > Fix For: drone_2.0.0.Beta1 > > > Persistence Extension does not execute when being used with the Drone/Graphene extensions. When you run the tests in Client Mode the @UsingDataSet annotations do not trigger and populate the database. @ApplyScriptBefore also does not work. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 18:03:05 2015 From: issues at jboss.org (Patrick Fink (JIRA)) Date: Fri, 29 May 2015 18:03:05 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1077) Persistence Plugin does not work with Drone/Graphene In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072499#comment-13072499 ] Patrick Fink edited comment on ARQ-1077 at 5/29/15 6:02 PM: ------------------------------------------------------------ I think currently the best workaround for this is to do something like this: Test class: {code:java} @Test @InSequence(1) @UsingDataSet("myDroneTest-seeding.yml") public void populateDatabaseWorkaround() {} @Test @InSequence(2) @RunAsClient public void myDroneTest() { //Do GUI testing here } @Test @InSequence(3) @ShouldMatchDataset("myDroneTest-checking.yml") @Cleanup(phase = TestExecutionPhase.NONE) public void checkDatabaseWorkaround() {} {code} arquillian.xml: {code:xml} BEFORE {code} At least this workaround isolates your persistence+drone tests better from the rest of your test suite then just using @Cleanup(phase = TestExecutionPhase.NONE). Depending on your needs, either the first or the last test method can be skipped. was (Author: patrick.fink): I think currently the best workaround for this is to do something like this: Test class: {code:java} @Test @InSequence(1) @UsingDataSet("myDroneTest-seeding.yml") public void populateDatabaseWorkaround() {} @Test @InSequence(2) @RunAsClient public void myDroneTest() { //Do GUI testing here } @Test @InSequence(3) @ShouldMatchDataset("myDroneTest-checking.yml") @Cleanup(phase = TestExecutionPhase.NONE) public void checkDatabaseWorkaround() {} {code} arquillian.xml: {code:xml} BEFORE {code} At least this workaround isolates your persistence+drone tests better from the rest of your test suite then just using @Cleanup(phase = TestExecutionPhase.NONE). > Persistence Plugin does not work with Drone/Graphene > ---------------------------------------------------- > > Key: ARQ-1077 > URL: https://issues.jboss.org/browse/ARQ-1077 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone, Extension - Persistence > Environment: JBoss AS 7 Container > Reporter: Bryan Saunders > Assignee: Bartosz Majsak > Labels: drone, persistence > Fix For: drone_2.0.0.Beta1 > > > Persistence Extension does not execute when being used with the Drone/Graphene extensions. When you run the tests in Client Mode the @UsingDataSet annotations do not trigger and populate the database. @ApplyScriptBefore also does not work. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri May 29 18:03:07 2015 From: issues at jboss.org (Patrick Fink (JIRA)) Date: Fri, 29 May 2015 18:03:07 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1077) Persistence Plugin does not work with Drone/Graphene In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072499#comment-13072499 ] Patrick Fink edited comment on ARQ-1077 at 5/29/15 6:02 PM: ------------------------------------------------------------ I think currently the best workaround for this is to do something like this: Test class: {code:java} @Test @InSequence(1) @UsingDataSet("myDroneTest-seeding.yml") public void populateDatabaseWorkaround() {} @Test @InSequence(2) @RunAsClient public void myDroneTest() { //Do GUI testing here } @Test @InSequence(3) @ShouldMatchDataset("myDroneTest-checking.yml") @Cleanup(phase = TestExecutionPhase.NONE) public void checkDatabaseWorkaround() {} {code} Depending on your needs, either the first or the last test method can be skipped. arquillian.xml: {code:xml} BEFORE {code} At least this workaround isolates your persistence+drone tests better from the rest of your test suite then just using @Cleanup(phase = TestExecutionPhase.NONE). was (Author: patrick.fink): I think currently the best workaround for this is to do something like this: Test class: {code:java} @Test @InSequence(1) @UsingDataSet("myDroneTest-seeding.yml") public void populateDatabaseWorkaround() {} @Test @InSequence(2) @RunAsClient public void myDroneTest() { //Do GUI testing here } @Test @InSequence(3) @ShouldMatchDataset("myDroneTest-checking.yml") @Cleanup(phase = TestExecutionPhase.NONE) public void checkDatabaseWorkaround() {} {code} arquillian.xml: {code:xml} BEFORE {code} At least this workaround isolates your persistence+drone tests better from the rest of your test suite then just using @Cleanup(phase = TestExecutionPhase.NONE). Depending on your needs, either the first or the last test method can be skipped. > Persistence Plugin does not work with Drone/Graphene > ---------------------------------------------------- > > Key: ARQ-1077 > URL: https://issues.jboss.org/browse/ARQ-1077 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone, Extension - Persistence > Environment: JBoss AS 7 Container > Reporter: Bryan Saunders > Assignee: Bartosz Majsak > Labels: drone, persistence > Fix For: drone_2.0.0.Beta1 > > > Persistence Extension does not execute when being used with the Drone/Graphene extensions. When you run the tests in Client Mode the @UsingDataSet annotations do not trigger and populate the database. @ApplyScriptBefore also does not work. -- This message was sent by Atlassian JIRA (v6.3.15#6346)