gRPC, tracing, security and testing are now easier to adopt than ever

Spring Boot 4.1

Every microservice team eventually hits the same friction point: you want gRPC for your internal communications because it’s fast, strongly typed and streaming-friendly — but wiring it into Spring Boot required third-party libraries, manual bean definitions and a separate configuration model that lived outside the Spring Boot ecosystem.

With the release of Spring Boot 4.1, that struggle is officially history.

⚡ TL;DR (Quick Recap)

  • Native gRPC Support — server, client, testing, SSL, security and health indicators are all auto-configured.
  • Enhanced Observability: Richer OpenTelemetry auto-configuration and unbroken @Async context propagation.
  • Hardened HTTP Clients: Out-of-the-box SSRF mitigation using the new InetAddressFilter.
  • Jackson properties — spring.jackson.read.* and spring.jackson.write.* apply across all auto-configured mappers.
  • Native Log4j Rotation: Built-in strategies for size, time and cron-based log rotation without complex XML.

Context: Why This Release Matters Now

As architectures grow more distributed, the demands placed on backend developers shift. We need faster inter-service communication to keep latencies low, rock-solid security defaults to protect against emerging threats and local testing environments that don’t silently fail.

Spring Boot 4.1 responds directly to these modern pressures. By formalizing support for gRPC and providing robust observability right into the core, this release transforms previously advanced architectural patterns into accessible, out-of-the-box defaults.

Spring gRPC Support

This is the feature that reorganizes how Spring teams think about service-to-service communication. Spring Boot 4.1 takes ownership of the gRPC starters, moving them from the spring-grpc project into the org.springframework.boot group.

What’s included:

  • spring-boot-starter-grpc-server — Netty-backed gRPC server on port 9090 by default, switchable to Servlet (Tomcat/Jetty) for HTTP/2 hosting.
  • spring-boot-starter-grpc-client — auto-configured stubs via @ImportGrpcClients, with named channel properties under spring.grpc.client.channel.*.
  • spring-boot-grpc-test — @AutoConfigureTestGrpcTransport for in-process test channels that need zero network configuration.
  • Built-in health indicator via io.grpc:grpc-services — bridged into Spring Boot's health model.
  • Auto-configured reflection service — allows grpcurl and other tooling to discover services at runtime.
  • SSL bundle support for both server and client channels.
  • Spring Security integration for both Netty and Servlet modes.

Writing a server service is clean:

@GrpcService
public class MyHelloWorldService extends HelloWorldGrpc.HelloWorldImplBase {
    @Override
    public void sayHello(HelloRequest request, StreamObserver<HelloReply> responseObserver) {
        String message = "Hello '%s'".formatted(request.getName());
        HelloReply reply = HelloReply.newBuilder().setMessage(message).build();
        responseObserver.onNext(reply);
        responseObserver.onCompleted();
    }
}

Any bean implementing BindableService — which all generated gRPC classes do — is automatically registered with the server. No additional wiring is needed.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.NONE)
@AutoConfigureTestGrpcTransport
@ImportGrpcClients(types = HelloWorldGrpc.HelloWorldBlockingStub.class)
class MyGrpcTests {
    @Autowired
    private HelloWorldGrpc.HelloWorldBlockingStub helloStub;
    @Test
    void sayHello() {
        HelloRequest request = HelloRequest.newBuilder().setName("Spring").build();
        HelloReply reply = this.helloStub.sayHello(request);
        assertThat(reply.getMessage()).isEqualTo("Hello 'Spring'");
    }
}

For Maven users, Spring Boot now manages io.github.ascopes:protobuf-maven-plugin and pre-configures it when you use spring-boot-starter-parent.
Gradle users get the com.google.protobuf plugin reacted to by spring-boot-gradle-plugin with protoc and protoc-gen-grpc-java versions managed automatically.

Observability and OpenTelemetry Enhancements

Observability is no longer treated as an afterthought. You can now easily disable the OpenTelemetry SDK entirely via application properties while still retaining useful trace propagators.

More importantly, Context Propagation is now automatically applied to methods running on separate threads via @Async. If you have ever lost a trace ID when firing off a background task, you will appreciate how seamlessly this ties your distributed logs back together.

The observability model in Spring Boot has been maturing steadily, but 4.1 brings the most substantial OpenTelemetry property expansion to date.

