September 2014 - arquillian-issues

[JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers

by Ian Brandt (JIRA)

[ https://issues.jboss.org/browse/ARQ-1846?page=com.atlassian.jira.plugin.s... ] Ian Brandt updated ARQ-1846: ---------------------------- Fix Version/s: tomcat_1.0.0.Final > Support configuration of the Tomcat system classpath from managed containers > ---------------------------------------------------------------------------- > > Key: ARQ-1846 > URL: https://issues.jboss.org/browse/ARQ-1846 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers

by Ian Brandt (JIRA)

[ https://issues.jboss.org/browse/ARQ-1846?page=com.atlassian.jira.plugin.s... ] Ian Brandt reassigned ARQ-1846: ------------------------------- Assignee: Ian Brandt > Support configuration of the Tomcat system classpath from managed containers > ---------------------------------------------------------------------------- > > Key: ARQ-1846 > URL: https://issues.jboss.org/browse/ARQ-1846 > Project: Arquillian > Issue Type: Feature Request > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Ian Brandt > Assignee: Ian Brandt > Fix For: tomcat_1.0.0.Final > > > In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1846) Support configuration of the Tomcat system classpath from managed containers

by Ian Brandt (JIRA)

Ian Brandt created ARQ-1846: ------------------------------- Summary: Support configuration of the Tomcat system classpath from managed containers Key: ARQ-1846 URL: https://issues.jboss.org/browse/ARQ-1846 Project: Arquillian Issue Type: Feature Request Components: Tomcat Containers Affects Versions: tomcat_1.0.0.CR7 Reporter: Ian Brandt In some rare cases, such as customization of Tomcat's internal logging, it may prove useful to augment or change the [system classpath used to start Tomcat|http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html]. Currently the managed containers hard code the Tomcat default configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1845) BeforeSuite and AfterSuite events triggered for every class in Eclipse since ARQ-1803

by Emond Papegaaij (JIRA)

[ https://issues.jboss.org/browse/ARQ-1845?page=com.atlassian.jira.plugin.s... ] Emond Papegaaij updated ARQ-1845: --------------------------------- Component/s: Test Harness Integration (was: Base Implementation) > BeforeSuite and AfterSuite events triggered for every class in Eclipse since ARQ-1803 > ------------------------------------------------------------------------------------- > > Key: ARQ-1845 > URL: https://issues.jboss.org/browse/ARQ-1845 > Project: Arquillian > Issue Type: Bug > Components: Test Harness Integration > Affects Versions: 1.1.5.Final > Reporter: Emond Papegaaij > > The change made in ARQ-1803 broke the Eclipse hack that should prevent Before- and AfterSuite events for every class. Eclipse creates an Arquillian instance for every class to be tested before the tests are actually started. The State.runnerStarted() was placed in the constructor to count the number of tests created, so only the last test would fire AfterSuite. See the comment in org.jboss.arquillian.junit.State for more info. > This is a major regression for us, as we depend on the arquillian-suite-extension to only deploy the application once. Deploying the application takes over a minute, adding significant time to our test runs under Eclipse. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1845) BeforeSuite and AfterSuite events triggered for every class in Eclipse since ARQ-1803

by Emond Papegaaij (JIRA)

Emond Papegaaij created ARQ-1845: ------------------------------------ Summary: BeforeSuite and AfterSuite events triggered for every class in Eclipse since ARQ-1803 Key: ARQ-1845 URL: https://issues.jboss.org/browse/ARQ-1845 Project: Arquillian Issue Type: Bug Components: Base Implementation Affects Versions: 1.1.5.Final Reporter: Emond Papegaaij The change made in ARQ-1803 broke the Eclipse hack that should prevent Before- and AfterSuite events for every class. Eclipse creates an Arquillian instance for every class to be tested before the tests are actually started. The State.runnerStarted() was placed in the constructor to count the number of tests created, so only the last test would fire AfterSuite. See the comment in org.jboss.arquillian.junit.State for more info. This is a major regression for us, as we depend on the arquillian-suite-extension to only deploy the application once. Deploying the application takes over a minute, adding significant time to our test runs under Eclipse. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1830) Only the last Test Class of some subset of Test classes is reported with TestNG runner

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/ARQ-1830?page=com.atlassian.jira.plugin.s... ] Juraj Húska commented on ARQ-1830: ---------------------------------- I tried to reproduce this with different Arquillian core versions, but I did not found a suitable testng based test suite to try it, and isolate it. Well I can create a one, but as I do not suppose this as critical, I would devote some time to this once somebody requests it. > Only the last Test Class of some subset of Test classes is reported with TestNG runner > -------------------------------------------------------------------------------------- > > Key: ARQ-1830 > URL: https://issues.jboss.org/browse/ARQ-1830 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Recorder > Affects Versions: recorder_1.0.0.Alpha4 > Reporter: Juraj Húska > > When you have TestNG test suite, after running some *subset* of all test classes (particular test classes or e.g. all classes in one package), then only the last test class is reported. > It works when you run all tests, and also with JUnit nicely. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1809) @ShouldMatchDataSet is broken when ordering by non-string columns

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1809?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak commented on ARQ-1809: ------------------------------------- I cannot reproduce this behaviour, but I have improved sorted and filtered sets so that they have now proper metadata. As for the suggested fix : both YAML and JSON implementation are based on FlatXML data sets, where datatype is also set to unknown. If I understand DBUnit right, the real types are then extracted from underlying db and conversion is applied. But this might be wrong reasoning :) I will take a closer look. In the meantime, could you try to run your test against [latest master|https://github.com/arquillian/arquillian-extension-persistence] and let me know? Does this error occurs each and every time you run the test? > @ShouldMatchDataSet is broken when ordering by non-string columns > ----------------------------------------------------------------- > > Key: ARQ-1809 > URL: https://issues.jboss.org/browse/ARQ-1809 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Steven Dodd > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > Steps to reproduce: > 1. Create a table, "test", with a single column, an integer primary key, "id". > 2. Try the following test case under the persistence extension: > {code} > @UsingDataSet({test.yml}) > @ShouldMatchDataSet(value={test.yml}) > @Test > public void test() { > // do nothing > } > {code} > {code:title=test.yml} > test: > - id: -1 > - id: -2 > {code} > Result: test fails like so: > {code} > java.lang.AssertionError: Test failed in 2 cases. > test | In row 0: expected value of id "-1" but was "-2". > test | In row 1: expected value of id "-2" but was "-1". > {code} > Reason: > The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN. > The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database. > DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison. > SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above. > As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results. > Suggested Fix: > The expected dataset needs to have accurate column types assigned, not UNKNOWN. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1809) @ShouldMatchDataSet is broken when ordering by non-string columns

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1809?page=com.atlassian.jira.plugin.s... ] Work on ARQ-1809 started by Bartosz Majsak. ------------------------------------------- > @ShouldMatchDataSet is broken when ordering by non-string columns > ----------------------------------------------------------------- > > Key: ARQ-1809 > URL: https://issues.jboss.org/browse/ARQ-1809 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Steven Dodd > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > Steps to reproduce: > 1. Create a table, "test", with a single column, an integer primary key, "id". > 2. Try the following test case under the persistence extension: > {code} > @UsingDataSet({test.yml}) > @ShouldMatchDataSet(value={test.yml}) > @Test > public void test() { > // do nothing > } > {code} > {code:title=test.yml} > test: > - id: -1 > - id: -2 > {code} > Result: test fails like so: > {code} > java.lang.AssertionError: Test failed in 2 cases. > test | In row 0: expected value of id "-1" but was "-2". > test | In row 1: expected value of id "-2" but was "-1". > {code} > Reason: > The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN. > The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database. > DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison. > SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above. > As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results. > Suggested Fix: > The expected dataset needs to have accurate column types assigned, not UNKNOWN. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1815) Unable to locate Oracle Sequence filter

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1815?page=com.atlassian.jira.plugin.s... ] Work on ARQ-1815 stopped by Bartosz Majsak. ------------------------------------------- > Unable to locate Oracle Sequence filter > --------------------------------------- > > Key: ARQ-1815 > URL: https://issues.jboss.org/browse/ARQ-1815 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Priority: Blocker > Fix For: persistence_1.0.0.next > > > When trying to define custom table filter using > {{<property name=“customTableFilter”>org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider</property>}} > It's resulting in > {{Unable to find sequence filter for org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider. Using default database sequence filter.}} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1815) Unable to locate Oracle Sequence filter

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1815?page=com.atlassian.jira.plugin.s... ] Work on ARQ-1815 started by Bartosz Majsak. ------------------------------------------- > Unable to locate Oracle Sequence filter > --------------------------------------- > > Key: ARQ-1815 > URL: https://issues.jboss.org/browse/ARQ-1815 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Priority: Blocker > Fix For: persistence_1.0.0.next > > > When trying to define custom table filter using > {{<property name=“customTableFilter”>org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider</property>}} > It's resulting in > {{Unable to find sequence filter for org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider. Using default database sequence filter.}} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues September 2014