I've tried to search on Spring documentation + articles on the internet + questions from Stackoverflow but I didn't find any information about it. For me the configuration of Log4J2 (especially the pattern) is much simpler, personal taste.
Also, I find that Log4J2 has better performance than Logback according to these articles:
https://stackify.com/compare-java-logging-frameworks
https://blog.overops.com/the-logging-olympics-a-race-between-todays-top-5-logging-frameworks
What is the difference between log4j, slf4j and logback?
https://www.sitepoint.com/which-java-logging-framework-has-the-best-performance/
And if we are to consider Async Logger, the performance is expediently higher in favor of Log4J2 according to Apache - https://logging.apache.org/log4j/2.x/performance.html and yes I know that it's their job to make their framework look better but I do believe that they are reliable.
My assumption is that Pivotal choose Logback to be the default because Log4J2 came sometime after they released version 1.0 of Spring-Boot.
Can anyone shed some light on this? Is my assumption correct?
By default, Spring Boot picks up the native configuration from its default location for the system (such as classpath:logback. xml for Logback), but you can set the location of the config file by using the "logging. config" property.
The default logging configuration in Spring Boot is a Logback implementation at the info level for logging the output to console. The first info log is printed, followed by a seven-line banner of Spring and then the next info log. The debug statement is suppressed.
Spring Boot uses Apache Commons logging for all internal logging. Spring Boot's default configurations provides a support for the use of Java Util Logging, Log4j2, and Logback.
Spring Boot supports Log4j 2 for logging configuration if it is on the classpath. If you are using the starters for assembling dependencies that means you have to exclude Logback and then include log4j 2 instead. If you aren't using the starters then you need to provide jcl-over-slf4j (at least) in addition to Log4j 2.
Logback is the default log framework used in a spring boot. Logback has native support of the slf4j. Logback also contains the defined configuration of the conditional processing. It contains the capabilities of advanced filtering. It will also support the maximum archived files.
Default Logback Logging When using starters, Logback is used for logging by default. Spring Boot preconfigures it with patterns and ANSI colors to make the standard output more readable. Let's now run the application and visit the http://localhost:8080/ page, and see what happens in the console:
By default, Spring Boot redirects all logs sent from Apache Commons Logging (JCL), Log4J and Java Util Logging (JUL) APIs to SLF4J. Logback is used as SLF4J implementation. If not already familiar then check out quick SLF4J features here. Logback natively implements SLF4J API. Spring internal code uses JCL, that will also end up in Logback logs.
Logback Introduction: An Enterprise Logging Framework. Monitoring, diagnosing, and troubleshooting are key activities in any enterprise application lifecycle, and logging is the core part of these activities. Through logging you get to see what the application code is actually doing during these activities at runtime.
This is the reason:
Phil Webb: I don't really feel like the arguments being made justify the introduction of a breaking change. [...] 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. [...] I think it's unlikely that we'll consider switching the default logging system until the next major release of Spring Boot.
Ralph Goers: support for configuring Log4j 2 from Spring Cloud Config is planned to be added.
Source
Log4j 2.12.0 added support for utilizing Spring Cloud Config to host the Log4j configuration with dynamic reconfiguration and added support for Docker. With the release of Log4j 2.13.0 Log4j has further integrated with Spring by providing a Spring Lookup so the Log4j configuration can access spring properties. In addition, some Log4j system properties can also be read from Spring's bootstrap.yml or application.yml files. 2.13.0 also provides a Kubernetes Lookup to allow Kubernetes attributes to be specified in the Log4j configuration as properties to include in the log events.
See Logging in the Cloud and Log4j Spring Cloud Config Client.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With