SLF4J and Logback help you add messages to your app that tell what is happening. This makes it easier to find problems and understand your app's behavior.
SLF4J and Logback basics in Spring Boot
private static final Logger logger = LoggerFactory.getLogger(YourClass.class); logger.info("This is an info message"); logger.error("This is an error message");
Use LoggerFactory.getLogger() to create a logger for your class.
Use different methods like info(), error(), debug() to log messages with levels.
private static final Logger logger = LoggerFactory.getLogger(MyApp.class); logger.info("App started successfully");
logger.error("Failed to load data: {}", exception.getMessage());logger.debug("User input: {}", userInput);This Spring Boot app uses SLF4J with Logback to log messages when the app starts and if it fails.
package com.example.demo; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class DemoApplication { private static final Logger logger = LoggerFactory.getLogger(DemoApplication.class); public static void main(String[] args) { logger.info("Starting the Spring Boot application"); try { SpringApplication.run(DemoApplication.class, args); logger.info("Application started successfully"); } catch (Exception e) { logger.error("Application failed to start", e); } } }
Logback is the default logging framework used by Spring Boot when you use SLF4J.
You can configure Logback using logback-spring.xml or application.properties to change log levels and outputs.
Use placeholders like {} in log messages to insert variables safely.
SLF4J provides a simple way to write log messages in your code.
Logback is a powerful tool that handles how and where logs are saved or shown.
Using them together helps you understand what your app is doing and find problems faster.
Practice
Solution
Step 1: Understand SLF4J's role
SLF4J acts as a simple facade or interface for various logging frameworks, allowing consistent logging calls.Step 2: Differentiate from log storage
SLF4J itself does not handle storing or formatting logs; that is done by the logging backend like Logback.Final Answer:
To provide a simple and consistent logging interface -> Option AQuick Check:
SLF4J = Simple logging interface [OK]
- Confusing SLF4J with the logging backend
- Thinking SLF4J formats or stores logs
- Assuming SLF4J sends logs remotely
Solution
Step 1: Recall SLF4J logger creation syntax
The standard way is to use LoggerFactory.getLogger with the class name as parameter.Step 2: Check each option
private static final Logger logger = LoggerFactory.getLogger(MyClass.class); matches the correct syntax; others use incorrect methods or constructors.Final Answer:
private static final Logger logger = LoggerFactory.getLogger(MyClass.class); -> Option CQuick Check:
Logger creation = LoggerFactory.getLogger(Class) [OK]
- Trying to instantiate Logger with new keyword
- Using Logger.getLogger() without parameters
- Missing static or final keywords
logger.info("User {} logged in", username);What will be the output if
username is "Alice"?Solution
Step 1: Understand SLF4J placeholder usage
The curly braces {} act as placeholders replaced by the following arguments in order.Step 2: Substitute username value
Since username is "Alice", it replaces the {} placeholder in the message.Final Answer:
User Alice logged in -> Option DQuick Check:
Placeholders {} replaced by arguments [OK]
- Printing the placeholder {} literally
- Printing variable name instead of value
- Appending variable after the message
Logger logger = LoggerFactory.getLogger(MyClass.class);
logger.debug("Debug message");But you never see the debug message in your console logs. What is the most likely reason?
Solution
Step 1: Understand log levels and filtering
Logback filters messages below the configured log level, so DEBUG messages may be hidden if level is INFO or higher.Step 2: Check logger creation and SLF4J support
The logger is created correctly and SLF4J supports debug messages, so those are not the cause.Final Answer:
The log level is set higher than DEBUG in Logback configuration -> Option BQuick Check:
Log level filtering hides DEBUG if set higher [OK]
- Assuming logger creation failed
- Thinking SLF4J lacks debug support
- Believing debug logs always show by default
errors.log and all logs to the console. Which Logback configuration snippet correctly achieves this?Solution
Step 1: Locate the ERROR LevelFilter on FILE appender
The FILE appender usesch.qos.logback.classic.filter.LevelFilterwith<level>ERROR</level>,<onMatch>ACCEPT</onMatch>,<onMismatch>DENY</onMismatch>. This ensures only ERROR logs go toerrors.log.Step 2: Confirm console appender and root logger
The CONSOLE appender has no filter. The<root level="DEBUG">attaches both appenders, so all logs (DEBUG and above) go to console.Final Answer:
The configuration with ERROR LevelFilter on FILE appender -> Option AQuick Check:
File appender filters ERROR, console shows all [OK]
- Not filtering file appender logs by level
- Setting root level too high hiding logs
- Missing console appender or not attaching it
Ready to prove it?
Pass the test and this pattern moves unknown