New capabilities:

  • SDK toggle — management.opentelemetry.enabled=false replaces the SDK with no-op implementations
  • Sampler configuration — management.opentelemetry.tracing.sampler now configures the OpenTelemetry sampler directly from properties.
  • SpanLimits and LogLimits — auto-configuration under management.opentelemetry.tracing.limits.* and management.opentelemetry.logging.limits.*.
  • SSL bundles for OTLP exporters — SSL bundle support has been added to OTLP logging, metrics and trace exporters.

A representative property set for fine-grained control:

management:
  opentelemetry:
    enabled: true
    tracing:
      sampler: parentbased_always_on
      limits:
        max-number-of-attributes: 128
        max-number-of-events: 128
    logging:
      limits:
        max-number-of-attributes: 64

Teams running the full OTLP stack — metrics, traces and logs — now have a consistent property-based configuration model for the entire pipeline.

SSRF Mitigation for HTTP Clients

Server-Side Request Forgery (SSRF) is one of those vulnerabilities that’s easy to introduce and hard to notice until it’s exploited. Spring Boot 4.1 adds InetAddressFilter as a first-class mitigation mechanism for auto-configured HTTP clients.

The filter lets you restrict which IP ranges outbound HTTP calls are allowed to reach. It targets the scenario where an application accepts a URL from an untrusted input and then makes a request to it — a classic SSRF vector.

Jackson Configuration Properties Expansion

Jackson configuration in Spring Boot has historically been JSON-only from a property perspective. Spring Boot 4.1 changes that with two new property namespaces that apply across all three auto-configured formats.

Jackson properties:

  • spring.jackson.read.* — configures reading features common to JSON, XML (via Jackson XML) and CBOR mappers.
  • spring.jackson.write.* — configures writing features across the same set of mappers.

This matters because teams using Spring Boot’s multi-format support (e.g., a REST API that returns JSON, XML or CBOR based on Accept headers) had to configure each mapper separately with JacksonCustomizer beans. The new properties apply consistently to all three.

Additionally, auto-configured Jackson mappers now receive a HandlerInstantiator that creates handler instances (deserializers, serializers, type id resolvers, etc.) from Spring-managed beans. This means you can inject Spring beans into custom Jackson handlers without manual wiring.

spring:
  jackson:
    read:
      ignore-undefined: false
    write:
      write-bigdecimal-as-plain: false

File Rotation Support for Log4j

Logback has had configurable file rotation in Spring Boot for a while. Log4j users are now caught up. Spring Boot 4.1 adds four Log4j rotation strategies via a new set of properties:

  • size (default) — rotates when the file reaches a configured size threshold.
  • time — rotates on a time interval (hourly, daily, etc.).
  • size-and-time — rotates when either size or time condition is met.
  • cron — rotates on a cron schedule for precise control.
logging:
  log4j2:
    file:
      rotation:
        strategy: size

Worthy Mentions

  • MongoDB Support for Spring Batch. A new spring-boot-batch-data-mongo starter brings auto-configuration for Spring Batch jobs backed by MongoDB instead of a relational database.
  • Docker Compose — Log Output on Startup Failure. When docker compose up or docker compose start fails, Spring Boot now automatically captures and logs the output of docker compose logs. The log level is controlled by spring.docker.compose.start.log-level (default info). Previously, diagnosing a failed Compose startup required running the command manually and inspecting output. Now the relevant container logs appear directly in the Spring Boot application output.
  • Unified Cookie Handling: Cookie handling is now standardized and easily configurable across TestRestTemplate, RestTemplateBuilder and auto-configured HTTP clients.
  • Explicit Encoding for Property Imports: You can finally specify the exact encoding when importing configuration files, which is a lifesaver for localized systems (e.g., spring.config.import=classpath:import.properties[encoding=utf-8]).
  • Embedded LDAP SSL: Auto-configuration for embedded LDAP servers now smoothly supports LDAPS using standard SSL bundles.
  • Spring Cleaning: Apache Derby integration and the LiveReload feature in DevTools have both been officially deprecated in favor of more modern alternatives like H2 and fast application restarts. Dropped legacy tools like layertools - move to tools jar mode, which provides the same features and more.

Final Takeaways

Spring Boot 4.1 is a meaningful step in two directions simultaneously: capability and production-readiness. The gRPC integration removes one of the last major infrastructure choices that required stepping outside the Spring Boot ecosystem. The OpenTelemetry expansion makes the observability configuration model genuinely complete for teams running the full OTLP pipeline.

The smaller features — SSRF mitigation, consistent cookie handling, @Async context propagation — reflect a release cycle focused on the gaps that experienced Spring Boot users actually hit in production.

You can find an example on GitHub.

Originally posted on marconak-matej.medium.com.