Summary of "Spring Boot 3 | Session 87 | Logging | Logs | Loggers | Log Levels | SLF4J in Spring Boot"

What logging is and why it matters

Logging is the recording of events, messages, errors and execution flow produced by an application (typically including timestamp, class, message and level). Common uses:

Trace incoming requests across layers (controller → service → repository → DB).
Capture exceptions and debug defects.
Monitor runtime behavior and performance (timings).
Provide evidence for production incident investigations and support operational teams.

Real-world benefit: you can search historical logs (by date/time, user id, email) to verify if/when a request occurred and diagnose failures.

Why not use System.out.println

System.out prints plain messages only; it lacks level, timestamp, class context and production features (rotation, archival, filtering).
In real applications you should not use System.out — use a logging framework instead.

Logging frameworks and Spring Boot defaults

Common Java logging frameworks: SLF4J (Simple Logging Facade for Java), Log4j, Logback.
Spring Boot provides logging support out-of-the-box (typically SLF4J + Logback). No manual dependency/config required for basic logging.
Many framework/internal components (Tomcat, Spring) already emit logger messages (startup, port, active profile, etc.).

How to add logs in your code (recommended practice)

Create a logger instance per class:
- Example:
  - private static final Logger log = LoggerFactory.getLogger(MyClass.class);
- Use the class you are in (passing the wrong class will record the wrong origin).
Replace System.out prints with log.* calls so all methods in the class can use the same logger.
Use overloaded log methods to include formatted messages and exceptions:
- log.info("msg {}", arg);
- log.error("msg", ex);

Logger levels and behavior

Typical levels: TRACE, DEBUG, INFO, WARN, ERROR.
Spring Boot default level is INFO: INFO, WARN and ERROR messages are printed by default; DEBUG and TRACE are suppressed unless enabled.
Level hierarchy: enabling a given level prints that level and all higher-priority ones. For example:
- Setting DEBUG prints DEBUG, INFO, WARN, ERROR.
- Setting TRACE prints all levels.
Common guidance:
- INFO: normal/important runtime information (default).
- DEBUG: detailed troubleshooting information (enable when investigating).
- TRACE: very fine-grained, rarely used.
- WARN / ERROR: problems or exceptional conditions.

Enabling DEBUG/TRACE example (application.properties):

logging.level.com.your.package=DEBUG
Avoid setting the root logger unless you know the consequences: logging.level.root=DEBUG.

Log output and operational features

A typical log line contains timestamp (including milliseconds), log level, application name/context, originating class/package and message.

Example: 2026-03-22 12:34:56.789 INFO my-app com.example.MyService - Operation completed

Operational features:

Logs are written to files and rotated/archived when they reach size or time limits (e.g., file1.log → archived → file2.log). Archived logs are used for post-incident analysis.
Logs help monitor which APIs succeed/fail, identify error hotspots, and measure performance (capture start/end timestamps to compute durations).

Best practices & tips

Always use a logging framework, not System.out, in real applications.
Create a logger per class with the correct class reference.
Use appropriate log levels — don’t log everything at DEBUG in production.
Log exceptions via logger methods that accept a Throwable to capture stack traces.
Use log messages to trace request flow across layers; include identifiers (user id, email) where safe — avoid logging sensitive data (passwords).
When debugging production issues, temporarily enable DEBUG for specific packages rather than globally.

Tutorial / guide checklist (what the video demonstrates)

Replace System.out.println traces with LoggerFactory.getLogger(...) and log.info(...) calls.
Show how Spring Boot prints richer log output (timestamp, class, app name) compared with System.out.
Create logger in controller and service classes and demonstrate that logs show the class origin.
Demonstrate default behavior: INFO/WARN/ERROR visible; DEBUG/TRACE not until enabled.
Show how to enable debug in application.properties and observe verbose internal logs.
Explain production workflows: log file rotation/archiving and how support teams use logs to investigate incidents.

Topics signaled for follow-up

Deeper dive into log level hierarchy and exact semantics.
Proper configuration of package vs root log levels and recommended practices.
Techniques for using logs for performance measurement and advanced monitoring/aggregation.