Logging in Spring Boot uses Apache Commons Logging for all internal logging but leaves the underlying log implementation open. The Commons Logging (JCL) provides a Log interface that is intended to be both light-weight and an independent abstraction of other logging toolkits.

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

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

Log Format

The default log output from Spring Boot resembles the following example:

2019-09-15 17:59:56.002  INFO 13108 --- [   main] c.talksinfo.SpringPropertiesApplication  : Starting SpringApplication on PID 13108
2019-09-15 17:59:56.004  INFO 13108 --- [   main] c.talksinfo.SpringPropertiesApplication  : The following profiles are active: test
2019-09-15 17:59:56.597  INFO 13108 --- [   main] c.talksinfo.SpringPropertiesApplication  : Started SpringApplication in 0.951 seconds

The following items are output:

  • Date and Time: Millisecond precision and easily sortable.
  • Process ID.
  • --- separator to distinguish the start of actual log messages.
  • Thread name: Enclosed in square brackets (may be truncated for console output).
  • Logger name: This is usually the source class name (often abbreviated).
  • The log message.

Message Priorities/Levels in Spring Boot

It is important to ensure that log message are appropriate in content and severity. The following guidelines are suggested:

  • error – Severe errors that cause premature termination. Expect these to be immediately visible on a status console. Also runtime errors or unexpected conditions. Expect these to be immediately visible on a status console.
  • warn – Use of deprecated APIs, poor use of API, ‘almost’ errors, other runtime situations that are undesirable or unexpected, but not necessarily “wrong”. Expect these to be immediately visible on a status console.
  • info – Interesting runtime events (startup/shutdown). Expect these to be immediately visible on a console, so be conservative and keep to a minimum.
  • debug – detailed information on the flow through the system. Expect these to be written to logs only.
  • trace – more detailed information. Expect these to be written to logs only.

Logback does not have a FATAL level. It is mapped to ERROR.

Default Message Priority/Level

The default log configuration echoes messages to the console as they are written. By default, ERROR-level, WARN-level, and INFO-level messages are logged. You can also enable a “debug” mode by starting your application with a --debug flag.

You can also specify debug=true in your application.properties.

When the debug mode is enabled, a selection of core loggers (embedded container, Hibernate, and Spring Boot) are configured to output more information. Enabling the debug mode does not configure your application to log all messages with DEBUG level.

Alternatively, you can enable a “trace” mode by starting your application with a --trace flag (or trace=true in your application.properties). Doing so enables trace logging for a selection of core loggers (embedded container, Hibernate schema generation, and the whole Spring portfolio).

Example of declaring Log Level in application.properties


Example of declaring Log Level in application.yaml

    root: INFO

Setting log  level to trace will show trace log something like below in console,

Above image shows truncated lines of logs as it is just an example. Original record has still more number of lines.

Custom Logging Properties

Other properties available for customization of logging are below ones,

Grouping Packages for Setting Log Levels

Packages can be grouped together so that logging can all be configured at the same time.

For example, you can change the logging levels for all Tomcat related loggers at one place. To help with this, Spring Boot allows you to define logging groups in your Spring Environment. For example, here’s how you could define a “tomcat” group by adding it to your application.properties:

logging.group.tomcat=org.apache.catalina, org.apache.coyote, org.apache.tomcat

Once defined, you can change the level for all the loggers in the group with a single line:


Spring Boot includes the following pre-defined logging groups that can be used out-of-the-box:

Custom Logging using 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.


In this article, we had a quick look at how spring-jcl is included in starters, log format, different log levels, setting log levels, grouping package for log levels and available custom logging properties.