Spring Boot 3.4 Core Changes: From Structured Logging to Virtual Threads
When deploying server applications to production, log collection and container environment configuration often require significant effort. Spring Boot 3.4 now supports generating JSON-based structured logs using only default configuration files without adding external libraries, and it has refined the methods for testing and validating configuration properties. Here are the key practical points for developers considering a new project or a version upgrade.
Structured Logging with a Single Line of Configuration
In cloud or Kubernetes environments, JSON-formatted logs that are easier to search and parse are preferred over plain text logs. Previously, this required adding separate dependencies like Logstash Logback encoder to build files and going through complex XML configurations. Starting with Spring Boot 3.4, structured logging is officially supported as a built-in feature.
You can specify ECS (Elastic Common Schema), Logstash, or GELF formats directly in your configuration files. It is also possible to define different formats for console output and file storage.
The following is an example of an application.properties configuration in a Spring Boot 3.4 environment.
The biggest advantage is being able to standardize log pipeline integration specifications without having to manage separate library dependencies.
MockMvcTester: Seamless Integration with AssertJ
When verifying web layer controllers, MockMvc previously required learning jsonPath syntax and ResultMatcher chaining. Spring Boot 3.4 introduces MockMvcTester, which allows you to verify API responses using the familiar AssertJ assertion style.
By injecting a MockMvc instance into your test code and wrapping it with MockMvcTester or using a dedicated builder, you can use autocomplete to verify HTTP status codes, headers, and response bodies in readable sentence form. This helps reduce syntax errors when verifying nested JSON structures or list data.
Automatic Test Database Detection and Stricter Property Validation
There are both useful improvements and points to watch out for regarding test environments and configuration property behavior.
The hassles often experienced when using Testcontainers in integration tests have been reduced. Previously, you had to declare separate properties in annotations to prevent the default fallback to an in-memory DB like H2. Spring Boot 3.4's AutoConfigureTestDatabase automatically detects container-based datasources, eliminating the need for unnecessary configuration code.
There are also changes to be aware of during upgrades. When using ConfigurationProperties, validation for nested object fields has become stricter in line with standard Bean Validation specifications. To ensure validation constraints within sub-objects work correctly, you must now annotate nested fields with @Valid to propagate validation downwards. If you have existing validation code that was previously omitted, you should check it before upgrading.
Maru's Practical Application Guide
The scope of Virtual Thread support in Java 21 has expanded, and the default container builder has been updated to the lighter Jammy Tiny base, which also reduces the size of deployment images.
If you are starting a new project, I recommend making Spring Boot 3.4 your default choice without hesitation. When upgrading an existing project to 3.4, you can ensure a safe transition by first checking for missing nested validations in configuration classes and reviewing log collection settings in your deployment pipeline.
