March 2013 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-1350) Drone: allow reuse of session even though all capabilities are not serializable

by Lukáš Fryč (JIRA)

Lukáš Fryč created ARQ-1350: ------------------------------- Summary: Drone: allow reuse of session even though all capabilities are not serializable Key: ARQ-1350 URL: https://issues.jboss.org/browse/ARQ-1350 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Extension - Drone Reporter: Lukáš Fryč Assignee: Karel Piwko Remote drivers might store non-serializable instances in Capabilities map. Drone fails to reuse such browsers since it is not able to store and serialize their capabilities in ReusedSession object. One example of such a driver is PhantomJSDriver which stores object under key 'proxy': com.google.common.collect.Maps$TransformedEntriesMap. --- In order to maximize ability of session reusal, Drone may avoid reusing driver's capabilities at own, but try serialization of each capabilities entry separately and store them in new instance of DesiredCapabilities. This allows to reuse PhantomJS sessions. -- 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-1349) Drone: upgrade Selenium to 2.31.0 and PhantomJS to 1.0.3-dev

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1349?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1349: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/22 > Drone: upgrade Selenium to 2.31.0 and PhantomJS to 1.0.3-dev > ------------------------------------------------------------ > > Key: ARQ-1349 > URL: https://issues.jboss.org/browse/ARQ-1349 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Extension - Drone > Reporter: Lukáš Fryč > Assignee: Karel Piwko > Priority: Minor > > PhantomJS to 1.0.3-dev contains [~jpapouse]'s changes which allows to use his prototype of binary distribution. -- 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-1349) Drone: upgrade Selenium to 2.31.0 and PhantomJS to 1.0.3-dev

by Lukáš Fryč (JIRA)

Lukáš Fryč created ARQ-1349: ------------------------------- Summary: Drone: upgrade Selenium to 2.31.0 and PhantomJS to 1.0.3-dev Key: ARQ-1349 URL: https://issues.jboss.org/browse/ARQ-1349 Project: Arquillian Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Extension - Drone Reporter: Lukáš Fryč Assignee: Karel Piwko Priority: Minor PhantomJS to 1.0.3-dev contains [~jpapouse]'s changes which allows to use his prototype of binary distribution. -- 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-1255) Multiple deployments is not working in Weld SE container

by Antonin Stefanutti (JIRA)

