Spring Boot 4.1.0 RC1: OpenTelemetry Protocol and Improved Transaction Management
Spring Boot 4.1.0 RC1 marks the first release candidate in the 4.1 line, targeting a GA release within the next few weeks. The headline additions are support for the OpenTelemetry Protocol (OTLP) SDK exporter environment variables—meaning Spring Boot applications can now pick up OTEL configuration from the environment with no code changes—and first-class support for Spring Framework's LazyConnectionDataSourceProxy through auto-configuration and configuration properties.
The LazyConnectionDataSourceProxy improvement is practically significant for applications with many short-lived transactions that don't actually require a JDBC connection on every call. Spring Boot now detects and configures the proxy automatically, deferring physical connection acquisition until a statement is actually executed. For teams using PgBouncer, HikariCP in transaction mode, or any other pooled datasource, this can measurably reduce pool pressure under read-heavy workloads.
The release also delivers the usual batch of dependency upgrades, documentation improvements, and bug fixes. Teams currently on the milestone releases can upgrade to RC1 and expect a stable API surface; no further breaking changes are planned before GA.
Read more — InfoQ
Spring Security 7.1.0 RC1: anyOf() Composition and Preflight Request Filter
Spring Security 7.1.0 RC1 introduces the anyOf() combinator method on AuthorizationManager, making it straightforward to express OR-semantics across multiple authorization rules without chaining custom code. Where previously developers had to implement composite AuthorizationManager instances or fall back to expression-based rules, anyOf() provides a clean, type-safe API that composes existing managers declaratively.
A new PreFlightRequestFilter lands in this release to standardise handling of browser-issued CORS preflight requests. Prior implementations relied on the main security filter chain evaluating OPTIONS requests, which could trigger authentication checks unintentionally on preflight probes from browser clients. The dedicated filter short-circuits this path, reducing both the risk of misconfiguration and the overhead of evaluating security rules for unauthenticated OPTIONS requests.
Read more — InfoQ
Spring Integration 7.1.0 RC1: Redis 8.4 Compare-and-Set in RedisLockRegistry
Spring Integration 7.1.0 RC1 refactors RedisLockRegistry to leverage the Compare-and-Set (CAS) operations introduced in Redis 8.4. The previous implementation relied on Lua scripts to achieve atomic lock acquisition, which carries overhead on Redis Cluster deployments and increases complexity when tracing lock contention. The new CAS-based path removes the Lua dependency and uses Redis native commands that are eligible for cluster-slot routing without scripting overhead.
For teams running distributed Spring Integration flows that rely on RedisLockRegistry for idempotency or leader election, upgrading to this release (once GA) will reduce lock acquisition latency and simplify Redis ACL configurations that previously needed SCRIPTING permissions.
Read more — InfoQ
Spring Modulith 2.1.0 RC1: @ModuleSlicing for Integration Test Isolation
Spring Modulith 2.1.0 RC1 delivers the @ModuleSlicing annotation, which addresses a persistent developer experience issue where integration tests for one module would inadvertently load Spring beans from unrelated modules, causing test failures due to missing infrastructure—databases, message brokers, or external services—that only those unrelated modules require.
With @ModuleSlicing, developers annotate their test classes to explicitly declare which module slice should be bootstrapped for that test. Spring Modulith uses the module model already present in the application to compute the minimal set of beans required, excluding everything outside the declared slice boundary. The result is faster test startup times and more reliable isolated tests that do not break when a distant module adds a new infrastructure dependency.
This is particularly useful for large applications where the full application context takes many seconds to start. Teams already using Spring Modulith's architectural verification features will find @ModuleSlicing a natural complement to the module boundary tests they already run.
Read more — InfoQ
Links & Sources
You May Also Enjoy
