March 2013 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-960) Provide the way to specify the strategy on instantiting AppllicationContext e.g. each test method or each test case

by Jakub Narloch (JIRA)

[ https://issues.jboss.org/browse/ARQ-960?page=com.atlassian.jira.plugin.sy... ] Work on ARQ-960 started by Jakub Narloch. > Provide the way to specify the strategy on instantiting AppllicationContext e.g. each test method or each test case > -------------------------------------------------------------------------------------------------------------------- > > Key: ARQ-960 > URL: https://issues.jboss.org/browse/ARQ-960 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Spring > Reporter: Jakub Narloch > Assignee: Jakub Narloch > Fix For: spring_1.0.0.next > > > Currently the application context is being created once per test case and being destroyed afterwards by ApplicationContextDestroyer. First but all it would be better to have the application context created once per test case, but still in some situation it would be good to be able to run each tests with completly new ApplicationContext. So altogether it would be preferable to enable user the deicision on how the application context should be handled by the extension. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-960) Provide the way to specify the strategy on instantiting AppllicationContext e.g. each test method or each test case

by Jakub Narloch (JIRA)

[ https://issues.jboss.org/browse/ARQ-960?page=com.atlassian.jira.plugin.sy... ] Jakub Narloch updated ARQ-960: ------------------------------ Description: Currently the application context is being created once per test case and being destroyed afterwards by ApplicationContextDestroyer. First but all it would be better to have the application context created once per test case, but still in some situation it would be good to be able to run each tests with completly new ApplicationContext. So altogether it would be preferable to enable user the deicision on how the application context should be handled by the extension. (was: Currently the application context is being created once per test case and being destroyed afterwards by ApplicationContextDestroyer. In some situation it would be better to be able to run each tests with completly new ApplicationContext.) > Provide the way to specify the strategy on instantiting AppllicationContext e.g. each test method or each test case > -------------------------------------------------------------------------------------------------------------------- > > Key: ARQ-960 > URL: https://issues.jboss.org/browse/ARQ-960 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Spring > Reporter: Jakub Narloch > Assignee: Jakub Narloch > Fix For: spring_1.0.0.next > > > Currently the application context is being created once per test case and being destroyed afterwards by ApplicationContextDestroyer. First but all it would be better to have the application context created once per test case, but still in some situation it would be good to be able to run each tests with completly new ApplicationContext. So altogether it would be preferable to enable user the deicision on how the application context should be handled by the extension. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1357) link between arquillian json to stacks runtimes

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1357?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen commented on ARQ-1357: ------------------------------------ You want connection from arq.json:container -> stacks.yaml:availableRuntimes ? > link between arquillian json to stacks runtimes > ------------------------------------------------ > > Key: ARQ-1357 > URL: https://issues.jboss.org/browse/ARQ-1357 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Max Rydahl Andersen > > It would be interesting to have a link between https://raw.github.com/forge/plugin-arquillian/master/src/main/resources/... and https://raw.github.com/jboss-jdf/jdf-stack/master/stacks.yaml which defines download locations for runtimes which are not necessarily all in maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1357) link between arquillian json to stacks runtimes

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1357?page=com.atlassian.jira.plugin.s... ] Max Rydahl Andersen commented on ARQ-1357: ------------------------------------------ this is something both forge and eclipse tooling could use. > link between arquillian json to stacks runtimes > ------------------------------------------------ > > Key: ARQ-1357 > URL: https://issues.jboss.org/browse/ARQ-1357 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Max Rydahl Andersen > > It would be interesting to have a link between https://raw.github.com/forge/plugin-arquillian/master/src/main/resources/... and https://raw.github.com/jboss-jdf/jdf-stack/master/stacks.yaml which defines download locations for runtimes which are not necessarily all in maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1357) link between arquillian json to stacks runtimes

by Max Rydahl Andersen (JIRA)

Max Rydahl Andersen created ARQ-1357: ---------------------------------------- Summary: link between arquillian json to stacks runtimes Key: ARQ-1357 URL: https://issues.jboss.org/browse/ARQ-1357 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Max Rydahl Andersen It would be interesting to have a link between https://raw.github.com/forge/plugin-arquillian/master/src/main/resources/... and https://raw.github.com/jboss-jdf/jdf-stack/master/stacks.yaml which defines download locations for runtimes which are not necessarily all in maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-679) dependencies in manifest.mf ignored when running maven install

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-679?page=com.atlassian.jira.plugin.sy... ] Bartosz Majsak updated ARQ-679: ------------------------------- Assignee: Bartosz Majsak > dependencies in manifest.mf ignored when running maven install > -------------------------------------------------------------- > > Key: ARQ-679 > URL: https://issues.jboss.org/browse/ARQ-679 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBoss AS Containers > Affects Versions: 1.0.0.CR6 > Environment: Windows > Reporter: Michael Voegele > Assignee: Bartosz Majsak > Labels: arquillian, manifest, maven > > I use following components / versions: > arquillian-junit-container - 1.0.0.CR6 > jboss - 7.1.0.Beta1 > jboss-as-arquillian-container-remote - 7.1.0.Beta1 > junit - 4.10 > I have folloging testcase: > @RunWith(Arquillian.class) > public class DatasourceSessionBeanTest { > @Deployment > public static JavaArchive createTestArchive() { > JavaArchive javaArchive = ShrinkWrap.create(JavaArchive.class, "datasource-test.jar"); > javaArchive.addClasses(BeanInterceptor.class); > javaArchive.addClasses(DatasourceServiceRemote.class, DatasourceSessionBean.class); > javaArchive.addClasses(AlcatrazUser.class, DataTransferObject.class); > javaArchive.addClasses(AlcatrazDAO.class, MatchMode.class); > javaArchive.addAsManifestResource("META-INF/persistence.xml", "persistence.xml"); > javaArchive.addAsManifestResource("META-INF/MANIFEST.MF", "MANIFEST.MF"); > // javaArchive.addPackages(true, "org.slf4j"); > // javaArchive.addPackages(true, "org.jboss.logmanager"); > System.out.println(javaArchive.toString(true)); > return javaArchive; > } > @EJB(mappedName = "java:app/datasource-test/DatasourceSessionBean") > private DatasourceServiceRemote datasourceService; > @Test > public void testGetByRoid() { > AlcatrazUser alcatrazUser = datasourceService.getByRoid("2531781"); > assertNotNull("Result should not be null.", alcatrazUser); > } > } > -> A manifest.mf is added containing 'Dependencies: org.slf4j' > When running the test "as a junit test", slf4j is found and logging works. > When the tests are executed from maven lifecycle, I get a ClassNotFoundException org.slf4j.Logger and the test fails. > By adding dependencies to org.slf4j and org.jboss.logmanager to the pom and by adding them to the ShrinkWrap archive (see the two commented lines), the test works, although no logging is done. > Dependencies to modules in manifest.mf should also be recognized when the tests are run from maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-272) guardXhr does not work for redirected pages

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-272?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-272: ----------------------------------- If you do redirect, then it might be your case. {{guardXhr}} will wait for a page to indicate that XHR has happened. If there will be redirect caused by callback in AJAX request, and HTTP request will be issued, then we can't deterministically say if XHR or HTTP was caused. In this case I would say we should make guardHttp safe for redirection caused by XHR response. > guardXhr does not work for redirected pages > ------------------------------------------- > > Key: ARQGRA-272 > URL: https://issues.jboss.org/browse/ARQGRA-272 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.0.0.Alpha3 > Reporter: Lukáš Fryč > Priority: Critical > Fix For: 2.0.0.Beta1 > > > Try to add guardXhr here to this call: > https://github.com/richfaces/core/blob/bb83bc8e892eec5ab9a83ec3ec060da5e1... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-272) guardXhr does not work for redirected pages

