February 2013 - arquillian-issues

[JBoss JIRA] (ARQ-1027) Support CommandService Protocol SPI via Warp Protocol

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1027?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč reassigned ARQ-1027: ------------------------------- Assignee: Lukáš Fryč > Support CommandService Protocol SPI via Warp Protocol > ----------------------------------------------------- > > Key: ARQ-1027 > URL: https://issues.jboss.org/browse/ARQ-1027 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha1 > Reporter: Curtis McMillen > Assignee: Lukáš Fryč > Priority: Critical > Fix For: warp_1.0.0.Beta1 > > Attachments: stacktrace.txt > > Original Estimate: 1 day > Remaining Estimate: 1 day > > It seems there is a problem with running Warp tests if arquillian-jacoco is on the classpath. > When WarpFilter fires the AfterSuite event, the writeCoverageData observer in arquillian-jacoco is executing which ultimately leads to a NPE coming from servlet protocol. The full stacktrace is attached. > You can reproduce by simply adding the following dependencies to the pom for warp in arquillian-showcase and then running the BasicJSFUnitTestCase. > {code:xml} > <dependency> > <groupId>org.jboss.arquillian.extension</groupId> > <artifactId>arquillian-jacoco</artifactId> > <version>1.0.0.Alpha3</version> > <scope>test</scope> > </dependency> > <dependency> > <groupId>org.jacoco</groupId> > <artifactId>org.jacoco.core</artifactId> > <version>0.5.7.201204190339</version> > <scope>test</scope> > </dependency> > {code} > Removing these dependencies isn't really an option because I have other arquillian tests not using Warp that I want code coverage on. I tried using alternative annotated with @Specializes thinking I could basically disable the observer in arquillian-jacoco simply by including a different beans.xml in the deployment of my Warp tests. This however fails with "WELD-000047 Specializing bean must extend another bean" which I'm thinking is due to https://issues.jboss.org/browse/WELD-1113. > Any ideas for getting this to work? -- 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-1303) Add Spring StaticApplicationContext

by Jakub Narloch (JIRA)

