Repository navigation
Conversation
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
gnodet-bot
left a comment
There was a problem hiding this comment.
LGTM. No issues found.
Purely additive metadata: @BodyTypes annotations on 7 Endpoint classes and the corresponding generated JSON for 10 IoT components (coap×4, milo-browse, milo-client, milo-server, plc4x, tahu-edge, tahu-host). Descriptions accurately reflect runtime behavior — including the known silent-failure cases documented honestly in the PR body. Catalog and component-local JSON copies are consistent. No code logic changed.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 11 of 707 tested, 26 compile-only — current: 11 all testedMaveniverse Scalpel detected 11 affected modules (current approach: 11). Skip-tests mode would test 11 modules (5 direct + 7 downstream), skip tests for 26 (generated code, meta-modules) Modules Scalpel would test (11)
Modules with tests skipped (26)
All tested modules (38 modules, 5m 14s total)Total reactor time: 5m 14s
Top 20 slowest modules:
|
… milo-browse, milo-client, milo-server, plc4x, tahu-edge and tahu-host Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
0367cc1 to
a0862d3
Compare
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
|
Merged to main as b4a4e0e (squashed with the other CAMEL-24961 body type groups, tested together locally). Claude Code on behalf of davsclaus |
Claude Code on behalf of davsclaus
This group adds the catalog body types (CAMEL-24961) for ten IoT components: coap, coaps, coap+tcp and coaps+tcp, milo-browse, milo-client and milo-server, plc4x, tahu-edge and tahu-host. Each change is an
@BodyTypesannotation on the Endpoint, plus the JSON it generates and the catalog copy. The four coap schemes share one Endpoint class, so they get the same body types. No doc page changes.What the catalog says now
byte[], empty when there is none; also the notifications of observebyte[]; aBooleanfor PING; unchanged with notify=trueany: the nodes come from the CamelMiloNodeIds header or the node optionExpandedNodeIdtoBrowseResultDataValue, whose status code tells a good value from a lost connectionVariantor aDataValueStatusCodeof a write, the result of a method call, or a List ofDataValuefor a readDataValuea client wrotePlcWriteResponseSparkplugBPayload, or no body for the metrics of the CamelTahuMetric headersbyte[], or null; the metrics are headersChecked at runtime. Throwaway tests, not part of the PR, sent text, bytes, a stream, a file, a Map, a POJO, a number and no body. The setups:
simulated://driver, as a consumer, a triggered consumer, a polling consumer and a producer.Not run: coaps and coaps+tcp (DTLS and TLS), the milo method call (its test covers it), and a tahu payload with a uuid.
PRs #28367, #28368, #28371 (camel-milo) and #28387 (camel-plc4x) change code of these modules, but not their Endpoint classes or generated files. #28387 keeps the bodies the same.
Bugs found, not fixed here. Filed one JIRA per component: CAMEL-26178 (camel-coap), CAMEL-26179 (camel-milo), CAMEL-26180 (camel-plc4x), CAMEL-26181 (camel-tahu).
byte[]converter, such as a Map, a POJO or an Integer, sends an empty payload with no error.receive(), instead of failing the exchange.Local checks
🤖 Generated with Claude Code