You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Tibor Digana (Jira)" <ji...@apache.org> on 2021/07/03 12:00:00 UTC

[jira] [Commented] (SUREFIRE-1659) Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.

    [ https://issues.apache.org/jira/browse/SUREFIRE-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17374005#comment-17374005 ] 

Tibor Digana commented on SUREFIRE-1659:
----------------------------------------

[~srdo]
[~kalgon]
[~EPadronU]
[~rkraneis]
I am still having the problem with Log4J Jul. There is no problem with SLF4J. The source code in Junit5 is still the same.


{code:java}
class LauncherConfigurationParameters implements ConfigurationParameters {

	private static final Logger logger = LoggerFactory.getLogger(LauncherConfigurationParameters.class);
{code}


The integration test reports an error:

{noformat}
Error:  Failures: 
Error:    JUnitPlatformStreamCorruptionIT.warningIsNotEmittedWithJulToLog4j:88 expecting empty, but was:<['[WARNING] Corrupted channel by directly writing to native stream in forked JVM 1. See FAQ web page and the dump file D:\a\maven-surefire\maven-surefire\surefire-its\target\JUnitPlatformStreamCorruptionIT_warningIsNotEmittedWithJulToLog4j\target\surefire-reports\2021-07-03T10-47-26_367-jvmRun1.dumpstream']>
{noformat}


The Ifact that the SLF4J has no problem means that JUL implementation has got a reference to {{System.out}} too fast on class loading and not lazily when the first log message is fired. I guess SLF4J is implemented with totally lazy singleton or something.
That's the reason why our CI failed in https://github.com/apache/maven-surefire/pull/354/commits/1fc1106cea5da44c213fb6d7934c8997b8f3616d
Our assertion statements listened to the old message and the new one. That's why we did not see this problem but the users did it.

> Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
> -----------------------------------------------------------------
>
>                 Key: SUREFIRE-1659
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1659
>             Project: Maven Surefire
>          Issue Type: Bug
>    Affects Versions: 3.0.0-M3
>            Reporter: Stig Rohde Døssing
>            Assignee: Tibor Digana
>            Priority: Major
>             Fix For: 3.0.0-M6
>
>         Attachments: src.zip, surefire-stdout-corrupt.zip
>
>
> I have a project that registers a JUnit 5 TestExecutionListener. The TestExecutionListener contains an SLF4j Logger, using Log4j2 as the underlying library. There is a log4j2.xml on the classpath, logging to console, and Surefire is set up to redirect output.
> Running the tests gives the following result.
> {quote}
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM 1. See FAQ web page and the dump file ...
> {quote}
> I've attached a minimal reproduction.
> Doing either of the following eliminates the error:
> * Not having the log4j2.xml on the classpath
> * Not having the Logger in the TestExecutionListener



--
This message was sent by Atlassian Jira
(v8.3.4#803005)