log4j-iostreams in 3.0.0-beta2 has bug that fails logCaptor

[nagkumar]

package com.shivoham.sys2log.logs.log4j.tests;

import com.shivoham.sys2log.logs.log4j.SOutRedirectLog4J2;
import nl.altindag.log.LogCaptor;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.io.IoBuilder;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

import java.io.OutputStream;
import java.io.PrintStream;
import java.util.List;

import static org.junit.jupiter.api.Assertions.assertTrue;

public final class TestSOutRedirectLog4J2
{
    protected static final LogCaptor logCaptor = LogCaptor.forClass(SOutRedirectLog4J2.class);

    private static final Logger log4jLogger = LogManager.getLogger(SOutRedirectLog4J2.class);

    @BeforeEach
    public void setUp()
    {
	OutputStream lOutputStreamFromLogger = IoBuilder.forLogger(log4jLogger).buildOutputStream();
	System.setOut(new PrintStream(lOutputStreamFromLogger));
	logCaptor.clearLogs();
    }

    @Test
    public void redirect()
    {
	new SOutRedirectLog4J2().doPrint();
	assertTrue(hasPartialMatch(logCaptor.getLogs(), "This message will be logged via Log4j2."),
		   "Should print This message will be logged via Log4j2.");
    }

    private static final boolean hasPartialMatch(final List<String> aStringList, final String aSubString)
    {
	return aStringList.stream().anyMatch(s -> s.trim().contains(aSubString.trim()));
    }
}

package com.shivoham.sys2log.logs.log4j;

public class SOutRedirectLog4J2
{
    public void doPrint()
    {
	System.out.println("This message will be logged via Log4j2.");
    }
}

dependencies {
implementation("org.apache.logging.log4j:log4j-core:3.0.0-beta3")
    implementation("org.apache.logging.log4j:log4j-api:2.25.1")
    implementation("org.apache.logging.log4j:log4j-iostreams:2.25.1")
}

This code fails to show redirected content in logCaptor.getLogs().. however with the same version of logCaptor and 2.25.1 of log4j-iostreams it works

Complete source code is at
https://github.com/nagkumar/java/tree/main/tutorials/testing/junit5/logs/sys2log/sys2log

[ppkarwasz]

Hi @nagkumar,

Thank you for the detailed bug report and for providing a reproducible example — very helpful.

As of log4j-core:3.0.0-beta3, the log4j-iostreams module has been removed from the 3.x release train (see issue #2630). The 3.x line now contains only the logging implementation (log4j-core) and its direct extensions.

Modules like log4j-iostreams, which depend solely on the Log4j API, will continue to be maintained in the 2.x line.

Importantly, this is intentional:

log4j-core:3.x is designed to work with log4j-api:2.x and log4j-iostreams:2.x, because it is an implementation of Log4j API 2.x not 3.x.

So while it may seem like a version mismatch at first glance, your current workaround (using log4j-core:3.0.0-beta3 with log4j-iostreams:2.25.1) is actually the correct and supported approach.

To avoid confusion and ensure compatibility, we recommend using the BOM (log4j-bom) like this:

dependencies {
    implementation platform('org.apache.logging.log4j:log4j-bom:3.0.0-beta3')
    // Log4j API artifacts
    implementation 'org.apache.logging.log4j:log4j-api'
    implementation 'org.apache.logging.log4j:log4j-iostreams'
    // Log4j API implementation
    runtimeOnly 'org.apache.logging.log4j:log4j-core'
}

This will resolve:

• log4j-api and log4j-iostreams to compatible 2.x versions
• log4j-core to 3.0.0-beta3

Since there are no plans for a 3.x release of log4j-iostreams, and the current setup is expected and supported, I’m closing this as “won’t fix.”

[nagkumar]

Thx for the speedy resolution.

Since there are no plans for a 3.x release of log4j-iostreams,

I observed there is a version 3.0.0-beta2.. would that be deprecated for use..?

[ppkarwasz]

Hi @nagkumar,

Since there are no plans for a 3.x release of log4j-iostreams,

I observed there is a version 3.0.0-beta2.. would that be deprecated for use..?

Yes, we did publish log4j-iostreams:3.0.0-beta2. However, it was released before a major architectural shift we made in January 2024, when we decided to rebase Log4j Core 3.x onto the 2.x API (see vote thread) to stress out that Log4j Core 3.x does not bring any breaking changes to Log4j API users.

By the time 3.0.0-beta2 was released, this change hadn’t yet taken effect. Since then, the release strategy for 3.x changed significantly:

• Starting with 3.0.0-beta3, only log4j-core and its extensions are published in the 3.x line.
• Modules like log4j-api and log4j-iostreams remain on the 2.x line — intentionally — and are fully compatible with Core 3.x.

Because these are all beta versions and never intended for production, we haven’t formally deprecated earlier artifacts like beta2. That said, you're absolutely right that we should better document this. We’ll look into clarifying that:

• All artifacts from the 3.x line prior to 3.0.0-beta3 are unsupported.
• Only 3.0.0-beta3 and beyond reflect the intended long-term structure and compatibility model.
• beta2 and earlier should be considered obsolete and discouraged for any use.

Regarding the final 3.0.0 release

We're holding off on a final 3.0.0 release not because of critical blockers, but to ensure it's on par with our latest 2.x line. Two main items are pending:

• Backporting GraalVM support, introduced in Log4j Core 2.25.0
• Finishing the port of various 2.x bug fixes to 3.x (see Synchronization with main backlog #3161)

These aren’t blocking issues per se — but we’re aiming for a solid, production-worthy 3.0.0 release. If users like you are testing and ready to adopt Core 3.x in production, we’re happy to postpone those issues and deliver 3.0.0 earlier.