March 2013 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-1319) Warp: Jacoco support

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1319?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč edited comment on ARQ-1319 at 3/1/13 4:00 AM: --------------------------------------------------------- Hey Aris, great job with investigations! The initial intention was to verify that Warp-based tests coverage is reported correctly. Configuring Warp's code coverage is actually nice consequence and I will merge it once it will work correctly. The problem here is that even in the ant-generated reporting, I can't see coverage of e.g. TestingServlet ({{ftest}} project, {{org.jboss.arquillian.warp.ftest}} package), which should be actually hit several times - this is what fundamentally Warp users wants. I guess there is some problem with reporting from Warp-based tests, e.g. does the command service does not work correctly? Does it provide correct data? was (Author: lfryc): Hey Aris, great job with investigations! The initial intention was to verify that Warp-based tests coverage is reported correctly. Configuring Warp's code coverage is actually nice consequence and I will merge it once it will work correctly. The problem here is that even in the ant-generated reporting, I can't see coverage of e.g. TestingServlet ({{ftest}} project, {{org.jboss.arquillian.warp.ftest}} package), which should be actually hit several times - this is what actually Warp users wants. > 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č > Fix For: warp_1.0.0.Beta1 > > Attachments: jacoco.jpg, warp-jacoco.png > > > 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 Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1319?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on ARQ-1319: --------------------------------- Hey Aris, great job with investigations! The initial intention was to verify that Warp-based tests coverage is reported correctly. Configuring Warp's code coverage is actually nice consequence and I will merge it once it will work correctly. The problem here is that even in the ant-generated reporting, I can't see coverage of e.g. TestingServlet ({{ftest}} project, {{org.jboss.arquillian.warp.ftest}} package), which should be actually hit several times - this is what actually Warp users wants. > 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č > Fix For: warp_1.0.0.Beta1 > > Attachments: jacoco.jpg, warp-jacoco.png > > > 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-1320) Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for commiting response.

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1320?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1320: ---------------------------- Fix Version/s: warp_1.0.0.Beta1 (was: 1.1.0.Beta1) > Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for commiting 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 > Assignee: Lukáš Fryč > Priority: Blocker > Fix For: warp_1.0.0.Beta1 > > > 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 commiting response.

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1320?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1320: ---------------------------- Priority: Blocker (was: Major) > Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for commiting 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 > Assignee: Lukáš Fryč > Priority: Blocker > > 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 commiting response.

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1320?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1320: ---------------------------- Fix Version/s: 1.1.0.Beta1 > Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for commiting 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 > Assignee: Lukáš Fryč > Priority: Blocker > Fix For: 1.1.0.Beta1 > > > 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-1321) Support for HTTPS in URLs injected with @ArquillianResource

by Samuel Santos (JIRA)

[ https://issues.jboss.org/browse/ARQ-1321?page=com.atlassian.jira.plugin.s... ] Samuel Santos commented on ARQ-1321: ------------------------------------ I agree, the qualifier annotation looks better. > Support for HTTPS in URLs injected with @ArquillianResource > ----------------------------------------------------------- > > Key: ARQ-1321 > URL: https://issues.jboss.org/browse/ARQ-1321 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Samuel Santos > Assignee: Samuel Santos > > When injecting an URL like the following: > {code:java} > @ArquillianResource URL url; > {code} > HTTP protocol will always be used. This happens because "http" is hard-coded in {{URLResourceProvider}}. > Vineet Reynolds suggested that we can create the type {{SecureUrl}} and a {{SecureUrlResourceProvider}} to allow us to use HTTPS: > {code:java} > @ArquillianResource SecureUrl url; > {code} > Any comment? -- 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-1321) Support for HTTPS in URLs injected with @ArquillianResource

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1321?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen commented on ARQ-1321: ------------------------------------ How about adding some form of qualifier to the ArquillanResource instead of a new type. If we can find a class that can match the 'filter' in the ArquillianResource annotation: {code} @ArquillianResource(HTTPS.class) URL url; {code} or a qualifier annotation {code} @ArquillianResource @Secure URL url; {code} > Support for HTTPS in URLs injected with @ArquillianResource > ----------------------------------------------------------- > > Key: ARQ-1321 > URL: https://issues.jboss.org/browse/ARQ-1321 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Samuel Santos > Assignee: Samuel Santos > > When injecting an URL like the following: > {code:java} > @ArquillianResource URL url; > {code} > HTTP protocol will always be used. This happens because "http" is hard-coded in {{URLResourceProvider}}. > Vineet Reynolds suggested that we can create the type {{SecureUrl}} and a {{SecureUrlResourceProvider}} to allow us to use HTTPS: > {code:java} > @ArquillianResource SecureUrl url; > {code} > Any comment? -- 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-1321) Support for HTTPS in URLs injected with @ArquillianResource

by Samuel Santos (JIRA)

Samuel Santos created ARQ-1321: ---------------------------------- Summary: Support for HTTPS in URLs injected with @ArquillianResource Key: ARQ-1321 URL: https://issues.jboss.org/browse/ARQ-1321 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Samuel Santos Assignee: Samuel Santos When injecting an URL like the following: {code:java} @ArquillianResource URL url; {code} HTTP protocol will always be used. This happens because "http" is hard-coded in {{URLResourceProvider}}. Vineet Reynolds suggested that we can create the type {{SecureUrl}} and a {{SecureUrlResourceProvider}} to allow us to use HTTPS: {code:java} @ArquillianResource SecureUrl url; {code} Any comment? -- 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 March 2013