Spring Boot
Log4j
log4j.properties
Java logging
application configuration

Log4j.properties in Spring boot

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

In modern Spring Boot applications, log4j.properties is usually not the configuration file you want. Spring Boot uses Logback by default, and if you switch to the current Log4j family, the normal target is Log4j 2 with files such as log4j2-spring.xml, log4j2.xml, or log4j2.properties. That distinction matters because a lot of outdated advice still assumes legacy Log4j 1 behavior.

Spring Boot default logging versus Log4j

A fresh Spring Boot application uses spring-boot-starter-logging, which brings in Logback. If you do nothing, that is the logging system Boot will configure.

If you want Log4j 2 instead, remove the default logging starter transitively and add the Log4j 2 starter.

xml
1<dependency>
2    <groupId>org.springframework.boot</groupId>
3    <artifactId>spring-boot-starter-web</artifactId>
4    <exclusions>
5        <exclusion>
6            <groupId>org.springframework.boot</groupId>
7            <artifactId>spring-boot-starter-logging</artifactId>
8        </exclusion>
9    </exclusions>
10</dependency>
11
12<dependency>
13    <groupId>org.springframework.boot</groupId>
14    <artifactId>spring-boot-starter-log4j2</artifactId>
15</dependency>

That puts Log4j 2 in charge of logging initialization.

Why log4j.properties is usually the wrong file now

Historically, Log4j 1 used log4j.properties. That library is old, and it is not the logging setup you should target in a current Spring Boot application.

For Log4j 2, use one of these file names instead:

  • 'log4j2-spring.xml'
  • 'log4j2.xml'
  • 'log4j2.properties'

log4j2-spring.xml is especially useful in Spring Boot because Boot can process some Spring-aware extensions there.

A simple Log4j 2 configuration

Here is a minimal log4j2-spring.xml example:

xml
1<?xml version="1.0" encoding="UTF-8"?>
2<Configuration status="WARN">
3    <Appenders>
4        <Console name="Console" target="SYSTEM_OUT">
5            <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss} %-5level [%t] %c - %msg%n"/>
6        </Console>
7    </Appenders>
8
9    <Loggers>
10        <Root level="INFO">
11            <AppenderRef ref="Console"/>
12        </Root>
13    </Loggers>
14</Configuration>

Put that file in src/main/resources, start the application, and Log4j 2 will drive the output if the correct dependencies are on the classpath.

Migrating from older log4j.properties setups

If you are coming from an older non-Boot application, the main migration task is translating legacy Log4j 1 concepts into Log4j 2 configuration. The ideas are still familiar:

  • Loggers
  • Appenders
  • Layouts
  • Root log level

What changes is the configuration format and the runtime integration. In a modern Boot service, it is usually better to migrate the old file than to keep forcing legacy configuration semantics into a newer logging stack.

When application.properties is enough

Not every project needs a full Log4j configuration file. Spring Boot can control common logging levels from application.properties:

properties
logging.level.root=INFO
logging.level.com.example=DEBUG

This works even with the default logging system and is often enough for small projects. Reach for a dedicated Log4j 2 config file when you need advanced appenders, rolling policies, JSON layouts, or fine-grained logger structure.

Common Pitfalls

The biggest mistake is dropping a legacy log4j.properties file into a modern Spring Boot project and expecting Boot plus Log4j 2 to pick it up automatically.

Another issue is forgetting to remove spring-boot-starter-logging. If both logging systems are present without a deliberate plan, the runtime behavior becomes confusing.

Developers also confuse "Log4j" with "Log4j 2." They are related names, but they are not the same configuration model or file naming convention.

Finally, do not overconfigure logging if simple logging.level.* properties already solve the problem. A full logging file is useful, but it is not mandatory for every service.

If an existing application truly still depends on old log4j.properties, treat that as legacy maintenance work, not the default pattern for a fresh Spring Boot service.

Summary

  • Spring Boot uses Logback by default, not Log4j.
  • For current Spring Boot projects, prefer Log4j 2 rather than legacy Log4j 1.
  • Use spring-boot-starter-log4j2 when switching logging implementations.
  • Prefer log4j2-spring.xml, log4j2.xml, or log4j2.properties over log4j.properties.
  • Use application.properties logging keys when you only need basic log-level control.

Course illustration
Course illustration

All Rights Reserved.