Croway opened a new pull request, #27210: URL: https://github.com/apache/camel/pull/27210
_Claude Code on behalf of Croway_ Follow-up of #27145 ([CAMEL-25197](https://issues.apache.org/jira/browse/CAMEL-25197)). The websocket transport of `camel-cli-connector` was hard-wired to the JDK WebSocket client. This puts the socket I/O behind a small SPI, so that runtimes can use their own WebSocket client when the application already has one (Camel Quarkus: the WebSockets Next client; Camel Spring Boot: Spring's client), and fall back to the JDK client otherwise, without adding dependencies. ## Changes - New `org.apache.camel.cli.connector.CliWebSocketClient` (`@since 4.23`): `connect(URI, headers, Listener)` returning a `Channel` (`sendText`, `sendPing`, `close`, `abort`), plus `getName()` and `MAX_MESSAGE_SIZE` (16 MB). - `CliWebSocketHandshakeException`: the HTTP status of a rejected handshake (401/403 still logged as a token problem). - `JdkCliWebSocketClient`: the previous JDK code, moved (partial frames reassembly with the 16 MB cap, `request(1)` flow, automatic pong). - Everything protocol-related stays in the transport, so every client gets it: envelope, hello, actions, snapshots and their splitting, single writer, send timeout, lone surrogates, heartbeat, backoff with jitter, inbound cap, `prod` profile / token / `allow-insecure` checks. - Client selection: the single `CliWebSocketClient` in the registry if any, otherwise the JDK client. New option `camel.cli.websocket.client` (`auto` default, `jdk` to always use the JDK client). The client in use is logged and reported in `hello.transport`. - Incoming frames are now parsed on the transport thread instead of the client callback thread, which can be an event loop (Vert.x). - A close or error reported before the client completes `connect()` is handled (the transport reconnects). - Docs: "WebSocket client" section and the new option in `cli-connector.adoc`. ## Tests - `mvn verify -pl dsl/camel-cli-connector`: 31 tests, 0 failures (the 24 existing ones unchanged, plus 7 new: registry client used, `jdk` forces the JDK client, default client, unknown client refused, close frame `1000` on stop, liveness by pongs only, close before the client reports the connection open). - Soak test (5 Camel Main apps over the WebSocket transport for 240 s, with the tool closing connections, a network blackhole, the tool down and the token rejected): all disruptions recovered, actions and snapshots fine, no unexpected errors. The only reported failure is one trace counted as "received twice or out of order", which also occurs on the code before this change; the harness tracks traces per application rather than per connection. - Also exercised by the Camel Quarkus (WebSockets Next) and Camel Spring Boot clients built on this SPI (separate PRs). -- 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]
