[
https://issues.apache.org/jira/browse/CAMEL-26590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18140693#comment-18140693
]
Federico Mariani commented on CAMEL-26590:
------------------------------------------
Tried the upgrade against Spring Boot *4.2.0-RC2* (Spring Framework 7.1.0-RC2).
Branches, no PR yet:
* camel:
[CAMEL-26590-sb-4.2.0|https://github.com/Croway/camel/compare/main...CAMEL-26590-sb-4.2.0]
* camel-spring-boot:
[CAMEL-26590-sb-4.2.0|https://github.com/Croway/camel-spring-boot/compare/main...CAMEL-26590-sb-4.2.0]
(needs the camel branch installed)
h3. Changes needed
*camel*
* {{parent/pom.xml}} aligned with the 4.2.0-RC2 BOM: spring-boot 4.2.0-RC2,
spring 7.1.0-RC2, spring-security 7.2.0-RC1, spring-amqp / spring-ldap /
spring-data-redis 4.2.0-RC1, spring-batch 6.1.0-RC1, spring-ws 5.1.0-RC1,
spring-cloud-config 5.1.0-RC2, micrometer 1.18.0-RC2, micrometer-tracing
1.8.0-RC2, reactor 3.9.0-RC1, reactor-netty 1.4.0-RC1, netty 4.2.20.Final
* camel-spring-ws did not compile: Spring WS 5.1 removed the deprecated
{{WebServiceMessageSender.supports(URI)}}. The sender decorator in
{{SpringWebserviceProducer}} now delegates {{supports(URI, UriSource)}}
(compiles with 5.0.x too)
* 4.24 upgrade guide: notes for the RabbitMQ starter and Spring WS 5.1
*camel-spring-boot*
* {{camel-spring-rabbitmq-starter}} depends on {{spring-boot-rabbitmq}}, with a
test and a RabbitMQ IT. Confirmed the problem: with only
{{spring-boot-starter-amqp}} on 4.2 there is no {{ConnectionFactory}} bean
* regenerated files: {{camel-spring-boot-dependencies}} (micrometer versions)
and {{spring-boot.json}} (the {{management.endpoint.camelroutes}} group now has
{{CamelRoutesEndpoint}} as type, from a configuration processor change in Boot;
the properties are unchanged)
* nothing else: all modules compile, tests included
h3. Tests, all passing on 4.2.0-RC2
* camel: all camel-spring-parent modules (incl. the RabbitMQ and Redis ITs),
camel-spring-ai unit tests, camel-jms, camel-sql, camel-micrometer,
camel-micrometer-observability, camel-observation, camel-reactor. The 28 other
modules using these Spring / Micrometer / Reactor versions compile
* camel-spring-boot: full build, incl. the archetype IT that starts an app on
4.2.0-RC2; tests of core/camel-spring-boot (incl. the virtual threads IT),
camel-spring-boot-xml and the rabbitmq, observability-services, platform-http,
micrometer, observation, spring-cloud-config, undertow-spring-security, sql and
kafka starters
h3. Once 4.2.0 is GA
* replace the RC versions with those of the GA BOM and rerun the tests above
* Spring AI: still on 2.0.2 (tests pass), decide on 2.1.x
* springdoc: no release built on Boot 4.2 yet (camel-spring-boot is on 3.0.2)
* Boot 4.2 manages newer versions than Camel for kafka (4.4.0 vs 4.3.1), log4j2
(2.26.1 vs 2.25.5) and hazelcast (5.7.0 vs 5.4.0)
* deprecation warnings only: {{RestTemplate}} (Framework 7.1), still required
by Spring Cloud Config 5.1 in camel-spring-cloud-config
* camel-spring-boot-examples/rabbitmq: move to {{spring-boot-starter-rabbitmq}}
* the OpenTelemetry items of this issue are follow-up work, not needed for the
upgrade
_Claude Code on behalf of 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)
