Logging in Spring Boot

1. Overview

In this short tutorial, we’re going to explore the main logging options available in Spring Boot.

Deeper information about Logback is available in A Guide To Logback, while Log4j2 is introduced in Intro to Log4j2 – Appenders, Layouts and Filters.

2. Initial Setup

Let’s first create a Spring Boot module — the recommended way to do so is using Spring Initializr, which we cover in our Spring Boot Tutorial.

Now let’s create our only class file, LoggingController:

@RestController
public class LoggingController {

    Logger logger = LoggerFactory.getLogger(LoggingController.class);

    @RequestMapping("/")
    public String index() {
        logger.trace("A TRACE Message");
        logger.debug("A DEBUG Message");
        logger.info("An INFO Message");
        logger.warn("A WARN Message");
        logger.error("An ERROR Message");

        return "Howdy! Check out the Logs to see the output...";
    }
}

Once we’ve loaded the web application, we’ll be able to trigger those logging lines by simply visiting http://localhost:8080/

3. Zero Configuration Logging

Spring Boot is a very helpful framework — it helps us forget about the majority of the configuration settings, most of which it opinionatedly autotunes.

In the case of logging, the only mandatory dependency is Apache Commons Logging.

We need to import it only when using Spring 4.x (Spring Boot 1.x), since in Spring 5 (Spring Boot 2.x) it’s provided by Spring Framework’s spring-jcl module.

We shouldn’t worry about importing spring-jcl at all if we’re using a Spring Boot Starter (which almost always we are). That’s because every starter, like our spring-boot-starter-web, depends on spring-boot-starter-logging, which already pulls in spring-jcl for us.

When using starters, Logback is used for logging by default.

Spring Boot pre-configures 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:

As we can see in the above picture, the default logging level of the Logger is preset to INFO, meaning that TRACE and DEBUG messages are not visible.

In order to activate them without changing the configuration, we can pass the –debug or –trace arguments on the command line:

java -jar target/spring-boot-logging-0.0.1-SNAPSHOT.jar --trace

If we want to change the verbosity permanently, we can do so in the application.properties file as described here:

logging.level.root=WARN
logging.level.com.baeldung=TRACE

4. Logback Configuration Logging

Even though the default configuration is useful (for example to get started in zero time during POCs or quick experiments), it’s most likely not enough for our daily needs.

Let’s see how to include a Logback configuration with a different color and logging pattern, with separate specifications for console and file output, and with a decent rolling policy to avoid generating huge log files.

First of all, we should go toward a solution which allows handling our logging settings alone, instead of polluting application.properties, which is commonly used for many other application settings.

When a file in the classpath has one of the following names, Spring Boot will automatically load it over the default configuration:

• logback-spring.xml
• logback.xml
• logback-spring.groovy
• logback.groovy

Spring recommends using the -spring variant over the plain ones whenever possible, as described here.

Let’s write a simple logback-spring.xml:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

    <property name="LOGS" value="./logs" />

    <appender name="Console"
        class="ch.qos.logback.core.ConsoleAppender">
        <layout class="ch.qos.logback.classic.PatternLayout">
            <Pattern>
                %black(%d{ISO8601}) %highlight(%-5level) [%blue(%t)] %yellow(%C{1.}): %msg%n%throwable
            </Pattern>
        </layout>
    </appender>

    <appender name="RollingFile"
        class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOGS}/spring-boot-logger.log</file>
        <encoder
            class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <Pattern>%d %p %C{1.} [%t] %m%n</Pattern>
        </encoder>

        <rollingPolicy
            class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- rollover daily and when the file reaches 10 MegaBytes -->
            <fileNamePattern>${LOGS}/archived/spring-boot-logger-%d{yyyy-MM-dd}.%i.log
            </fileNamePattern>
            <timeBasedFileNamingAndTriggeringPolicy
                class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                <maxFileSize>10MB</maxFileSize>
            </timeBasedFileNamingAndTriggeringPolicy>
        </rollingPolicy>
    </appender>
    
    <!-- LOG everything at INFO level -->
    <root level="info">
        <appender-ref ref="RollingFile" />
        <appender-ref ref="Console" />
    </root>

    <!-- LOG "com.baeldung*" at TRACE level -->
    <logger name="com.baeldung" level="trace" additivity="false">
        <appender-ref ref="RollingFile" />
        <appender-ref ref="Console" />
    </logger>

</configuration>

And when we run the application, here’s the output:

As we can see, it now logs TRACE and DEBUG messages, and the overall console pattern is both textually and chromatically different than before.

It also now logs on a file in a /logs folder created under the current path and archives it through a rolling policy.

5. Log4j2 Configuration Logging

While Apache Commons Logging is at the core, and Logback is the reference implementation provided, all the routings to the other logging libraries are already included to make it easy switching to them.

