BlockHound completely breaks Log4j2 with Spring Boot 3.4.2

[micopiira]

Expected Behavior

Log4j2 should work with Spring Boot 3.4.2 + BlockHound

Actual Behavior

After upgrading to Spring Boot 3.4.2, we noticed that Log4j2 completely stopped working. After narrowing down on possible causes, it seems that using BlockHound together with Spring Boot 3.4.2 causes this. Spring Boot 3.4.1 works fine with exact same Log4j2 and BlockHound version.

I initially reported this issue to Spring Boot GitHub repo here: spring-projects/spring-boot#43963 but I was instructed to report this issue here since they don't think they can do anything about this in Spring Boot.

I'm quite certain that this commit: spring-projects/spring-boot@b6b9237 is the culprit here. BlockHound StandardOutputIntegration changes the System.out stream, which causes the StatusConsoleListener#setStream call in Log4J2LoggingSystem to call closeNonSystemStream on the PrintStreamDelegate causing logging to console to not work. Not sure if this should be fixed in Spring boot, BlockHound or Log4j2.

Steps to Reproduce

• Use BlockHound with Spring Boot 3.4.2 + Log4j2, minimal reproducer here: https://github.com/micopiira/spring-boot-log4j2-issue

Your Environment

• Reactor version(s) used: -
• Other relevant libraries versions (eg. netty, ...): Spring Boot 3.4.2
• JVM version (java -version): Eclipse Temurin 21.0.4
• OS and version (eg uname -a): Darwin Micos-MacBook-Pro.local 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec 6 19:01:59 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6000 arm64

[violetagg]

@micopiira We will check the issue

[violetagg]

@micopiira I think your analysis are correct. I think the issue is in org.apache.logging.log4j.status.StatusConsoleListener#closeNonSystemStream where it is assumed that the oldStream is the non-system stream whereas in fact the oldStream is the system stream and the current System.out is a delegator. Wdyt?
So basically org.apache.logging.log4j.status.StatusConsoleListener#closeNonSystemStream closes the system stream.

[micopiira]

Yes that is exactly what happens. This issue can be avoided by calling BlockHound.install() before any calls to LogManager.getLogger, for example:

@SpringBootApplication
public class SpringBootLog4j2DemoApplication {
	static {
		BlockHound.install();
	}
	private static final Logger logger = LogManager.getLogger(SpringBootLog4j2DemoApplication.class);

	public static void main(String[] args) {
		SpringApplication.run(SpringBootLog4j2DemoApplication.class, args);
	}

	@Bean
	ApplicationRunner init() {
		return args -> logger.info("Hello World!");
	}
}

But as I said, this worked fine with Spring Boot 3.4.1, so I'm not sure if there is anything to "fix" and who/where this should be fixed?

[violetagg]

IMO this is not BlockHound issue and the real issue is the assumption in org.apache.logging.log4j.status.StatusConsoleListener#closeNonSystemStream