[ https://issues.jboss.org/browse/ARQ-1255?page=com.atlassian.jira.plugin.s... ] Antonin Stefanutti commented on ARQ-1255: ----------------------------------------- Provided that Weld SE container will support multiple deployments, shouldn't the test class be a _{{@Deployment}} unit_ along with the other ones (or scanned by CDI as you mentioned) be enough to solve the second issue, at least for the two test cases that I attached. The second issue that you're mentioning, if I understand it correctly, is going a step further with an additional use case where {{@Inject}} annotated fields/methods would be filtered given the specified {{@Deployment}} to avoid having {{DeploymentException}} thrown. However, in the two attached use cases, this is not really needed and that would make sense functionally speaking to have that exception raised if I were using {{@OperateOnDeployment("bean2-jar")}} instead of {{@OperateOnDeployment("beans-jar")}} in test case 2 for example. > Multiple deployments is not working in Weld SE container > -------------------------------------------------------- > > Key: ARQ-1255 > URL: https://issues.jboss.org/browse/ARQ-1255 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld Containers > Affects Versions: 1.0.0.CR5 > Reporter: Antonin Stefanutti > Attachments: Bean1.java, Bean2.java, MultipleDeploymentArquilianCdiTest.java, OperateOnDeploymentArquilianCdiTest.java, pom.xml, test_case_1_stacktrace.txt, test_case_2_stacktrace.txt > > > As described in [Multiple Deployments|https://docs.jboss.org/author/display/ARQ/Multiple+Deployments], multiple {{@Deployment}} annotated methods can be declared in a test class. In addition, the {{@OperateOnDeployment}} annotation enables the selection of a particular _deployment_ per test method. > However, when using Arquillian with a Weld SE container, the CDI container isn't deployed with the expected archives which ends up having {{DeploymentException}} thrown, as illustrated in the test cases below: > *Test case 1:* > {code} > @RunWith(Arquillian.class) > public class MultipleDeploymentArquilianCdiTest { > @Inject > private Bean1 bean1; > @Inject > private Bean2 bean2; > @Deployment(name = "bean1-jar") > public static Archive<?> createBean1Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Deployment(name = "bean2-jar") > public static Archive<?> createBean2Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Test > public void multiDeploymentTest() { > assertNotNull(bean1); > assertNotNull(bean2); > } > } > {code} > *Test case 2:* > {code} > @RunWith(Arquillian.class) > public class OperateOnDeploymentArquilianCdiTest { > @Inject > private Bean1 bean1; > @Inject > private Bean2 bean2; > @Deployment(name = "beans-jar") > public static Archive<?> createBeansJar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Deployment(name = "bean1-jar") > public static Archive<?> createBean1Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Deployment(name = "bean2-jar") > public static Archive<?> createBean2Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Test > @OperateOnDeployment("beans-jar") > public void singleDeploymentTest() { > assertNotNull(bean1); > assertNotNull(bean2); > } > } > {code} > In both cases, the following exception is thrown: > {code} > org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Bean2] with qualifiers [@Default] at injection point [[field] @Inject private arquillian.test.OperateOnDeploymentArquilianCdiTest.bean2] > {code} > Note that test case 2 is working when only {{@Deployment(name = "beans-jar")}} is declared. > Test classes and the {{pom.xml}} are attached. -- 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-1320) Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for committing response.

by Jakub Narloch (JIRA)

[ https://issues.jboss.org/browse/ARQ-1320?page=com.atlassian.jira.plugin.s... ] Jakub Narloch commented on ARQ-1320: ------------------------------------ I added all the methods from HttpServletResponse and ServletResponse that will eventually commit the response and made it unmodificable afterwards. The one more thing we need to consider is how the sendError(int, String) method should work. According to the docs, the methods can override the response stream and clear the headers, but more over it can affect the execution chain whenever there are error page defined in the web.xml Also, there is one more thing we need to consider if the wrapper is commited, should we implement the rest of the methods according to the spec, so that there won't have any effect if the isCommitted() == true? > Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for committing response. > ----------------------------------------------------------------------------------------------------------- > > Key: ARQ-1320 > URL: https://issues.jboss.org/browse/ARQ-1320 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Jakub Narloch > Priority: Blocker > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > The flushBuffer(http://docs.oracle.com/javaee/6/api/javax/servlet/ServletResp... which causes the response to be marked as commited. and Adding afterwards any headers to the response has no effect. > We should override the that method and prevent it's default behaviour. > Also, it would be good idea to check the specs for any other method that could commit the message and prevent from enriching it by Warp. -- 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-1320) Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for committing response.

by Jakub Narloch (JIRA)

[ https://issues.jboss.org/browse/ARQ-1320?page=com.atlassian.jira.plugin.s... ] Jakub Narloch updated ARQ-1320: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-warp/pull/15 Pull request linked. > Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for committing response. > ----------------------------------------------------------------------------------------------------------- > > Key: ARQ-1320 > URL: https://issues.jboss.org/browse/ARQ-1320 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Jakub Narloch > Priority: Blocker > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > The flushBuffer(http://docs.oracle.com/javaee/6/api/javax/servlet/ServletResp... which causes the response to be marked as commited. and Adding afterwards any headers to the response has no effect. > We should override the that method and prevent it's default behaviour. > Also, it would be good idea to check the specs for any other method that could commit the message and prevent from enriching it by Warp. -- 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-1320) Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for committing response.

by Jakub Narloch (JIRA)

[ https://issues.jboss.org/browse/ARQ-1320?page=com.atlassian.jira.plugin.s... ] Jakub Narloch updated ARQ-1320: ------------------------------- Summary: Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for committing response. (was: Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for commiting response.) > Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for committing response. > ----------------------------------------------------------------------------------------------------------- > > Key: ARQ-1320 > URL: https://issues.jboss.org/browse/ARQ-1320 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Jakub Narloch > Priority: Blocker > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > The flushBuffer(http://docs.oracle.com/javaee/6/api/javax/servlet/ServletResp... which causes the response to be marked as commited. and Adding afterwards any headers to the response has no effect. > We should override the that method and prevent it's default behaviour. > Also, it would be good idea to check the specs for any other method that could commit the message and prevent from enriching it by Warp. -- 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-1319) Warp: Jacoco support

by Aris Tzoumas (JIRA)

[ https://issues.jboss.org/browse/ARQ-1319?page=com.atlassian.jira.plugin.s... ] Aris Tzoumas commented on ARQ-1319: ----------------------------------- ARQ-934 Pull Request will fix Jacoco's operation. After that all we have to do is to enable Arquillian Jacoco Plugin on jsf-ftest too. > Warp: Jacoco support > -------------------- > > Key: ARQ-1319 > URL: https://issues.jboss.org/browse/ARQ-1319 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Warp > Reporter: Lukáš Fryč > Assignee: Aris Tzoumas > Fix For: warp_1.0.0.Beta1 > > Attachments: ftest-coverage.jpg, jacoco.jpg, warp-jacoco.png > > Original Estimate: 2 days > Remaining Estimate: 2 days > > The support for CommandService was committed in ARQ-1027, which enabled us to run {{arquillian-extension-jacoco}}. > However as report from the Warp's build shows, the reporting isn't successful - report doesn't seem to contain any hits. > We need to investigate and once ready, we should use [{{check}}|http://www.eclemma.org/jacoco/trunk/doc/check-mojo.html] goal to be sure that coverage is reported successfully from Warp's tests. -- 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-1319) Warp: Jacoco support

by Aris Tzoumas (JIRA)

[ https://issues.jboss.org/browse/ARQ-1319?page=com.atlassian.jira.plugin.s... ] Work on ARQ-1319 started by Aris Tzoumas. > Warp: Jacoco support > -------------------- > > Key: ARQ-1319 > URL: https://issues.jboss.org/browse/ARQ-1319 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Warp > Reporter: Lukáš Fryč > Assignee: Aris Tzoumas > Fix For: warp_1.0.0.Beta1 > > Attachments: ftest-coverage.jpg, jacoco.jpg, warp-jacoco.png > > Original Estimate: 2 days > Remaining Estimate: 2 days > > The support for CommandService was committed in ARQ-1027, which enabled us to run {{arquillian-extension-jacoco}}. > However as report from the Warp's build shows, the reporting isn't successful - report doesn't seem to contain any hits. > We need to investigate and once ready, we should use [{{check}}|http://www.eclemma.org/jacoco/trunk/doc/check-mojo.html] goal to be sure that coverage is reported successfully from Warp's tests. -- 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-934) Warp: Reuse manager during whole test

by Aris Tzoumas (JIRA)

[ https://issues.jboss.org/browse/ARQ-934?page=com.atlassian.jira.plugin.sy... ] Aris Tzoumas updated ARQ-934: ----------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-warp/pull/14 > Warp: Reuse manager during whole test > ------------------------------------- > > Key: ARQ-934 > URL: https://issues.jboss.org/browse/ARQ-934 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Warp > Reporter: Lukáš Fryč > Assignee: Aris Tzoumas > Priority: Critical > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Manager is created for each request independently: > https://github.com/arquillian/arquillian-extension-warp/blob/master/impl/... > {quote} > <aslak> Scopes a bound to ThreadLocals, so you'll need to 'reactivate' application scope pr request > {quote} -- 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