In order to use any logging library other than Logback, though, we need to exclude it from our dependencies.

For every starter like this one (it’s the only one in our example, but we could have many of them):

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

we need to turn it into a skinny version, and (only once) add our alternative library, here through a starter itself:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>

At this point, we need to place in the classpath a file named like one of the following:

• log4j2-spring.xml
• log4j2.xml

We’ll print through Log4j2 (over SLF4J) without further modifications.

Let’s write a simple log4j2-spring.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout
                pattern="%style{%d{ISO8601}}{black} %highlight{%-5level }[%style{%t}{bright,blue}] %style{%C{1.}}{bright,yellow}: %msg%n%throwable" />
        </Console>

        <RollingFile name="RollingFile"
            fileName="./logs/spring-boot-logger-log4j2.log"
            filePattern="./logs/$${date:yyyy-MM}/spring-boot-logger-log4j2-%d{-dd-MMMM-yyyy}-%i.log.gz">
            <PatternLayout>
                <pattern>%d %p %C{1.} [%t] %m%n</pattern>
            </PatternLayout>
            <Policies>
                <!-- rollover on startup, daily and when the file reaches 
                    10 MegaBytes -->
                <OnStartupTriggeringPolicy />
                <SizeBasedTriggeringPolicy
                    size="10 MB" />
                <TimeBasedTriggeringPolicy />
            </Policies>
        </RollingFile>
    </Appenders>

    <Loggers>
        <!-- LOG everything at INFO level -->
        <Root level="info">
            <AppenderRef ref="Console" />
            <AppenderRef ref="RollingFile" />
        </Root>

        <!-- LOG "com.baeldung*" at TRACE level -->
        <Logger name="com.baeldung" level="trace"></Logger>
    </Loggers>

</Configuration>

And when we run the application, here’s the output:

As we can see, the output is quite different from the Logback one — a proof that we’re fully using Log4j2 now.

In addition to the XML configuration, Log4j2 allows us to use also a YAML or JSON configuration, as described here.

6. Log4j2 Without SLF4J

We can also use Log4j2 natively, without passing through SLF4J.

In order to do that, we must simply use the native classes:

import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.LogManager;
// [...]
Logger logger = LogManager.getLogger(LoggingController.class);

We don’t need to perform any other modification to the standard Log4j2 Spring Boot configuration.

We can now exploit the brand new features of Log4j2 without being stuck with the old SLF4J interface, but we’re also tied to this implementation, and we’ll need to rewrite our code when deciding to switch to another logging framework.

7. Beware of Java Util Logging

Spring Boot also supports JDK logging, through the logging.properties configuration file.

There are cases when it’s not a good idea to use it, though. From the documentation:

There are known classloading issues with Java Util Logging that cause problems when running from an ‘executable jar’. We recommend that you avoid it when running from an ‘executable jar’ if at all possible.

It’s also a good practice, when using Spring 4, to manually exclude commons-logging in pom.xml, to avoid potential clashes between the logging libraries. Spring 5 instead handles it automatically, hence we don’t need to do anything when using Spring Boot 2.

8. JANSI on Windows

While Unix-based operating systems such as Linux and Mac OS X support ANSI color codes by default, on a Windows console everything will be sadly monochromatic.

Windows can obtain ANSI colors through a library called JANSI.

We should pay attention to the possible classloading drawbacks, though.

We must import and explicitly activate it in the configuration like follows:

Logback:

<configuration debug="true">
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <withJansi>true</withJansi>
        <encoder>
            <pattern>[%thread] %highlight(%-5level) %cyan(%logger{15}) - %msg %n</pattern>
        </encoder>
    </appender>
    <!-- more stuff -->
</configuration>

Log4j2:

ANSI escape sequences are supported natively on many platforms but are not by default on Windows. To enable ANSI support add the Jansi jar to our application and set property log4j.skipJansi to false. This allows Log4j to use Jansi to add ANSI escape codes when writing to the console.

NOTE: Prior to Log4j 2.10, Jansi was enabled by default. The fact that Jansi requires native code means that Jansi can only be loaded by a single class loader. For web applications this means the Jansi jar has to be in the web container’s classpath. To avoid causing problems for web applications, Log4j will no longer automatically try to load Jansi without explicit configuration from Log4j 2.10 onward.

It’s also worth knowing that:

• the layout documentation page contains useful Log4j2 JANSI informations in the highlight{pattern}{style} section
• while JANSI can color the output, Spring Boot’s Banner (native or customized through the banner.txt file) will stay monochromatic

9. Conclusion

We’ve seen the main ways to interface with the major logging frameworks from within a Spring Boot project.

We’ve also explored the main advantages and pitfalls of every solution.

As always, the full source code is available over on Github.