A complete guide to testing REST APIs with JUnit 6 using both MockMvc and WebTestClient. Covers GET, POST, PUT, DELETE testing, JSON path assertions, validation error testing, file uploads, authentication, and a matcher quick-reference table.
A complete guide to testing Spring Boot applications with JUnit 6. Covers unit tests with plain JUnit, slice tests (@WebMvcTest, @DataJpaTest, @JsonTest), full integration tests with @SpringBootTest, context caching, Testcontainers, and best practices for each layer.
@RestClientTest and MockRestServiceServer, rebuilt against Spring Boot 4.1.1: a RestClient-based client, a legacy RestTemplate client, a declarative HTTP interface client, and the error path -- plus three real, verified surprises: two packages that moved without warning, Jackson 3 resolving in place of Jackson 2 by default, and a genuine trap where identical mocking code works for RestTemplate and throws a real AssertionError for RestClient.
Imagine your application's log file as a constant stream of information. In a production crisis, this stream becomes a firehose. How do you find the single critical error message in a flood of routine status updates? The answer lies in logging levels. These aren't just labels; they are the fundamental control mechanism in Log4j2. They allow developers to filter noise, pinpoint failures, and monitor application health effectively. Mastering this hierarchy is the key to creating logs that are helpful, not overwhelming. This guide explores Log4j2’s levels, from configuration to real-world best practices. The Logging Threshold: How Levels Work Think of logging levels as a gatekeeper's volume knob. Each log message you write (an "event") is assigned a level of importance, or severity. The logger itself is then configured with a threshold level. When a message arrives, the framework compares its severity to the logger's threshold. Only messages at or above the configured threshold are processed and sent to their destination (like a file or the console). This simple mechanism provides fine-grained control over your application's verbosity. You can run the exact same code in different environments and get drastically different log outputs—all without changing a single line of Java. In development, you might set the threshold low to see everything. In production, you set it high to capture only significant errors.
GraalVM native-image compiles a Spring Boot 4.1 app into a binary that starts in 0.09 seconds instead of 3.5 -- but only after a real ClassNotFoundException, a fix using the tracing agent, and a metadata-collision trap that silently undoes that fix. Rewritten with verified Boot 4.1.1 and current GraalVM versions, honest costs, and where Project Leyden fits as the non-native alternative.
Every developer has those moments where a seemingly simple task turns into a head-scratching puzzle. This error, encountered while trying to configure a custom LocalSessionFactoryBean in Spring Boot, is a perfect example of a subtle type mismatch causing a cryptic failure. The Scenario and the Error The goal was to set up a custom SessionFactory bean using Spring's LocalSessionFactoryBean. The initial, problematic configuration was: @Configuration public class HibernateConfig { @Bean public LocalSessionFactoryBean sessionFactory() { LocalSessionFactoryBean sessionFactory = new LocalSessionFactoryBean(); // … set data source, hibernate properties … // This line caused the error! sessionFactory.setConfigurationClass(org.hibernate.cfg.Configuration.class); return sessionFactory; } } This configuration resulted in the following exception upon application startup: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory': Bean property 'configurationClass' is not writable or has an invalid setter method. Does the parameter type of the setter match the return type of the getter?
If you’ve been working with Spring Framework for a while, especially with its XML-based configuration, you’ve likely encountered a pattern in the <beans> element where schema locations are defined. It often looks something like this: <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd"> <!-- Your bean definitions here --> </beans> Notice the -3.0.xsd at the end of the schema locations? This explicitly ties your configuration to a specific version of the Spring schema. While this might seem harmless or even like a good idea for precision, it can actually lead to unnecessary headaches and maintenance overhead. Why You Shouldn’t Include Version Numbers The Spring Framework is designed with backward compatibility in mind. When a new version of Spring is released (e.g., Spring 3.0, 4.0, 5.0, etc.), the XML schemas are generally updated to include new features or deprecate old ones, but they usually remain compatible with configurations written for previous versions, especially if you’re not using any of the very latest, specific features.
In a Spring MVC application, a ViewResolver is responsible for mapping logical view names that your controllers return to actual .jsp files (or Thymeleaf templates, etc.). When you need to support multiple locales and provide messages or titles that vary per language, a ResourceBundleViewResolver is a convenient choice. This post walks through a minimal, but complete, configuration that you can drop into any Spring MVC project. Problem Statement Suppose you want a home.jsp that displays a greeting, a welcome message, and a page title, all of which should change depending on the user’s locale. You also want to keep the JSPs simple, so you delegate the translation of these messages to a standard Java ResourceBundle (properties file). Solution Overview Define the view resolver so it first looks for a messages_*.properties file. Configure the ViewResolver hierarchy to fall back to the default view resolver if a match isn’t found. Create a simple controller that forwards to a logical view name. Write the JSP that pulls values from the resource bundle.
The original version of this post walked through building a Prometheus and Grafana stack by hand: add micrometer-registry-prometheus, expose /actuator/prometheus, run a Prometheus container with a hand-written scrape config, run a Grafana container, wire up a data source, import a dashboard by ID. None of that stopped working on Spring Boot 4.1 — it's still a completely valid way to run Prometheus and Grafana. What changed is that Boot 4.1 adds a fourth option, built by the Spring team, that skips almost all of it: point one Docker Compose file at a real observability backend and the metrics and traces just start arriving, verified end to end against a real running container, not a diagram.
Email isn't just for newsletters; it's the backbone of modern application workflows. From sending critical account verification links to delivering daily reports, a reliable email system is non-negotiable. Luckily, Spring Boot makes sending emails clean, configurable, and production-ready with its powerful JavaMailSender interface. In this comprehensive guide, we'll walk you through everything you need to know to become an email pro with Spring Boot 3. We'll cover sending plain text and rich HTML emails, handling attachments, and supercharging your system with asynchronous processing for blazing-fast performance. Let's get started. 1. Setting the Stage: Project Setup First things first, we need to tell our Spring Boot project that we intend to use its mail-sending capabilities. We do this by adding a single dependency to our pom.xml file.