[
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