Switch default logger from logback to log4j2

[djkeh]

Hi,

This debate has already been done in #10072, but I'd like to raise this issue once again because:

1. Use log4j2 as the default logging instead of logback #10072 is the latest issue dealing with this, as far as I know.
2. If 1. is correct, the issue is closed about 2 years ago.
3. There are reasonable advantages to use log4j2 as default logger.

Thus, I think it's about right time to talk about this again, and if I may, I'd like to ask you to reconsider log4j2 as default logger in Spring Boot project, as it seems log4j2 has pretty decent reasons to replace logback like:

• log4j2 is officially better version of logback.
• log4j2 performances are better in many aspects compared to logback, especially in multi-threaded environment.
• Log4j 2.11.2 is production-ready.
• log4j2 virtually has every feature that logback provides.
• log4j2 provides easy and almost same experience to slf4j and logback api.
• log4j2 has backward compatibility for log4j and slf4j.
• Many other reports and instructions recommend to use log4j2 instead of logback if possible.

It may not be so critical and urgent, however, I believe I'm not the only one to see this "upgrade" in close future.
I'd like to ask for your opinion.

Thanks.

Reference

Apache Log4j 2 is an upgrade to Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides many of the improvements available in Logback while fixing some inherent problems in Logback’s architecture.

• intro.: https://logging.apache.org/log4j/2.x/
• Official benchmark result from apache.org: https://logging.apache.org/log4j/2.x/performance.html
• and more benchmarks
  • https://dzone.com/articles/tips-for-optimizing-your-site-for-multiple-browser
  • https://www.loggly.com/blog/benchmarking-java-logging-frameworks/

[philwebb]

Thanks for the suggestion, but I don't really feel like the arguments being made justify the introduction of a breaking change. They mostly feel quite subjective.

log4j2 is officially better version of logback.

I'm not sure it's possible to make such a blankey statement.

log4j2 performances are better in many aspects compared to logback, especially in multi-threaded environment.

I don't feel like logging performance (with our default setup) is an issue that people face. If it is, they can swap to Log4J2 very easily. Performance alone doesn't feel like a good reason to change the default.

Log4j 2.11.2 is production-ready.

So is logback

log4j2 virtually has every feature that logback provides.

Logback has every feature that logback provides

log4j2 provides easy and almost same experience to slf4j and logback api.

Logback also implement SLF4J, from a user point of view there's no difference.

log4j2 has backward compatibility for log4j and slf4j.

But Log4J2 is different than Logback, so might break people who upgrade from Spring Boot 2.1 -> 2.2

Many other reports and instructions recommend to use log4j2 instead of logback if possible.

Using Log4J2 when possible is very easy with Spring Boot (as long as you don't have complex logging setups).

---

If we were starting Spring Boot today we may well have chosen Log4J2 over Logback, but I think so far there are no massively compelling reasons to cause our users upgrade pain. We've tried to make it as easy as possible to switch to Log4J2 for those users that want to.

I think it's unlikely that we'll consider switching the default logging system until the next major release of Spring Boot.

[rgoers]

I should add that in Log4j 2 2.12.0 direct support for configuring Log4j 2 from Spring Cloud Config is planned to be added. The code has been completed and merged and is just waiting for the release to be cut. Also, support for Logback has gotten noticeably slow in the last few years. According to https://logback.qos.ch/news.html the last GA release was March 30, 2017.

[Marco-Sulla]

@philwebb Excuse me, but since Spring Boot uses the slf4j facade, how can a change of the internal logger library cause any breakage?

@rgoers: could it also added to Spring Boot Initializer?

[philwebb]

@Marco-Sulla We'd run the risk of breaking developers that are doing anything more advanced that just logging with the SLF4J facade. There are many deeper integrations that people might have made.