by Alex Chau (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-272?page=com.atlassian.jira.plugin... ] Alex Chau commented on ARQGRA-272: ---------------------------------- Does this issue cause Graphene to mix up HTTP and XHR for AJAX redirections? I'm having an issue where a test with FirefoxDriver detects HTTP but HtmlUnitDriver (and PhantomJS/GhostDriver) detects XHR. > guardXhr does not work for redirected pages > ------------------------------------------- > > Key: ARQGRA-272 > URL: https://issues.jboss.org/browse/ARQGRA-272 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.0.0.Alpha3 > Reporter: Lukáš Fryč > Priority: Critical > Fix For: 2.0.0.Beta1 > > > Try to add guardXhr here to this call: > https://github.com/richfaces/core/blob/bb83bc8e892eec5ab9a83ec3ec060da5e1... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1352) Script can not insert unix path separator '/' into the DB

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1352?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak resolved ARQ-1352. --------------------------------- Resolution: Done Thank you! Pushed upstream. > Script can not insert unix path separator '/' into the DB > --------------------------------------------------------- > > Key: ARQ-1352 > URL: https://issues.jboss.org/browse/ARQ-1352 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Sandor Bodo-Merle > Assignee: Sandor Bodo-Merle > Fix For: persistence_1.0.0.next > > Attachments: 0001-ScriptExecutor-fix-commit-parsing.patch > > > I have a test class which try to insert a unix path value in the DB on schema creation: > @CreateSchema({"setup.sql"}) > public class UserTest { > ... > } > Th the ScriptExecutor introduced in 1.0.0.Alpha6 will iron out the '/' character from the path on insert - like in the following small example: > public class main { > public static void main(String[] args) { > final String ANSI_SQL_COMMENTS_PATTERN = "--.*|//.*|(?s)/\\\\*.*?\\\\*/|(?s)\\{.*?\\}"; > String script = "INSERT INTO config (name, value) VALUES ('path', '/home/sbodo/test.txt');"; > System.out.println(script.replaceAll(ANSI_SQL_COMMENTS_PATTERN, "")); > } > } > Output is: > INSERT INTO config (name, value) VALUES ('path', 'sbodo/test.txt'); > instead of: > INSERT INTO config (name, value) VALUES ('path', '/home/sbodo/test.txt'); > Tested with Jboss 7.1.1 and Postgres 9.1. > The test worked fine in 1.0.0.Alpha5. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1352) Script can not insert unix path separator '/' into the DB

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1352?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak updated ARQ-1352: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-extension-persistence/pull/30 > Script can not insert unix path separator '/' into the DB > --------------------------------------------------------- > > Key: ARQ-1352 > URL: https://issues.jboss.org/browse/ARQ-1352 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Sandor Bodo-Merle > Assignee: Sandor Bodo-Merle > Fix For: persistence_1.0.0.next > > Attachments: 0001-ScriptExecutor-fix-commit-parsing.patch > > > I have a test class which try to insert a unix path value in the DB on schema creation: > @CreateSchema({"setup.sql"}) > public class UserTest { > ... > } > Th the ScriptExecutor introduced in 1.0.0.Alpha6 will iron out the '/' character from the path on insert - like in the following small example: > public class main { > public static void main(String[] args) { > final String ANSI_SQL_COMMENTS_PATTERN = "--.*|//.*|(?s)/\\\\*.*?\\\\*/|(?s)\\{.*?\\}"; > String script = "INSERT INTO config (name, value) VALUES ('path', '/home/sbodo/test.txt');"; > System.out.println(script.replaceAll(ANSI_SQL_COMMENTS_PATTERN, "")); > } > } > Output is: > INSERT INTO config (name, value) VALUES ('path', 'sbodo/test.txt'); > instead of: > INSERT INTO config (name, value) VALUES ('path', '/home/sbodo/test.txt'); > Tested with Jboss 7.1.1 and Postgres 9.1. > The test worked fine in 1.0.0.Alpha5. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues March 2013