[
https://issues.apache.org/jira/browse/SUREFIRE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098412#comment-17098412
]
Alexander Kriegisch edited comment on SUREFIRE-1614 at 5/3/20, 12:29 PM:
-------------------------------------------------------------------------
[~tibordigana], I just wanted to answer to your comments which now are gone. I
did check and there were no dump files in my failsafe reports directory like
before. And that you don't care about console log output does not help me
either. The system console exists for a reason and that reason is to print on
it. Now everything my Java agent prints is gone and I need that output. You may
want to consider the fact that not all tools in this world have been designed
to run under Maven, they just run stand-alone in a JVM and Maven Surefire (or
Failsafe in my case) wraps the JVM start in order to perform tests. Tests and
console logs go hand in hand because console output is needed for debugging
failing tests. So not to have the console output in the log is not an option
for any normal user. I don't want to check the additional log files in the
reports directory. Usually tools do that in order to present pretty reports.
That is a secondary issue though. During development, especially on my local
machine, I just want to check Maven's console output.
I don't even understand what you mean by
> If some tool prints to the native system output, it is supposed to be a bug
> of the tool or your library or JVM
How can using normal `System.out.println()` be a bug? Even if I use a logging
framework in my agent's {{premain}} method - which I definitely won't because I
don't pull in a lot of dependencies for a single or a few lines of log output -
the logging framework is configured by default to print to the console. So far,
so simple.
was (Author: kriegaex):
[~tibordigana], I just wanted to answer to your comments which now are gone. I
did check and there were no dump files in my failsafe reports directory like
before. And that you don't care about console log output does not help me
either. The system console exists for a reason and that reason is to print on
it. Now everything my Java agent prints is gone and I need that output. You may
want to consider the fact that not all tools in this world have been designed
to run under Maven, they just run stand-alone in a JVM and Maven Surefire (or
Failsafe in my case) wraps the JVM start in order to perform tests. Tests and
console logs go hand in hand because console output is needed for debugging
failing tests. So not to have the console output in the log is not an option
for any normal user. I don't want to check the additional log files in the
reports directory. Usually tools do that in order to present pretty reports.
That is a secondary issue though. During development, especially on my local
machine, I just want to check Maven's console output.
> 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: 2.22.2, 3.0.0-M3
>
> Attachments: surefire-stream-corruption-bug.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
