jamesnetherton opened a new pull request, #27825: URL: https://github.com/apache/camel/pull/27825
# Description Upgrades Camel to Vert.x 5.2.1 ([CAMEL-23647](https://issues.apache.org/jira/browse/CAMEL-23647)). The components with direct Vert.x dependencies are migrated following the [Vert.x 5 migration guide](https://vertx.io/docs/guides/vertx-5-migration-guide/): - `camel-vertx`, `camel-vertx-common`, `camel-vertx-http`, `camel-vertx-websocket` - `camel-platform-http-vertx`, `camel-platform-http-main`, `camel-platform-http-jolokia` - `camel-knative-http`, `camel-oauth`, `camel-cli-connector` (test only) No deprecated Vert.x APIs are used. ## Main changes - **platform-http-vertx**: `VertxPlatformHttpRouter` delegates the new `Router` methods (`query*`, `uncaughtErrorHandler`). `mountSubRouter` is removed, as it is no longer part of the Vert.x `Router` API (it was already deprecated in Camel). - **knative-http**: uses the public `WebClient.addInterceptor` instead of casting to the internal `WebClientBase`, and depends on `vertx-codegen-api` instead of the `vertx-codegen` aggregate. - **platform-http-main**: uses the public `io.vertx.core.http.MimeMapping`. - **vertx-websocket**: - A connection lost without a close frame is detected with `HttpClosedException`. The previous `ConnectionBase.CLOSED_EXCEPTION` identity check had stopped matching (already with Vert.x 4.5.x), so such closes were reported as errors. - In Vert.x 5, `WebSocket.isClosed()` only becomes true once the closing handshake is done. A client consumer restarted while a reconnect was pending could therefore reuse a WebSocket about to close. The endpoint now forgets a WebSocket discarded by a reconnect. - The producer and the `consumeAsClient` consumer pass the reported exception rather than its cause (which could be `null`). - **Tests**: callback APIs migrated to futures. A test `VertxMetricsFactory` is registered through `ServiceLoader`, as `MetricsOptions.setFactory` is removed. Vert.x clients are kept referenced for the duration of a test: in Vert.x 5 a client that is garbage collected closes its connections, which made `VertxWebsocketTest` fail intermittently. The changes are documented in the 4.24 upgrade guide. ## Known limitations - **camel-arangodb** still uses Vert.x 4. The ArangoDB Java driver is built against Vert.x 4 and does not support Vert.x 5 yet ([arangodb/arangodb-java-driver#625](https://github.com/arangodb/arangodb-java-driver/issues/625)). An application that combines `camel-arangodb` with one of the Vert.x 5 based components resolves a single version of the `io.vertx` artifacts, so one side can fail at runtime. The upgrade guide describes the workaround suggested by the driver maintainers (`arangodb-java-driver-shaded`). - **Kubernetes client**: the fabric8 Kubernetes client 7.x (`kubernetes-httpclient-vertx`) is built against Vert.x 4. `camel-jbang-plugin-kubernetes` therefore currently resolves `vertx-core` 4.5.x next to the Vert.x 5 artifacts brought in by `camel-platform-http-main`. Its tests pass, but we will follow up with the Kubernetes Client 8.x upgrade in [CAMEL-25031](https://issues.apache.org/jira/browse/CAMEL-25031) so that it aligns with Vert.x 5. ## Internal Vert.x APIs still in use There is no public alternative for these. All but the test helpers were already used with Vert.x 4: - `RouteImpl.setEmptyBodyPermittedWithConsumes` and `InboundBuffer` (`camel-platform-http-vertx`) - `SocketAddressImpl` type converter (`camel-platform-http-vertx`) - `web.impl.Utils.pathOffset` (`camel-platform-http-jolokia`) - `web.client.impl.HttpContext` (`camel-knative-http`): part of the public `WebClient.addInterceptor` signature - `io.vertx.core.internal.VertxInternal` / `BlockedThreadEvent` in test helpers (blocked thread checks) ## Testing - `mvn dependency:tree -Dincludes=io.vertx` shows only 5.2.1 for every module with a direct Vert.x dependency. - Unit tests pass for all the modules above, and for `camel-mcp-server`, `camel-micrometer-prometheus`, `camel-ibm-watsonx-ai`, `camel-a2a`, `camel-openai`, `camel-jsonpath`, `camel-openapi-validator`, `camel-rest-openapi`, `camel-rest-postman`, `camel-cli-debug`, `camel-jbang-core`, `camel-kamelet-main` and `camel-jbang-plugin-kubernetes`. - The Vert.x related Spring Boot starters in camel-spring-boot build and pass their tests against this branch without changes. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (The affected modules were built with `mvn install`, which left no uncommitted generated changes. A full build from the root folder was not run.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. --- _Claude Code on behalf of jamesnetherton_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
