davsclaus commented on code in PR #27825:
URL: https://github.com/apache/camel/pull/27825#discussion_r4270134139
##########
parent/pom.xml:
##########
@@ -542,7 +542,7 @@
<univocity-parsers-version>2.10.2</univocity-parsers-version>
<velocity-tools-version>3.1</velocity-tools-version>
<velocity-version>2.4.1</velocity-version>
- <vertx-version>4.5.35</vertx-version>
+ <vertx-version>5.2.1</vertx-version>
Review Comment:
See point 1 in the review: `camel-launcher` resolves `vertx-core` through
`camel-jbang-plugin-kubernetes` → `kubernetes-httpclient-vertx` (fabric8
4.5.31), so after this change the fat jar would have `vertx-core` 4.5.31 next
to `vertx-web` 5.2.1. `io.fabric8:kubernetes-httpclient-vertx-5` (already in
7.9.0) avoids it.
##########
docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_24.adoc:
##########
@@ -13,6 +13,43 @@ See the xref:camel-upgrade-recipes-tool.adoc[documentation]
page for details.
== Upgrading Camel 4.23 to 4.24
+=== Vert.x 5
+
+Camel now uses Vert.x 5. This affects `camel-vertx`, `camel-vertx-http`,
`camel-vertx-websocket`,
+`camel-platform-http-vertx`, `camel-platform-http-main`,
`camel-platform-http-jolokia`, `camel-knative-http`
+and `camel-oauth`. Application code that uses the Vert.x API directly, for
example to create a custom `Vertx`
+instance, a custom `Router` handler, or an authentication provider for
platform-http, must be migrated as
+described in the https://vertx.io/docs/guides/vertx-5-migration-guide/[Vert.x
5 migration guide]. Notably,
+the callback variants of asynchronous methods are removed in favour of the
methods returning a `Future`.
+
+A metrics or tracing factory can no longer be set on the `VertxOptions` given
to a component (the
+`MetricsOptions.setFactory` and `TracingOptions.setFactory` methods are
removed). Either create the `Vertx`
+instance with `Vertx.builder()` and set it on the component (or bind it to the
registry), or register the factory
+as a `io.vertx.core.spi.VertxServiceProvider` service.
+
+`VertxPlatformHttpRouter.mountSubRouter` is removed, as it is no longer part
of the Vert.x `Router` API.
+Use `router.route(mountPoint + "*").subRouter(subRouter)` instead.
+
+When the connection of a WebSocket is lost without a close frame, the
`camel-vertx-websocket` consumer no longer
+passes the resulting exception to the consumer exception handler, and no
longer routes it as an `ERROR` event. It is
+handled as a WebSocket closed with a close frame: a consumer with
`fireWebSocketConnectionEvents=true` routes a `CLOSE`
+event, and a consumer with `consumeAsClient=true` reconnects. With the default
`fireWebSocketConnectionEvents=false`,
+the lost connection of a peer is therefore no longer logged as a warning.
+
+When the WebSocket of a consumer with `consumeAsClient=true` reports any other
error, the consumer exception handler
+now receives that exception. Previously it received the cause of that
exception, which could be `null`.
+
+When the WebSocket that the `camel-vertx-websocket` producer sends to (a
server not managed by Camel) reports an error
+other than a lost connection, the exchange now fails with that exception.
Previously it failed with the cause of that
+exception, which could be `null`.
+
+`camel-arangodb` still uses Vert.x 4, as the ArangoDB Java driver does not
support Vert.x 5 yet
Review Comment:
If `camel-kubernetes` is not moved to `kubernetes-httpclient-vertx-5` (or
kubernetes-client 8.x) before 4.24, it needs a note here too.
`kubernetes-client` 7.9.0 brings `vertx-core` 4.5.31 at runtime through
`kubernetes-httpclient-vertx`, so `camel-kubernetes` with
`camel-platform-http-main` has the same clash as described for ArangoDB.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
