[
https://issues.apache.org/jira/browse/SUREFIRE-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17374005#comment-17374005
]
Tibor Digana edited comment on SUREFIRE-1659 at 7/3/21, 12:01 PM:
------------------------------------------------------------------
[~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.
This is the detail from our integration test:
{code:xml}
<profile>
<id>junit-platform-with-jul-to-log4j</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire.version}</version>
<configuration>
<systemPropertyVariables>
<java.util.logging.manager>org.apache.logging.log4j.jul.LogManager</java.util.logging.manager>
</systemPropertyVariables>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.13.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jul</artifactId>
<version>2.13.1</version>
</dependency>
</dependencies>
</profile>
{code}
was (Author: tibor17):
[~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)
