Spring Boot 4.2.0 M2 Release Notes

Spring Boot 4.2.0-M2 Release Notes

For changes in earlier milestones, please refer to:

v4.2.0-M1

Upgrading from Spring Boot 4.1

Embedded LDAP Server Requires an SSL Bundle

Setting spring.ldap.embedded.ssl.enabled to true without also setting spring.ldap.embedded.ssl.bundle used to start a plain LDAP listener, without an error or a log message. An SSL bundle is now required when SSL is enabled.

New and Noteworthy

Tip	Check the configuration changelog for a complete overview of the changes in configuration.

LDAP support

SSL Bundle Support for LDAP

The auto-configured LdapContextSource can now connect over LDAPS using an SSL bundle. Configure the bundle to use with the spring.ldap.ssl.bundle property and an ldaps:// URL in spring.ldap.urls, which is also switched to default to ldaps://localhost:636 once a bundle is configured. If you only need the platform’s default trust and key material rather than a bundle, set spring.ldap.ssl.enabled to true instead.

Reloaded bundle key and trust material is picked up by subsequent connections automatically.

LDAPS Support for the Embedded LDAP Server

The auto-configured LDAP client can now connect to the embedded LDAP server over LDAPS. Naming an SSL bundle with spring.ldap.embedded.ssl.bundle now configures both ends, so an auto-configured LdapTemplate or LdapContextSource can talk to the server without any client-side configuration:

spring:
  ldap:
    base: "dc=spring,dc=io"
    embedded:
      base-dn: "dc=spring,dc=io"
      ssl:
        bundle: "example"

Whether the connection uses TLS at all is decided by the server, as it accepts nothing else, so spring.ldap.ssl is ignored. To give the client its own SSL configuration, define your own LdapConnectionDetails bean.

Embedded LDAP Configures the Client That Connects to It

Everything that describes a connection to the embedded server is now taken from the spring.ldap.embedded properties, as only the server can determine what a connection to it looks like. While an embedded server is used, these spring.ldap properties are ignored:

spring.ldap.urls, in favour of the port and scheme the server is listening on
spring.ldap.username and spring.ldap.password, in favour of spring.ldap.embedded.credential.username and spring.ldap.embedded.credential.password, as those are the only credentials the in-memory server accepts
spring.ldap.ssl.enabled and spring.ldap.ssl.bundle, in favour of spring.ldap.embedded.ssl.bundle

Of these, spring.ldap.urls and spring.ldap.ssl.enabled used to take effect. A spring.ldap configuration meant for a production server therefore no longer has to be unset for a test to run against the embedded server. To configure the client differently, define your own LdapConnectionDetails bean.

Because spring.ldap.base-environment.* now applies while the embedded server is used, a java.naming.ldap.factory.socket entry set there would be replaced by the socket factory of the SSL bundle. The application fails to start instead of using either silently. Use an SSL bundle or your own socket factory, not both.

See the reference documentation for more details.

Requiring Authentication with Embedded LDAP

To configure the operation types that require authentication, set spring.ldap.embedded.authentication-required-operation-types to one or more of the values enumerated in com.unboundid.ldap.sdk.OperationType.

Observability improvements

Common OTLP Configuration Fallback

The OTLP endpoint, headers, and compression can now be configured once under management.opentelemetry.otlp and shared across the tracing, logging, and metrics exporters. Each signal-specific property still takes precedence when set, and falls back to the common value otherwise:

management.opentelemetry.otlp.endpoint - used when a signal has no endpoint of its own configured, with the OTLP signal path (/v1/traces, /v1/logs, /v1/metrics) appended automatically for HTTP transport.
management.opentelemetry.otlp.headers - merged with any signal-specific headers, which take precedence on conflicting keys.
management.opentelemetry.otlp.compression - used when a signal has no compression of its own configured.

Configurable Tracing MDC Keys

The MDC keys under which Micrometer Tracing puts the trace and span IDs can now be customized:

management.tracing.mdc.trace-id-key - key for the trace ID, traceId by default.
management.tracing.mdc.span-id-key - key for the span ID, spanId by default.

Both keys are applied to OpenTelemetry and Brave, and the default correlation ID in the log output follows them automatically, so log correlation keeps working without any further configuration.