[jira] [Updated] (SUREFIRE-1614) JUnit Runner that writes to System.out corrupts Surefire's STDOUT when using JUnit's Vintage Engine

["Tibor Digana (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SUREFIRE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tibor Digana updated SUREFIRE-1614:
-----------------------------------
    Fix Version/s: 3.0.0-M3

> JUnit Runner that writes to System.out corrupts Surefire's STDOUT when using JUnit's Vintage Engine
> ---------------------------------------------------------------------------------------------------
>
>                 Key: SUREFIRE-1614
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1614
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: JUnit 5.x support
>    Affects Versions: 2.22.1, 3.0.0-M2
>            Reporter: Andy Wilkinson
>            Assignee: Christian Stein
>            Priority: Major
>             Fix For: 3.0.0-M3
>
>         Attachments: surefire-stream-corruption-bug.zip
>
>
> When JUnit Jupiter's Vintage Engine is used to run tests written using the JUnit 4 API, output to the console from a {{TestRunner}} results in Surefire's STDOUT being corrupted:
> {noformat}
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM 1. See FAQ web page and the dump file […]{noformat}
> Note that the test runner is simply calling {{System.out}}. This is to simulate the real world setup where the runner performs some logging that ultimately results in a console appender calling {{System.out}}. The same arrangement does not cause a problem when run using JUnit 4. An initial investigation suggests that the Vintage Engine calls the custom {{TestRunner}} earlier and, it would appear, at a time when Surefire cannot tolerate output to {{System.out}}.
> I have attached a minimal project that reproduces the problem. Running {{./mvnw -Pjunit5 test}} will reproduce the corruption. Running {{./mvnw -Pjunit4 test}} will not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)