February 2013 - arquillian-issues

[JBoss JIRA] (ARQ-1304) Create test ApplicationContext through factory method.

by Jakub Narloch (JIRA)

Jakub Narloch created ARQ-1304: ---------------------------------- Summary: Create test ApplicationContext through factory method. Key: ARQ-1304 URL: https://issues.jboss.org/browse/ARQ-1304 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Extension - Spring Affects Versions: spring_1.0.0.Beta1 Reporter: Jakub Narloch Assignee: Jakub Narloch Fix For: spring_1.0.0.next Current version brings the concept of custom classes, which allows to define the concreate class that will be used to instantiate the ApplicationContext. Maybe it would be good idea to give the user full control on how the ApplicationContext will be created, so he can not only use some specialized implementation but would be also able to configure it correctly. On the code level this would be achive by 'scaning' for static method that will be responsible for creating the ApplicationContext instance e.g.: {code} @SpringApplicationContext ApplicationContext [method_name]() {} {code} -- 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 reassigned ARQ-1303: ---------------------------------- Assignee: Jakub Narloch (was: Marius Bogoevici) > 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: Jakub Narloch > 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] (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: ------------------------------------ > You don't need to lookup the bean, we can provide a feature to autowire beans in a test class by using reflection. please take a look at AbstractSpringInjectionEnricher.java registerBean method My comment was referring to this code snippet: {code} public void testMethod(){ ctx.getBeanFactory().registerSingleton(dao.getClass().getName(), dao); } {code} You won't be able to register the beans in such way and autowire it to the test, since this is done in different test phases and at the moment the Spring context is being re-created before each test. The only sollution to access such created bean would be to lookup it through the BeanFactory. As I see it. We could introduce top level annotation, like for example @SpringStaticConfiguration (or something similar) which will allow to pass array of packages and classes that would be registered. Using this annotation will imply that the test enricher would create StaticApplicationContext and register all the classes/packages. Afterwards it would be used as any other application context. > 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] (ARQ-1286) Support Warp on Java EE 5 (Servlets 2.5) compliant containers

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1286?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1286: ---------------------------- Priority: Critical (was: Major) > Support Warp on Java EE 5 (Servlets 2.5) compliant containers > ------------------------------------------------------------- > > Key: ARQ-1286 > URL: https://issues.jboss.org/browse/ARQ-1286 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Lukáš Fryč > Priority: Critical > Fix For: warp_1.0.0.Beta1 > > > Warp is currently focused on Java EE 6 and higher, since it uses {{@WebFilter}} annotation to intercept incoming requests. > We may decide to support Servlets 2.5 containers as well in case there is enough interest (please vote if you are interested). -- 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 need to test this extension cross-platform wide. > 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] (ARQ-1261) Warp: setup container-compatibility integration builds

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1261?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on ARQ-1261: --------------------------------- Hey Pavol, could you please setup container-compatibility tests for Warp? They could use CloudBees and mock-browser (htmlUnit now, phantomjs if available). This issue has high priority for Beta1. > Warp: setup container-compatibility integration builds > ------------------------------------------------------ > > Key: ARQ-1261 > URL: https://issues.jboss.org/browse/ARQ-1261 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Warp > Reporter: Lukáš Fryč > Assignee: Pavol Pitonak > Fix For: warp_1.0.0.Beta1 > > > We should test compatibility with following containers; > * TomEE > * Glassfish > * WebSphere? > * WebLogic? > * CloudBees? -- 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-1262) Warp: setup browser-compatibility integration tests

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1262?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč reassigned ARQ-1262: ------------------------------- Assignee: Pavol Pitonak Hey Pavol, could you please setup browser-compatibility tests for Warp? They could use CloudBees/OpenShift and SauceLabs (I can provide all required accounts). This issue does not have high priority for Beta1. > Warp: setup browser-compatibility integration tests > --------------------------------------------------- > > Key: ARQ-1262 > URL: https://issues.jboss.org/browse/ARQ-1262 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Warp > Reporter: Lukáš Fryč > Assignee: Pavol Pitonak > Fix For: warp_1.0.0.Beta1 > > > Following containers should be configured: > * htmlUnit > * phantomjs > * CloudBees/SauceLabs > * Chrome > * Firefox > * Internet Explorer -- 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: ---------------------------- Assignee: Aris Tzoumas (was: 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: Aris Tzoumas > 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-1261) Warp: setup container-compatibility integration builds

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1261?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1261: ---------------------------- Assignee: Pavol Pitonak > Warp: setup container-compatibility integration builds > ------------------------------------------------------ > > Key: ARQ-1261 > URL: https://issues.jboss.org/browse/ARQ-1261 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Warp > Reporter: Lukáš Fryč > Assignee: Pavol Pitonak > Fix For: warp_1.0.0.Beta1 > > > We should test compatibility with following containers; > * TomEE > * Glassfish > * WebSphere? > * WebLogic? > * CloudBees? -- 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-1198) Warp: collect requirements for replacing SeamTest and JSFUnit

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1198?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1198: ---------------------------- Labels: hack-idea (was: ) > Warp: collect requirements for replacing SeamTest and JSFUnit > ------------------------------------------------------------- > > Key: ARQ-1198 > URL: https://issues.jboss.org/browse/ARQ-1198 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Reporter: Lukáš Fryč > Labels: hack-idea > Fix For: warp_1.0.0.Beta1 > > > SeamTest: > http://docs.jboss.org/seam/2.0.1.GA/reference/en/html/testing.html > https://docs.jboss.org/author/display/ARQ/Seam+2 > JSFUnit: > http://www.jboss.org/jsfunit -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues February 2013