Federico Mariani created CAMEL-26590:
----------------------------------------
Summary: camel-spring-boot - Upgrade to SB 4.2.0
Key: CAMEL-26590
URL: https://issues.apache.org/jira/browse/CAMEL-26590
Project: Camel
Issue Type: Dependency upgrade
Components: camel-spring-boot
Reporter: Federico Mariani
Fix For: 4.24.0
Spring Boot 4.2.0 is planned for the end of November 2026 (4.2.0-RC2 on
2026-11-05, Spring Framework 7.1.0 GA on 2026-11-19). Besides the version bump,
a few 4.2 changes need follow-up in the starters.
h3. RabbitMQ: {{spring-boot-starter-amqp}} no longer auto-configures RabbitMQ
In 4.2 the RabbitMQ (AMQP 0.9.1) auto-configuration moved from
{{spring-boot-amqp}} to the new {{spring-boot-rabbitmq}} module
({{org.springframework.boot.amqp.autoconfigure.RabbitAutoConfiguration}} ->
{{org.springframework.boot.rabbitmq.autoconfigure.RabbitAutoConfiguration}}).
{{spring-boot-starter-amqp}} now pulls in the generic AMQP 1.0 client instead.
camel-spring-rabbitmq autowires the
{{org.springframework.amqp.rabbit.connection.ConnectionFactory}} that Boot's
{{RabbitAutoConfiguration}} creates. Applications that use
{{spring-boot-starter-amqp}}, as camel-spring-boot-examples/rabbitmq does, no
longer get that bean after the upgrade, so the component has no connection
factory.
* make {{camel-spring-rabbitmq-starter}} depend on
{{org.springframework.boot:spring-boot-rabbitmq}}, so the connection factory is
auto-configured without further dependencies
* migrate camel-spring-boot-examples/rabbitmq from {{spring-boot-starter-amqp}}
to {{spring-boot-starter-rabbitmq}}
* add a note to the upgrade guide
h3. OpenTelemetry: Spring Boot managed SDK
Boot 4.2 adds shared OTLP settings, {{management.opentelemetry.otlp.endpoint}},
{{.headers}} and {{.compression}}, used by traces, logs and metrics when no
signal-specific value is set.
With {{spring-boot-starter-opentelemetry}}, Boot exposes an
{{io.opentelemetry.api.trace.Tracer}} and a {{ContextPropagators}} bean.
{{OpenTelemetryTracer}} (camel-opentelemetry2) looks both up before falling
back to {{GlobalOpenTelemetry}}, so Camel spans already go through Boot's SDK
and the new settings apply. This is neither tested nor documented:
* {{camel-opentelemetry2-starter}} has no tests: add an integration test with
{{spring-boot-starter-opentelemetry}} that checks Camel spans are exported
through Boot's SDK and are children of the Spring MVC server span
(camel-platform-http-starter)
* document the Boot-managed setup in the camel-opentelemetry2-starter and
camel-observability-services docs, which currently describe the Java agent only
* when an {{OpenTelemetry}} bean exists but no {{Tracer}} /
{{ContextPropagators}} bean does (e.g. with
{{io.opentelemetry.instrumentation:opentelemetry-spring-boot-starter}}), let
the starter derive them from the {{OpenTelemetry}} bean, so the manual
configuration described in CAMEL-23343 is no longer needed
h3. OpenTelemetry: semantic conventions alignment
The new {{management.observations.conventions=open-telemetry}} switches Boot's
instrumentation to OpenTelemetry semantic conventions:
* Spring MVC / WebFlux server observations use Spring Framework's
{{OpenTelemetryServerRequestObservationConvention}}
({{http.server.request.duration}}, {{http.request.method}},
{{http.response.status_code}}, {{url.scheme}}, ...)
* JVM and process meters are renamed, e.g. {{jvm.memory.max}} ->
{{jvm.memory.limit}}, {{process.cpu.usage}} -> {{jvm.cpu.recent_utilization}}
On the Camel side:
* camel-telemetry {{TagConstants}} still uses the old attribute names
({{http.method}}, {{http.status_code}}, {{http.url}}, {{db.name}},
{{db.statement}}), so a trace for a platform-http route mixes both styles.
Proposal: opt-in stable semantic convention names in camel-telemetry, enabled
by the starters when {{management.observations.conventions=open-telemetry}} is
set. Opt-in, since renaming attributes breaks existing dashboards
* camel-observability-services-starter's default
{{camel.metrics.log-metrics-on-shutdown-filters}}
({{app.info,camel.exchanges.*,process.cpu.usage,jvm.memory.max,jvm.memory.used}})
no longer matches {{process.cpu.usage}} and {{jvm.memory.max}} with
OpenTelemetry conventions: add {{jvm.cpu.recent_utilization}} and
{{jvm.memory.limit}} to the defaults
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
