6:33 a.m.
[
https://issues.jboss.org/browse/ARQ-1027?page=com.atlassian.jira.plugin.s...
]
Aris Tzoumas commented on ARQ-1027:
-----------------------------------
I may have come up with a hackish solution...
It is as follows:
1) Setup a ServletProtocol event Bus when {{LocalExecutionEvent}} Event fires (Before the
actual test execution). This bus gets destroyed when {{After}} Event fires.
2) Change {{WarpFilter}} to let requests for {{ServletTestRunner}} pass through (but first
cache the call_id - {{ThreadLocal<String> currentCall}} static variable of
{{ServletTestRunner}}). The requests which are routed to the ServletTestRunner are those
made by the event bus I mentioned earlier.
3) Now, inside {{WarpFilter}}, before calling {{doFilterHttp}}, it resets
ServletTestRunner's call_id to the cached value it got before.
This way, when Jacoco catches the {{AfterSuite}} event inside the remote container, it
will successfully insert a new {{CoverageDataCommand}} inside ServletTestRunner's
events Map (since the ThreadLocal variable has been initialized). This command will be
read by the EventBus and the Command event will be fired inside the client for
Jacoco's observer to work and log the coverage data. I tested it and it works :)
One problem I faced is that ServletTestRunner's {{currentCall}} variable has a default
access modifier, so I had to create a utility Class inside warp-impl with package name
"{{org.jboss.arquillian.protocol.servlet.runner}}" in order to be able to set
that variable.
I cannot think of another solution that wouldn't involve changing the whole Warp's
architecture (along with some ServletProtocol additions).
Please, let me know if you are interested in my solution, I could prepare a pull request
for you (after I first polish it a bit) :)
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: Lukáš Fryč
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
4814
days inactive
4814
days old
arquillian-issues@lists.jboss.org
0 comments
1 participants
participants (1)
-
Aris Tzoumas (JIRA)