Repository navigation
CAMEL-24961: docs - the component, data format and language pages show the body types in a Message Body section - #28247
Conversation
…s, and the body it leaves after a step A @BodyTypes annotation on the endpoint, data format or language class says the body per side (consumerOut, consumerReply, producerIn, producerOut, marshal, unmarshal and expression in and out): its carriers (null, text, bytes, stream, file, value, map, list, pojo, unchanged, any, unknown), the Java type when it is always the same, the format, the options it depends on, the body for other option values, and a description. The package plugin writes it as a bodyTypes section of the catalog JSON and checks that each side fits the kind and that the options it names exist. A subclass declares its own. The first slice: file, direct, seda, timer, cron, kamelet, http, https, rest-openapi, xslt, sql and the json data format (jackson), read from the code that sets the body and checked against the body types the message history records when routes run. camel_catalog_doc returns them. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
…tp, jms, kafka, aws2-sqs, the csv, jacksonXml and yaml data formats, and the languages The second slice of the catalog body types: - components: platform-http, rest (and the rest-openapi consumer), ftp, ftps, sftp, jms, activemq, activemq6, amqp, kafka, aws2-sqs, log, mock, scheduler, quartz; - data formats: csv, jacksonXml, snakeYaml; - languages: simple, constant, jsonpath, xpath, groovy, jq. Each value is read from the code that sets the body, and checked against the body types the message history recorded when the tests of the modules and reference routes ran (the ftp integration tests included). camel_catalog_doc gives the body types a line per side, and its answer is cut at 18000 characters instead of 16000, so the four sides of the jms components leave the options a limit asks for room. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
paho-mqtt5: the consumer gives the payload as a byte array, the producer sends what converts to one and leaves the body unchanged. mongodb: the consumer gives a Document (or null for a change without its full document with changeStreams); the producer takes a document or a query, and leaves a body by operation: a Document or null for a find of one, a List for findAll, findDistinct and aggregate, a Long for count, the result of the driver for the other writes. Read from the code that sets the body, and checked against a mosquitto and a mongodb container started with camel infra. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
…ts an option value without carriers
From the review of PR 28241:
- An iterator is read once and has no size and no index, so tooling that
reads list as a List accepts ${body.size()} or ${body[0]} on it, which fail
at runtime. The new iterator carrier names it: sql with outputType=StreamList
gives an iterator, not a list.
- A @BodyType.When with no carriers (carrier = {}) wrote "carriers": [] into
the catalog. The build now rejects it, as it does a side without carriers.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
…MEL-24961-catalog-body-types-2 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
… camel_catalog_doc says unknown for no carriers From the review of PR 28242: - The csv data format with lazyLoad=true gives an iterator, with the iterator carrier of PR 28241, not a list. - camel_catalog_doc says unknown for a body without carriers, instead of failing. The build rejects it now, but a catalog read from elsewhere may have one. - Sqs2Endpoint imports org.apache.camel.spi.* already: only the import of the nested BodyType.Carrier stays. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
…w the body types in a Message Body section The documentation page of each component, data format and language that has body types in the catalog gets a Message Body section: a table with the body at each side (consumer, producer input and output, marshal, unmarshal, expression), the body for other values of an option, and the options the body depends on. A page without body types has no such section. - The body-types.adoc partial renders the bodyTypes section of the catalog JSON with the jsonpath extension of the website, like the message headers. The partials of the components (after the headers), the data formats and the languages (after the options) include it, so no page changes. - camel.js renders a side: its name, its carriers and Java type, and the description with the option values and the options it depends on. - camel catalog doc prints the same table in the terminal. Checked with a local Antora build of the components docs with the website extensions: the pages of file, http, platform-http, timer, kafka, sql, kamelet, jackson, csv, xpath, jq and simple show the section, and jdbc does not. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
|
🌟 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.
The JS helpers in correctly follow the AsciiDoc escaping rules (only and are attribute references — dotted names like are not, so leaving them unescaped is intentional and correct). The conditional pattern mirrors the existing headers implementation exactly. stores plain values via , so in renders cleanly. The map has exactly 10 entries, which is at the limit but valid.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
The attribute holds an array, and the catalog JSON and BodyTypeModel call the same field carriers. The Javadoc of BodyTypeModel.isUnknown() says that a side with no carriers is unknown too. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
…MEL-24961-catalog-body-types-2
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
…AMEL-24961-catalog-body-types-docs
…e data format and language schemas Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
…-types' into feature/CAMEL-24961-catalog-body-types-2
…AMEL-24961-catalog-body-types-docs
…n read as a list, as the carriers do Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
…AMEL-24961-catalog-body-types-docs
…atalog-body-types-docs Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
|
🧪 CI tested the following changed modules:
🔁 1 test passed only after a retry on JDK 21 (1 retried attempt) Recovered flaky tests on JDK 21 (1)
🔬 Scalpel shadow comparison — Scalpel: 5 of 707 tested, 8 compile-only — current: 5 all testedMaveniverse Scalpel detected 5 affected modules (current approach: 5). Skip-tests mode would test 5 modules (2 direct + 5 downstream), skip tests for 8 (generated code, meta-modules) Modules Scalpel would test (5)
Modules with tests skipped (8)
💡 Manual integration tests recommended:
All tested modules (15 modules, 3m 10s total)Total reactor time: 3m 10s
Top 20 slowest modules:
|
…omponent without body types, as jdbc gets them Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
gnodet-bot
left a comment
There was a problem hiding this comment.
Following up on my earlier review — all previous findings remain addressed; no new issues introduced by the latest commit.
The test change (jdbc → weather for the "no body types" assertion) is correct: PR #28242 (now merged) added body types to the jdbc component, making the original assertion fail. The weather component has no bodyTypes in the catalog JSON, making it a valid replacement. The change is minimal and accurate.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
Stacked on #28242. This is the documentation part of the catalog body types (CAMEL-24961): the pages of the components, data formats and languages show their body types, and so does
camel catalog doc.On the website. Each component, data format and language page with body types in the catalog gets a Message Body section. A page without body types, such as jdbc, has no section.
With output=bytes: bytes (byte[]));Not known when source is set).filetext,bytes,streamorfileallowNullBody=true:null,text,bytes,streamorfileunchanged(the File page)
Rendered with the website's extensions and UI, the File component and the XPath language:
How it is built
body-types.adoc, renders thebodyTypessection of the catalog JSON with the jsonpath extension of the website, as the message headers table does. The JSON comes through the same links to each module's generated JSON.camel.jsgets three helpers that render a side: its name, its carriers and Java type, and the description with the option values and the options it depends on. They escape only what AsciiDoc would read as an attribute ({body}, not{header.foo}).In the terminal.
camel catalog docprints the same table after the message headers of a component, and after the options of a data format or language. It uses the compact lines ofcamel_catalog_doc.Checked with a local Antora build of the components docs, with the website's extensions and UI:
Tests:
CatalogDocTest.shouldPrintTheMessageBody(file, jackson, and jdbc without a table), and the catalog doc tests of camel-jbang-core (49).Docs: the Camel Catalog page says the pages and
camel catalog docshow the body types.Claude Code on behalf of davsclaus
🤖 Generated with Claude Code