Introduction

In Spring Boot, logging usually goes through SLF4J with Logback by default. Lombok helps by generating the logger field for you, which removes repetitive boilerplate but does not change the logging architecture itself. The practical value is small but real: cleaner classes, consistent logger naming, and fewer hand-written logger declarations.

Use Lombok’s @Slf4j

The most common Lombok logging annotation for Spring Boot is @Slf4j.

1import lombok.extern.slf4j.Slf4j;
2import org.springframework.stereotype.Service;
3
4@Slf4j
5@Service
6public class PaymentService {
7
8    public void process(long orderId) {
9        log.info("Processing order {}", orderId);
10    }
11}

Lombok generates a static logger field behind the scenes, so you do not have to write:

private static final Logger log = LoggerFactory.getLogger(PaymentService.class);

The generated logger still uses the same underlying Spring Boot logging setup.

Configure Log Levels in Spring Boot

Lombok only generates the logger field. Log level control still belongs in Spring Boot configuration.

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

This lets you increase verbosity for specific packages without changing application code.

That separation is important:

• Lombok reduces source-code boilerplate
• Spring Boot manages runtime logging behavior

Prefer Parameterized Logging

When using the generated log field, prefer placeholder-based logging rather than string concatenation.

log.info("User {} placed order {}", userId, orderId);

This is better than:

log.info("User " + userId + " placed order " + orderId);

Parameterized logging is more efficient because the logging framework can skip string formatting work when the level is disabled.

Log Exceptions Explicitly

For failures, include the exception object so the stack trace is preserved.

1try {
2    paymentGateway.charge(orderId);
3} catch (RuntimeException ex) {
4    log.error("Payment failed for order {}", orderId, ex);
5    throw ex;
6}

This is much more useful than logging only ex.getMessage(), because the trace shows where the problem actually came from.

Lombok Supports Other Logging APIs Too

If the project uses a different logging abstraction, Lombok has other annotations such as @Log4j2 and @Log. For a standard Spring Boot application, @Slf4j is usually the right default because it fits the framework’s logging conventions naturally.

That said, the annotation should match the project’s actual logging stack. Lombok is a convenience layer, not a reason to change logging APIs unnecessarily.

Keep Log Messages Operationally Useful

The presence of Lombok can make logging so easy that teams start logging everything. That is rarely helpful. Good Spring Boot logs should still be intentional:

• 'INFO for meaningful lifecycle and business events'
• 'WARN for unusual but recoverable situations'
• 'ERROR for real failures'
• 'DEBUG and TRACE for diagnostic detail'

The goal is not more logs. The goal is better signal.

Use Context, Not Noise

A useful log message usually includes identifiers that help trace one request or business action, such as an order ID, user ID, or job ID. A useless log message often just repeats what the method name already says.

For example, log.info("Processing order {}", orderId) is much more valuable than log.info("Entered process method").

Lombok makes logging easy, but it does not decide what is worth logging.

Common Pitfalls

• Thinking Lombok changes the logging framework itself when it only generates the logger field.
• Using string concatenation instead of parameterized logging.
• Logging exception messages without the exception object and losing the stack trace.
• Adding logs everywhere just because @Slf4j makes it convenient.
• Forgetting that log levels are configured in Spring Boot properties, not in Lombok.

Summary

• In Spring Boot, Lombok’s @Slf4j is a convenient way to generate a logger field.
• It reduces boilerplate but still uses the normal Spring Boot logging setup.
• Configure log levels through Spring Boot properties.
• Prefer parameterized log messages and include exception objects when logging failures.
• Lombok makes logging easier to write, but message quality and log volume still need discipline.