What is the default logging setup in a Spring Boot application, and what role does SLF4J play?
answer
- SLF4J = facade, Logback = engine
- starter-logging transitively included
- bridges: jul/log4j/jcl -> slf4j
- LoggerFactory.getLogger, org.slf4j import
- zero-config console + logging.level.*
basics
~10 sSpring Boot uses Logback as the default logging backend, pulled in via spring-boot-starter-logging. Your code logs through SLF4J, a facade/API, and SLF4J routes those calls to Logback at runtime.
solid answer
~30 sEvery Spring Boot starter transitively includes spring-boot-starter-logging, which brings in Logback plus SLF4J and bridges (jul-to-slf4j, log4j-to-slf4j). SLF4J (Simple Logging Facade for Java) is an abstraction: you code against org.slf4j.Logger via LoggerFactory.getLogger(...), and at runtime SLF4J binds to Logback as the concrete implementation. This decoupling lets you swap the backend (e.g., to Log4j2) without touching application code. Spring Boot also auto-configures a sensible default pattern, colored console output, and log levels you can tune with logging.level.* properties in application.yml. You get working console logging with zero configuration files.
code
java · 16 linesimport org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Service;
@Service
public class GreetingService {
// Facade type from org.slf4j — never the concrete Logback/Log4j2 class
private static final Logger log = LoggerFactory.getLogger(GreetingService.class);
public String greet(String name) {
// Parameterized logging: no string concatenation unless DEBUG is enabled
log.debug("Building greeting for {}", name);
return "Hello, " + name;
}
}go deeper
Know the two words: Logback is default, SLF4J is the facade you code against.
Explain the transitive starter-logging dependency and the bridge jars that unify other APIs.
Discuss why the facade enables backend swapping and the single-binding constraint.
Frame logging abstraction as a dependency-inversion boundary; reason about classpath binding hygiene across a large module graph.
## The pieces **SLF4J (Simple Logging Facade for Java)** is *not* a logging implementation — it is an API/facade. Your application code depends only on `org.slf4j.Logger` and `org.slf4j.LoggerFactory`. Calling `LoggerFactory.getLogger(MyClass.class)` returns an SLF4J `Logger`, and calls like `log.info("...")` are forwarded to whatever backend is on the classpath. **Logback** is the concrete logging engine that actually formats and writes log events (to console, files, etc.). It was written by the same author as SLF4J and implements the SLF4J API *natively* — no adapter is needed, which is why it is the Spring Boot default. ## How Spring Boot wires it `spring-boot-starter` (and every other starter) transitively depends on **`spring-boot-starter-logging`**. That starter brings: - `logback-classic` (the Logback backend, which pulls in `logback-core` and `slf4j-api`), - **bridge libraries** that redirect other logging APIs into SLF4J so the whole app funnels through one backend: `jul-to-slf4j` (java.util.logging), `log4j-to-slf4j` (Log4j 2 API calls), and `jcl-over-slf4j` (Apache Commons Logging — Spring Framework itself uses `spring-jcl`). So even libraries that don't use SLF4J directly end up routed to Logback. ## Zero-config behavior With no config files at all you still get: - Console output with a default pattern (timestamp, level, PID, thread, logger, message), - Colored output on capable terminals, - Default level INFO for application code. You tune levels via properties without any XML: `logging.level.root=WARN`, `logging.level.com.myapp=DEBUG`. File output turns on by setting `logging.file.name` or `logging.file.path`. ## Getting a logger (idiomatic) ```java private static final Logger log = LoggerFactory.getLogger(MyService.class); ``` Use parameterized logging (`log.info("user {} logged in", id)`) so the message string is only built if that level is enabled. ## Gotchas - Don't import `ch.qos.logback.classic.Logger` or a Log4j `Logger` in app code — always import `org.slf4j.Logger`. Importing the concrete class defeats the facade and breaks backend swapping. - Only one SLF4J binding may be on the classpath; multiple bindings cause the classic 'multiple SLF4J providers' warning and non-deterministic backend selection. Spring Boot's starters keep this clean for you.
- Why is it better to write log.debug("user {} logged in", id) than log.debug("user " + id + " logged in")?The parameterized form defers building the final string until SLF4J confirms DEBUG is enabled. With string concatenation the message is always assembled, wasting CPU even when the level is disabled.
- What does spring-boot-starter-logging actually pull in besides Logback?slf4j-api, logback-classic/logback-core, and the bridge jars jul-to-slf4j, log4j-to-slf4j, and jcl-over-slf4j so other logging APIs are routed into SLF4J/Logback.
saying these in an interview costs you the question
- Thinking SLF4J is itself a logging implementation rather than a facade
- Believing you must add a config file to get any logging
- Importing the concrete Logback or Log4j Logger class in application code
- Claiming Log4j2 is the Spring Boot default