Spring Boot 4.2.0-M2: OpenTelemetry Semantic Conventions and SSL Bundles for LDAP

Spring Boot 4.2.0-M2 landed on September 25, 2026, the second milestone on the way to the 4.2 release. It packs 141 enhancements, documentation improvements, dependency upgrades and bug fixes, but two features stand out for teams running Spring Boot in production: a switch for OpenTelemetry semantic conventions in observability data, and SSL bundle support for LDAP. Here's what they mean and how to try them today.

Trying the Milestone

Milestones are published to Maven Central, so you only need to bump the version in a throwaway branch:

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>4.2.0-M2</version>
</parent>

./mvnw -q verify

Treat it as a preview. APIs and property names can still change before the GA release, so keep production on the current 4.x line and use milestones for early feedback.

OpenTelemetry Semantic Conventions

Spring Boot instruments your app through Micrometer Observation: one Observation produces both metrics and traces. Historically, the names and tags of that data followed Micrometer's own conventions. That works well in Prometheus and Grafana dashboards built for Spring, but it can clash with OpenTelemetry-native backends, which expect attribute names defined by the OpenTelemetry semantic conventions (for example http.request.method rather than Micrometer-style tags).

4.2.0-M2 adds a property to choose between the two:

# application.properties
management.observations.conventions=opentelemetry

The accepted values are micrometer and opentelemetry. This matters when:

You send telemetry to a vendor or collector that builds views on OpenTelemetry attribute names.
You run a polyglot system where Node.js, Go or Python services already emit OpenTelemetry conventions, and you want Java services to line up in the same dashboards.
You're migrating away from the OpenTelemetry Java agent towards Spring Boot's built-in support and want similar data shapes.

Before switching an existing service, check your dashboards and alerts. Metric and tag names will change, so queries written against the old names will stop matching.

Your Custom Observations Still Work

The property changes how built-in instrumentation names its data, not how you write code. Custom observations created through the ObservationRegistry look exactly the same:

@Service
public class CheckoutService {

    private final ObservationRegistry registry;

    public CheckoutService(ObservationRegistry registry) {
        this.registry = registry;
    }

    public void checkout(Order order) {
        Observation.createNotStarted("checkout", registry)
            .lowCardinalityKeyValue("payment.method", order.paymentMethod())
            .highCardinalityKeyValue("order.id", order.id())
            .observe(() -> process(order));
    }
}

Remember the rule: low cardinality key-values appear on both metrics and traces, high cardinality ones only on traces.

Common OTLP Configuration

M2 also introduces common OTLP endpoint, header and compression configuration, so you no longer need to repeat the same collector settings for each signal. In 4.x today, traces, metrics and logs are configured separately:

management.opentelemetry.tracing.export.otlp.endpoint=http://collector:4318/v1/traces
management.otlp.metrics.export.url=http://collector:4318/v1/metrics
management.opentelemetry.logging.export.otlp.endpoint=http://collector:4318/v1/logs

The exact property names for the shared settings are listed in the 4.2.0-M2 release notes. If you prefer environment variables, Spring Boot already maps the standard OpenTelemetry ones, with signal-specific variables taking precedence over general ones:

export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4318
export OTEL_EXPORTER_OTLP_HEADERS="authorization=Bearer ${OTLP_TOKEN}"
export OTEL_EXPORTER_OTLP_COMPRESSION=gzip

To get started with OpenTelemetry export at all, add the spring-boot-starter-opentelemetry dependency (listed as "OpenTelemetry" on start.spring.io).

SSL Bundles for LDAP

SSL bundles, introduced back in Spring Boot 3.1, let you define certificates and trust material once and reference them by name from different clients. Until now, LDAP was a gap: securing LdapContextSource connections usually meant JVM-wide truststore flags or a custom SocketFactory.

4.2.0-M2 auto-configures named SSL bundles for Spring LDAP's LdapContextSource, and adds LDAPS support for the embedded LDAP server used in tests and local development. You define the bundle the usual way:

spring:
  ssl:
    bundle:
      pem:
        corp-ldap:
          truststore:
            certificate: "classpath:certs/corp-ldap-ca.crt"
  ldap:
    urls: "ldaps://ldap.example.com:636"
    base: "dc=example,dc=com"

You then point the LDAP configuration at the corp-ldap bundle; see the release notes for the property. The benefits are concrete:

No more -Djavax.net.ssl.trustStore flags that affect every TLS connection in the JVM.
Certificate rotation works the same way as for your web server, Kafka or Redis clients.
Integration tests can use LDAPS against the embedded server instead of plain LDAP.

Other Milestone 2 Releases

Spring Boot 4.2.0-M2 arrived alongside second milestones across the portfolio, including Spring Framework 7.1.0-M2 and Spring Security 7.2.0-M2. If you're testing the Boot milestone, those come along through dependency management.

Key Takeaways

Spring Boot 4.2.0-M2 was released on September 25, 2026, with 141 changes.
management.observations.conventions switches between micrometer and opentelemetry semantic conventions.
Switching conventions renames metrics and tags, so update dashboards and alerts first.
Common OTLP endpoint, header and compression settings reduce per-signal duplication.
LDAP clients can now use named SSL bundles, and the embedded LDAP server supports LDAPS.
Use milestones in a branch for feedback, not in production.