Build1 publisher2 min readPublished
Spring Boot 4.2's second milestone adds a switch between Micrometer and OpenTelemetry conventions
Spring Boot 4.2.0-M2 adds management.observations.conventions, a property that switches semantic conventions between Micrometer and OpenTelemetry. Teams moving to 4.2 now have to pick the naming their dashboards and alerts will match.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- InfoQ's roundup for the week of September 21, 2026 also covers second milestones of Spring Framework, Data, Security, Batch and Integration, plus first milestones of Spring AI and Spring Cloud.
- Hibernate ORM 8.0.0.Beta1 gets initial support in Spring Data 2026.1.0-M2 for the coming Jakarta Persistence 4.0, while the Jakarta Persistence 3.2 baseline stays in place.
- Spring AI 2.1.0-M1 adds an OpenAiResponsesChatModel class that talks to OpenAI's /v1/responses endpoint.
- Framework 7.1.0-M2 lists improved null safety in ScheduledAnnotationBeanPostProcessor and stricter MockCookie.parse() validation when the Set-Cookie header is empty.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Observability owners need to decide which convention set the fleet emits before any service moves to 4.2, because that choice determines the names downstream queries and alert rules must match.
- constraint Spring Cloud users cannot evaluate Paddington on their current Boot line; trying the new Cloud release means taking Boot 4.2.0-M2 and its conventions switch along with it.
- exposure Services sitting behind a proxy that the refactored forwarded-header filters treat as untrusted will have requests denied, so proxy trust has to be checked before Paddington carries test traffic.
- capability Teams can run a branch against Hibernate ORM 8 and Jakarta Persistence 4.0 while Spring Data's baseline for the main line stays on Jakarta Persistence 3.2.
The switch is one configuration line. It accepts two values, micrometer and opentelemetry, and moves Boot's semantic conventions from one set to the other [1]:
``` management.observations.conventions=opentelemetry ```
I treat that line as a schema setting for telemetry. Dashboards and alert rules match on names. If the two convention sets name the same HTTP request or the same attribute differently, changing the value renames what the backend receives. Everything keyed on the old name then stops matching.
The roundup does not say which value 4.2 uses by default [1]. In my context, many services reporting to one backend, I would set the property explicitly in every service before the first one moves to 4.2. A pinned value cannot change between milestones, or at general availability, without someone editing a file.
Rolling upgrades are the harder case. During one, some services run 4.2 and some do not. If the upgraded services emit OpenTelemetry names while the rest emit Micrometer names, the backend holds two names for one measurement until the last service moves. Either the queries cover both names, or the collector rewrites one set into the other.
Spring Cloud's first milestone brings its own changes on top of that Boot release. The ForwardedHeadersFilter and XForwardedHeadersFilter classes were refactored to deny requests from an untrusted proxy [4]. A new PropertyPathNotifier interface lets applications be notified over HTTP when a configuration change is detected [5].
Spring Data's milestone also reworks Redis JSON support. A new JsonOperations interface defines subinterfaces for JSON operations. The GenericJackson2JsonRedisSerializer and GenericJacksonJsonRedisSerializer classes can now implement RedisJsonSerializer with raw-value slicing [8]. Code with its own Redis JSON handling is what I would test first in a Data upgrade.
Spring AI 2.1.0-M1 changes how a message is modelled. A new MessagePart interface and its implementations handle the separate parts of a message. According to InfoQ, the goal is "to accurately represent the messages that the current models actually return" [9]. Code that assumes a model reply is one block of text is where I'd expect to spend time on this upgrade.
The smallest Boot addition is also the tidiest. A named SSL Bundle can now be auto-configured onto Spring LDAP's LdapContextSource [2]. InfoQ points to the Boot release notes and a wiki page for the full list [12].
What to watch
- The default value of management.observations.conventions when Spring Boot 4.2.0 reaches general availability, and whether it differs from the milestones.
- Whether later Paddington milestones add configuration for which proxies the refactored forwarded-header filters trust.
- Whether Spring AI's MessagePart model reaches 2.1.0 GA unchanged or moves again in later milestones.