[ https://issues.jboss.org/browse/ARQ-1303?page=com.atlassian.jira.plugin.s... ] Jakub Narloch commented on ARQ-1303: ------------------------------------ Ok, But in such case, how can I use that in my test? I would have to 'lookup' the bean that is being test each time from the application context. You won't be able to inject you configured beans into the the tests directly. I was thinking about different aproach. How about resigning from class level annotations in favor of 'factory method'. Something like: {code} public class TestCase { @SpringApplicationContext public static ApplicationContext createApplicationContext() { return ... // the application context could be created fully programticly } public void test() { } } {code} In such way we could just @Autowire the beans in to the test class afterwards. Also we would have access to the ApplicationContext by simply adding @Autowired ApplicationContext field. It would work out of the box (likely this feature has been added somewhere in Spring 2.5.x version). The other thing I was thinking was using the same convention as in Spring Test 3.1. You are able to define static inner class annotated with @Configuration and define your beans there. Something like: {code} @SpringAnnotationConfiguration public class TestCase { @Configuration static class ContextConfiguration { @Bean public SomeBean create() { } } public void test() { } } {code} > Add Spring StaticApplicationContext > ----------------------------------- > > Key: ARQ-1303 > URL: https://issues.jboss.org/browse/ARQ-1303 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Spring > Reporter: omid pourhadi > Assignee: Marius Bogoevici > Priority: Minor > Original Estimate: 1 week, 1 day > Remaining Estimate: 1 week, 1 day > > It is a common way that developers programmatically register beans into context specially in testing rather than reading bean definitions from external configuration sources, in this case, you need to use StaticApplicationContext. > As far as my experience concerned, there are some circumstances that you need to have populated context when you are testing > 1. for registering mock objects into context > let's assume we inject a DAO into a service and we want to mock DAO then test our service > {code:title=Bar.java|borderStyle=solid} > public class MockTest(){ > @Mock > Dao dao; > public void testMethod(){ > ctx.getBeanFactory().registerSingleton(dao.getClass().getName(), dao); > } > } > {code} > 2. for specifying classes not packages > sometimes you need to create a spring context by only some specific classes from different packages not the whole packages. > It might be good idea to have an annotation ClassToScan({}) to define whcih classes, you want to scan -- 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-210) Support for GhostDriver / PhantomJS

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-210?page=com.atlassian.jira.plugin... ] Lukáš Fryč edited comment on ARQGRA-210 at 2/18/13 12:11 PM: ------------------------------------------------------------- We will also need to rename artifacts to avoid using original project name: I suggest using extension name *{{phantom}}* ({{arquillian-phantom-binary}}, {{arquillian-phantom-driver}}). was (Author: lfryc): We will also need to rename artifacts to avoid using original project name: I suggest using {{arquillian-phantom-binary}}. > Support for GhostDriver / PhantomJS > ----------------------------------- > > Key: ARQGRA-210 > URL: https://issues.jboss.org/browse/ARQGRA-210 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Lukáš Fryč > Assignee: Jan Papousek > Labels: richfaces > Fix For: 2.0.0.Beta1 > > > PhantomJS / GhostDriver allows to run headless tests with 'close to real experience' thanks to fact PhantomJS is based on Chrome / V8. > ---- > There are proof of concept bits: > https://github.com/lfryc/phantomjs-java > https://github.com/lfryc/ghostdriver-java > https://github.com/lfryc/arquillian-extension-drone/tree/phantomjs > https://github.com/lfryc/arquillian-graphene/tree/phantomjs -- 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-210) Support for GhostDriver / PhantomJS

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-210?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-210: ----------------------------------- We will also need to rename artifacts to avoid using original project name: I suggest using {{arquillian-phantom-binary}}. > Support for GhostDriver / PhantomJS > ----------------------------------- > > Key: ARQGRA-210 > URL: https://issues.jboss.org/browse/ARQGRA-210 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Lukáš Fryč > Assignee: Jan Papousek > Labels: richfaces > Fix For: 2.0.0.Beta1 > > > PhantomJS / GhostDriver allows to run headless tests with 'close to real experience' thanks to fact PhantomJS is based on Chrome / V8. > ---- > There are proof of concept bits: > https://github.com/lfryc/phantomjs-java > https://github.com/lfryc/ghostdriver-java > https://github.com/lfryc/arquillian-extension-drone/tree/phantomjs > https://github.com/lfryc/arquillian-graphene/tree/phantomjs -- 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-210) Support for GhostDriver / PhantomJS

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-210?page=com.atlassian.jira.plugin... ] Lukáš Fryč updated ARQGRA-210: ------------------------------ Assignee: Jan Papousek (was: Lukáš Fryč) > Support for GhostDriver / PhantomJS > ----------------------------------- > > Key: ARQGRA-210 > URL: https://issues.jboss.org/browse/ARQGRA-210 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Lukáš Fryč > Assignee: Jan Papousek > Labels: richfaces > Fix For: 2.0.0.Beta1 > > > PhantomJS / GhostDriver allows to run headless tests with 'close to real experience' thanks to fact PhantomJS is based on Chrome / V8. > ---- > There are proof of concept bits: > https://github.com/lfryc/phantomjs-java > https://github.com/lfryc/ghostdriver-java > https://github.com/lfryc/arquillian-extension-drone/tree/phantomjs > https://github.com/lfryc/arquillian-graphene/tree/phantomjs -- 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-210) Support for GhostDriver / PhantomJS

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-210?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-210: ----------------------------------- Jan, I find the configuration quite cumbersome for end-user (all the profiles which need to setup). ---- I did a proof of concept that we could resolve the artifact with ShrinkWrap Resolver for Maven: {code:java} @Test public void test() { Maven.resolver().resolve("org.jboss.arquillian.phantomjs:phantomjs-binary:jar:unix_amd64:1.8.1") .withoutTransitivity().as(JavaArchive.class); } {code} With {{org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-depchain:2.0.0-beta-2}} I was able to get local resolution in ~0.5sec. I consider it quite fast, but we should still leverage local binary cache as you did already. ---- Could you re-implement it using the technique mentioned above? > Support for GhostDriver / PhantomJS > ----------------------------------- > > Key: ARQGRA-210 > URL: https://issues.jboss.org/browse/ARQGRA-210 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Lukáš Fryč > Assignee: Lukáš Fryč > Labels: richfaces > Fix For: 2.0.0.Beta1 > > > PhantomJS / GhostDriver allows to run headless tests with 'close to real experience' thanks to fact PhantomJS is based on Chrome / V8. > ---- > There are proof of concept bits: > https://github.com/lfryc/phantomjs-java > https://github.com/lfryc/ghostdriver-java > https://github.com/lfryc/arquillian-extension-drone/tree/phantomjs > https://github.com/lfryc/arquillian-graphene/tree/phantomjs -- 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-210) Support for GhostDriver / PhantomJS

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-210?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-210: ----------------------------------- The PhantomJSDriver should be now available in Central: https://github.com/detro/ghostdriver/issues/142 http://code.google.com/p/selenium/issues/detail?id=4939 > Support for GhostDriver / PhantomJS > ----------------------------------- > > Key: ARQGRA-210 > URL: https://issues.jboss.org/browse/ARQGRA-210 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Lukáš Fryč > Assignee: Lukáš Fryč > Labels: richfaces > Fix For: 2.0.0.Beta1 > > > PhantomJS / GhostDriver allows to run headless tests with 'close to real experience' thanks to fact PhantomJS is based on Chrome / V8. > ---- > There are proof of concept bits: > https://github.com/lfryc/phantomjs-java > https://github.com/lfryc/ghostdriver-java > https://github.com/lfryc/arquillian-extension-drone/tree/phantomjs > https://github.com/lfryc/arquillian-graphene/tree/phantomjs -- 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-1027) Support CommandService Protocol SPI via Warp Protocol

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1027?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1027: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Support CommandService Protocol SPI via Warp Protocol > ----------------------------------------------------- > > Key: ARQ-1027 > URL: https://issues.jboss.org/browse/ARQ-1027 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha1 > Reporter: Curtis McMillen > Priority: Critical > Fix For: warp_1.0.0.Beta1 > > Attachments: stacktrace.txt > > Original Estimate: 1 day > Remaining Estimate: 1 day > > It seems there is a problem with running Warp tests if arquillian-jacoco is on the classpath. > When WarpFilter fires the AfterSuite event, the writeCoverageData observer in arquillian-jacoco is executing which ultimately leads to a NPE coming from servlet protocol. The full stacktrace is attached. > You can reproduce by simply adding the following dependencies to the pom for warp in arquillian-showcase and then running the BasicJSFUnitTestCase. > {code:xml} > <dependency> > <groupId>org.jboss.arquillian.extension</groupId> > <artifactId>arquillian-jacoco</artifactId> > <version>1.0.0.Alpha3</version> > <scope>test</scope> > </dependency> > <dependency> > <groupId>org.jacoco</groupId> > <artifactId>org.jacoco.core</artifactId> > <version>0.5.7.201204190339</version> > <scope>test</scope> > </dependency> > {code} > Removing these dependencies isn't really an option because I have other arquillian tests not using Warp that I want code coverage on. I tried using alternative annotated with @Specializes thinking I could basically disable the observer in arquillian-jacoco simply by including a different beans.xml in the deployment of my Warp tests. This however fails with "WELD-000047 Specializing bean must extend another bean" which I'm thinking is due to https://issues.jboss.org/browse/WELD-1113. > Any ideas for getting this to work? -- 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-1027) Support CommandService Protocol SPI via Warp Protocol

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1027?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on ARQ-1027: --------------------------------- The CommandService support for Warp will land in Beta1. > Support CommandService Protocol SPI via Warp Protocol > ----------------------------------------------------- > > Key: ARQ-1027 > URL: https://issues.jboss.org/browse/ARQ-1027 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha1 > Reporter: Curtis McMillen > Priority: Critical > Fix For: warp_1.0.0.Beta1 > > Attachments: stacktrace.txt > > Original Estimate: 1 day > Remaining Estimate: 1 day > > It seems there is a problem with running Warp tests if arquillian-jacoco is on the classpath. > When WarpFilter fires the AfterSuite event, the writeCoverageData observer in arquillian-jacoco is executing which ultimately leads to a NPE coming from servlet protocol. The full stacktrace is attached. > You can reproduce by simply adding the following dependencies to the pom for warp in arquillian-showcase and then running the BasicJSFUnitTestCase. > {code:xml} > <dependency> > <groupId>org.jboss.arquillian.extension</groupId> > <artifactId>arquillian-jacoco</artifactId> > <version>1.0.0.Alpha3</version> > <scope>test</scope> > </dependency> > <dependency> > <groupId>org.jacoco</groupId> > <artifactId>org.jacoco.core</artifactId> > <version>0.5.7.201204190339</version> > <scope>test</scope> > </dependency> > {code} > Removing these dependencies isn't really an option because I have other arquillian tests not using Warp that I want code coverage on. I tried using alternative annotated with @Specializes thinking I could basically disable the observer in arquillian-jacoco simply by including a different beans.xml in the deployment of my Warp tests. This however fails with "WELD-000047 Specializing bean must extend another bean" which I'm thinking is due to https://issues.jboss.org/browse/WELD-1113. > Any ideas for getting this to work? -- 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-1290) Warp: support Servlets 2.5

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1290?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1290: ---------------------------- Fix Version/s: warp_1.0.0.Beta1 > Warp: support Servlets 2.5 > -------------------------- > > Key: ARQ-1290 > URL: https://issues.jboss.org/browse/ARQ-1290 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Lukáš Fryč > Fix For: warp_1.0.0.Beta1 > > > Warp currently uses {{@WebFilter}} and thus it is supported only when using Servlets 3.0 protocol. > Additionally with ARQ-1027, the usage of {{web-fragment.xml}} was introduced. > Warp should detect what protocol is used (2.5 or 3.0) and in case of 2.5, the {{web.xml}} enrichment will be used instead. -- 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 February 2013