Repository navigation
fix(deps): align micrometer OTLP registry with Spring Boot 3.5 (#1534) - #1653
Merged
Merged
Conversation
Spring Boot 3.5.14's OtlpMetricsExportAutoConfiguration builds the registry via OtlpMeterRegistry.builder(...), a class that only exists from micrometer-registry-otlp 1.15.0. The registries were pinned to 1.14.6, so enabling management.otlp.metrics.export.enabled=true crashed the server at startup with: NoClassDefFoundError: io/micrometer/registry/otlp/OtlpMeterRegistry$Builder Bump revMicrometerRegistry 1.14.6 -> 1.15.12 (matching revMicrometer) so the Builder is present. The registries were held at 1.14.6 because micrometer-registry-otlp 1.15.x requests opentelemetry-proto 1.5.0-alpha, whose generated code needs protobuf-java 4.x — but protobuf is pinned to 3.x (#964, GraalVM polyglot). Force opentelemetry-proto back to 1.3.2-alpha (protobuf 3.x, GeneratedMessageV3) to keep the 3.x stack: micrometer 1.15's OTLP serializer references only metrics/common/resource proto messages, all present in 1.3.2-alpha; the only delta to 1.5.0-alpha is profiling classes micrometer never touches. Rewrite OtlpMetricsConfigurationTest to drive Spring Boot's actual OtlpMetricsExportAutoConfiguration (with management.otlp.metrics.export .enabled=true) instead of hand-constructing the registry, so it exercises the code path that regressed. The test fails on 1.14.6 with the exact NoClassDefFoundError above and passes on 1.15.12.
v1r3n
approved these changes
Sep 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Enabling OTLP metrics export (
management.otlp.metrics.export.enabled=true) crashes the server at startup withNoClassDefFoundError: OtlpMeterRegistry$Builder. Spring Boot 3.5 builds the registry viaOtlpMeterRegistry.builder(...)(only in micrometer-registry-otlp 1.15.x), but the registries were pinned to 1.14.6.Fix: bump the registries to 1.15.12 (matching micrometer core), and force
opentelemetry-protoback to 1.3.2-alpha so the protobuf-3.x stack stays intact (1.15.x otlp pulls 1.5.0-alpha which wants protobuf 4.x -- blocked by #964/GraalVM). micrometer 1.15 only touches metrics/common/resource proto messages, all present in 1.3.2-alpha (the only delta is profiling classes it never uses).The old regression test hand-built the registry, so it never hit the broken path -- rewrote it to drive Spring Boot's real auto-config. It fails on 1.14.6 (the exact crash above) and passes on 1.15.12.
User impact: first-timers turning on OTLP metrics saw the server die on boot with a cryptic
NoClassDefFoundError. Now it starts and exports metrics as expected.Orkes parity: none needed -- OSS-only dependency-pin fix, no Orkes parallel.
Fixes #1534