[
https://issues.apache.org/jira/browse/CAMEL-26590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Federico Mariani reassigned CAMEL-26590:
----------------------------------------
Assignee: Federico Mariani
> 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
> Assignee: Federico Mariani
> Priority: Major
> 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)
