[
https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tuomas Kiviaho updated SUREFIRE-811:
------------------------------------
Attachment: ConsoleOutputCapture.patch
I've been using the remoting approach by weawing an aspect ontop of
"ForkedBooter" for a while now and the only thing that seems to be causing
headache is capturing of the console output that is applied by surefire
provider to both System out and err.
Currently there is no logic preventing it from functioning in such threads that
have not been inherited from the thread that turned on the capturing. This
would not be a problem in normal style forking where every thread originated
from ForkedBooter and System out is isolated by the process.
In my case the ForkClient runs in same process and therefore uses the same
System.out/err which are currently captured by surefire provider. Luckily this
doesn't cause stack overflow, because ForkingRunListener - where the output
ultimately ends up just - just encodes the output prior printing it out to the
actual console.
Here's a simple patch that fixed this issue for me.
> remote-testing
> --------------
>
> Key: SUREFIRE-811
> URL: https://jira.codehaus.org/browse/SUREFIRE-811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
> Reporter: Henning Gross
> Attachments: ConsoleOutputCapture.patch
>
>
> Add the possibility to copy the target folder to remote machine and run
> integration-tests there. Copy back the results and handle them as if they
> would have been ran locally.
> I would volounteer to submit a patch for this feature if theres a chance it
> would be accepted.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
