Croway opened a new pull request, #27145: URL: https://github.com/apache/camel/pull/27145
[CAMEL-25197](https://issues.apache.org/jira/browse/CAMEL-25197) Adds a WebSocket transport to camel-cli-connector, so developer tools can drive a running integration without sharing its filesystem, and get snapshots pushed instead of polled. **Changes** - SPI extracted from `LocalCliConnector`: `CliActionDispatcher`, `CliSnapshotProducer`, `CliConnectorTransport`. The file protocol moves as-is to `FileCliConnectorTransport` (default, unchanged). File protocol tests are added first, and pass before and after the extraction. Subclasses overriding `sigterm()` (Spring Boot, Quarkus) keep working. - `WebSocketCliConnectorTransport` (`camel.cli.transport=websocket`): dials out to `camel.cli.websocket.url` with the JDK client (no new dependency, no port opened). Versioned JSON envelope: `hello`, `action`/`result` by `requestId`, `snapshot`. The actions and snapshots are the same JSON as the file protocol. - Reliability: reconnects with backoff and jitter, ping heartbeat, a hanging send aborts and reconnects, incremental trace/receive snapshots split below 256 KB, actions on their own thread with a bounded queue, `stop` action. - Security (dev tool): refuses to start with the `prod` profile, token required unless the tool is on loopback, warnings at startup and for `ws://` to a remote host. - Documented in `cli-connector.adoc`. **Testing**: 24 unit tests (in-test Vert.x WebSocket server); Camel CLI against the file transport; a 240 s soak test with 5 apps and 4 network/tool disruptions, which is attached to the JIRA. The soak test found three of the commits here. **Known limitation (not new)**: trace uids are assigned before the trace is queued, so under concurrency (seen with virtual threads) a trace can arrive out of order or be skipped by the incremental "last uid" cursor. The file transport has the same logic. @davsclaus the file transport is moved as-is, so it still creates plain JDK threads. The WebSocket transport now uses `CamelThreadFactory`, for Camel's naming and virtual threads, without being a Camel-managed pool. Is it ok to refactor the file transport in the same way (and clean it up further), in a follow-up? _Claude Code on behalf of Croway_ -- 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]
