[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 edited comment on ARQ-1319 at 3/3/13 7:19 AM:
-----------------------------------------------------------
Well Lukáš, you just found a *Bug* in {{CommandEventBus}}...
The case is that the Container may send a {{CoverageDataCommand}} to the client *after* a response has already been sent to the client ({{OutputStream}} is closed). As a result, client's CommandEventBus may have already been closed ({{After}} event has fired on client) and thus it doesn't receive the coverage command.
Actually, there is a race condition between the timer on {{CommandEventBus}} and the {{@After}} event that cancels the timer. Sometimes the {{TimerTask}} manages to process the command, sometimes it doesn't. That's why I was getting inconsistent coverage reports from Jacoco's reporting task.
There are two possible solutions to this problem:
* Add a delay to {{CommandEventBus}} shutdown, so that it has time to process the last Command from the container (should it ever send one).
* Make all container commands happen before {{After}} event fires on client.
Although the first solution may be easier to implement, the second one is the way we should go.
That's why I have prepared the following two commits:
* https://github.com/atzoum/arquillian-extension-warp/commit/6d284459402ebf...
This one closes the response afterwards {{Manager}}'s shudown, so {{CommandEventBus}} stays open for as long it is needed. You may need to review this one, since you have a better understanding of Warp's internals. I basically create a {{NonWritingResponse}} at the beginning of {{WarpFilter}}'s processing, which gets written and closed at the end of the processing.
* https://github.com/atzoum/arquillian-extension-warp/commit/0fa31972597c0b...
This one is an updated Test that should fail if the HTTP Response gets committed before {{AfterSuite}} event is called in the container.
The above two commits are inside my branch:
https://github.com/atzoum/arquillian-extension-warp/tree/race-condition
This branch runs all tests successfully and behaves as expected.
I am also attaching a screenshot with a correct coverage report on {{ftest}} project (https://issues.jboss.org/secure/attachment/12361047/ftest-coverage.jpg).
If you want to add arquillian coverage on *{{jsf-ftest}}*, please don't forget to add the following dependencies on {{pom.xml}}
{noformat}
<dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<scope>test</scope>
</dependency>
{noformat}
was (Author: atzoum):
Well Lukáš, you just found a *Bug* in {{CommandEventBus}}...
The case is that the Container may send a {{CoverageDataCommand}} to the client *after* a response has already been sent to the client ({{OutputStream}} is closed). As a result, client's CommandEventBus may have already been closed ({{After}} event has fired on client) and thus it doesn't receive the coverage command.
Actually, there is a race condition between the timer on {{CommandEventBus}} and the {{@After}} event that cancels the timer. Sometimes the {{TimerTask}} manages to process the command, sometimes it doesn't. That's why I was getting inconsistent coverage reports from Jacoco's reporting task.
There are two possible solutions to this problem:
* Add a delay to {{CommandEventBus}} shutdown, so that it has time to process the last Command from the container (should it ever send one).
* Make all container commands happen before {{After}} event fires on client.
Although the first solution may be easier to implement, the second one is the way we should go.
That's why I have prepared the following two commits:
* https://github.com/atzoum/arquillian-extension-warp/commit/6d284459402ebf...
This one closes the response afterwards {{Manager}}'s shudown, so {{CommandEventBus}} stays open for as long it is needed. You may need to review this one, since you have a better understanding of Warp's internals. I basically create a {{NonWritingResponse}} at the beginning of {{WarpFilter}}'s processing, which gets written and closed at the end of the processing.
* https://github.com/atzoum/arquillian-extension-warp/commit/0fa31972597c0b...
This one is an updated Test that should fail if the HTTP Response gets committed before {{AfterSuite}} event is called in the container.
The above two commits are inside my branch:
https://github.com/atzoum/arquillian-extension-warp/tree/race-condition
This branch runs all tests successfully and behaves as expected.
I am also attaching a screenshot with a correct coverage report on {{ftest}} project.
If you want to add arquillian coverage on *{{jsf-ftest}}*, please don't forget to add the following dependencies on {{pom.xml}}
{noformat}
<dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<scope>test</scope>
</dependency>
{noformat}
> 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: ftest-coverage.jpg, 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
13 years, 1 month
[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 updated ARQ-1319:
------------------------------
Attachment: ftest-coverage.jpg
> 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: ftest-coverage.jpg, 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
13 years, 1 month
[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:
-----------------------------------
Well Lukáš, you just found a *Bug* in {{CommandEventBus}}...
The case is that the Container may send a {{CoverageDataCommand}} to the client *after* a response has already been sent to the client ({{OutputStream}} is closed). As a result, client's CommandEventBus may have already been closed ({{After}} event has fired on client) and thus it doesn't receive the coverage command.
Actually, there is a race condition between the timer on {{CommandEventBus}} and the {{@After}} event that cancels the timer. Sometimes the {{TimerTask}} manages to process the command, sometimes it doesn't. That's why I was getting inconsistent coverage reports from Jacoco's reporting task.
There are two possible solutions to this problem:
* Add a delay to {{CommandEventBus}} shutdown, so that it has time to process the last Command from the container (should it ever send one).
* Make all container commands happen before {{After}} event fires on client.
Although the first solution may be easier to implement, the second one is the way we should go.
That's why I have prepared the following two commits:
* https://github.com/atzoum/arquillian-extension-warp/commit/6d284459402ebf...
This one closes the response afterwards {{Manager}}'s shudown, so {{CommandEventBus}} stays open for as long it is needed. You may need to review this one, since you have a better understanding of Warp's internals. I basically create a {{NonWritingResponse}} at the beginning of {{WarpFilter}}'s processing, which gets written and closed at the end of the processing.
* https://github.com/atzoum/arquillian-extension-warp/commit/0fa31972597c0b...
This one is an updated Test that should fail if the HTTP Response gets committed before {{AfterSuite}} event is called in the container.
The above two commits are inside my branch:
https://github.com/atzoum/arquillian-extension-warp/tree/race-condition
This branch runs all tests successfully and behaves as expected.
I am also attaching a screenshot with a correct coverage report on {{ftest}} project.
If you want to add arquillian coverage on *{{jsf-ftest}}*, please don't forget to add the following dependencies on {{pom.xml}}
{noformat}
<dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<scope>test</scope>
</dependency>
{noformat}
> 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: ftest-coverage.jpg, 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
13 years, 1 month
[JBoss JIRA] (ARQ-941) Make Exception.class default for value attribute on @ShouldThrowException
by Michal Matloka (JIRA)
[ https://issues.jboss.org/browse/ARQ-941?page=com.atlassian.jira.plugin.sy... ]
Michal Matloka updated ARQ-941:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/arquillian/arquillian-core/pull/44
> Make Exception.class default for value attribute on @ShouldThrowException
> -------------------------------------------------------------------------
>
> Key: ARQ-941
> URL: https://issues.jboss.org/browse/ARQ-941
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Base Implementation
> Reporter: Dan Allen
> Priority: Minor
> Labels: starter
> Fix For: 2.0.0.Beta1
>
>
> The annotation @ShouldThrowException is expressive enough to be understood as meaning a generic Exception will be thrown (during deployment) unless a more specific exception is specified.
> Therefore, a default should be specified for the value attribute such that:
> @ShouldThrowException == @ShouldThrowException(Exception.class)
> Here's the resulting annotation definition:
> {code:java}
> @Documented
> @Retention(RUNTIME)
> @Target(ElementType.METHOD)
> public @interface ShouldThrowException {
> Class<? extends Exception> value() default Exception.class;
> }
> {code}
> (Alternatively, the default can be Throwable.class, though the value of least surprise is likely Exception.class).
--
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
13 years, 1 month
[JBoss JIRA] (ARQ-1305) Defaults values for @SpringConfiguration and @SpringAnnotationConfiguration
by Jakub Narloch (JIRA)
[ https://issues.jboss.org/browse/ARQ-1305?page=com.atlassian.jira.plugin.s... ]
Jakub Narloch updated ARQ-1305:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Pushed upstream https://github.com/arquillian/arquillian-extension-spring/commit/a08f0129...
Thanks Jakub for your work!
> Defaults values for @SpringConfiguration and @SpringAnnotationConfiguration
> ---------------------------------------------------------------------------
>
> Key: ARQ-1305
> URL: https://issues.jboss.org/browse/ARQ-1305
> 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
>
>
> The idea is similar to the 'convention over configuration' approach from Spring Test.
> When configuring test with @SpringConfiguration when no XML configuration will specified the extension by default should try to load file with exact same name as the test class and additional '-context.xml' suffix e.g.
> For class org.sample.Test the default resource location should be org/sample/Test-context.xml.
> In case of @SpringAnnotationConfiguration when no class or package has been specified the extension by default should scan for static (non final) class annoated with @Configuration and use it when instantiating the AnnotationApplicationContext.
--
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
13 years, 1 month
[JBoss JIRA] (ARQ-1305) Defaults values for @SpringConfiguration and @SpringAnnotationConfiguration
by Jakub Kurlenda (JIRA)
[ https://issues.jboss.org/browse/ARQ-1305?page=com.atlassian.jira.plugin.s... ]
Jakub Kurlenda commented on ARQ-1305:
-------------------------------------
Please see new pull request: https://github.com/arquillian/arquillian-extension-spring/pull/27
> Defaults values for @SpringConfiguration and @SpringAnnotationConfiguration
> ---------------------------------------------------------------------------
>
> Key: ARQ-1305
> URL: https://issues.jboss.org/browse/ARQ-1305
> 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
>
>
> The idea is similar to the 'convention over configuration' approach from Spring Test.
> When configuring test with @SpringConfiguration when no XML configuration will specified the extension by default should try to load file with exact same name as the test class and additional '-context.xml' suffix e.g.
> For class org.sample.Test the default resource location should be org/sample/Test-context.xml.
> In case of @SpringAnnotationConfiguration when no class or package has been specified the extension by default should scan for static (non final) class annoated with @Configuration and use it when instantiating the AnnotationApplicationContext.
--
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
13 years, 1 month
[JBoss JIRA] (ARQ-1323) @EnableWarp annotation.
by Jakub Narloch (JIRA)
[ https://issues.jboss.org/browse/ARQ-1323?page=com.atlassian.jira.plugin.s... ]
Jakub Narloch updated ARQ-1323:
-------------------------------
Fix Version/s: spring_1.0.0.next
> @EnableWarp annotation.
> -----------------------
>
> Key: ARQ-1323
> URL: https://issues.jboss.org/browse/ARQ-1323
> 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
>
>
> Define @EnableWarp annotation that will import the WebMvcConfigurer which will register the WarpInterceptor i.e.:
> {code}
> @Import(? extends WebMvcConfigurer)
> @interface EnableWarp {
> }
> {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
13 years, 1 month
