Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
3.0.0-M5
-
None
Description
This is a follow-up to SUREFIRE-1788 which was closed prematurely even though there still were open issues which were discussed there initially. Basically the situation is as follows:
- I use Java agents writing to stdOut and stdErr in my tests.
- I was annoyed that Surefire/Failsafe were writing lots of [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM lines into *-jvmRun1.dumpstream files. Tibor Digana then told me to use <forkNode implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/> in my POM in order to fix the issue.
- I tried this in version 3.0.0-M5, but unfortunately, it makes Surefire/Failsafe freeze if a Java agent prints something to stdOut or stdErr. This happens both in M5 and in M6-SNAPSHOT after both
SUREFIRE-1788andSUREFIRE-1809have been merged in already. - My sample project reproduces the issue as soon as you uncomment the option in the POM and run mvn clean verify.
- The second issue is: Not using this option leads to garbled log output when a Java agent writes to both stdOut and stdErr before/during tests. See comments in class Agent.DummyTransformer for examples for garbled log lines and also comments in pom.xml for further information.
- If the garbled output would also appear with this option activated, cannot be tested at present due to the Surefire/Failsafe freeze. I will re-test that after the freeze has been fixed and before this issue can be closed.
Attachments
Attachments
Issue Links
- relates to
-
SUREFIRE-1801 New TCP communication mode defers "Listening for transport" debug message
- Open
-
SUREFIRE-2058 Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
- Closed
-
SUREFIRE-1788 Unhandled native logs in SurefireForkChannel
- Closed
- links to
(1 links to)