[davsclaus]

Stacked on #28275. This is the core group of the catalog body types (CAMEL-24961): the core components without body types so far, knative, and the core languages.

What the catalog says now

Component	Consumer	Producer input	Producer output
bean, class	(producer only)	any: the first parameter of the method gets it, converted to its type	unknown: what the method returns, null too; unchanged after a void method
browse	the body the producer sent	any	unchanged
controlbus	(producer only)	any; the expression as text for the language command	unchanged; text (or unchanged) for status and stats; the result of the expression for the language command
dataformat	(producer only)	any: as the data format named in the path takes it	unknown
dataset	unknown: what the DataSet bean creates	any, compared with the DataSet	unchanged
dataset-test	(producer only)	any, compared with the expected bodies	unchanged
dynamic-router	(producer only)	any	unknown: what the recipient ends with; a text when no subscription matches
dynamic-router-control	(producer only)	any	the subscription id (text) for subscribe and update, true for unsubscribe, text for list and statistics
event	a CamelEvent (pojo); a List with batchSize	(consumer only)
exec	(producer only)	any: the standard input, when it converts to a stream	the ExecResult (pojo)
knative	bytes or no body; the parsed data field of a structured event	text, bytes, stream or file	the response: bytes, or null
language	(producer only)	any: as the language reads it; the script never comes from the body	unknown: the result of the script; unchanged with transform=false; a stream with binary=true
once	no body; with the body option, not known: text, a resource, a value or the result of a language	(consumer only)
ref	unknown: as the endpoint in the registry	any	unknown
rest-api	no body (the GET of the API document)	(consumer only)
saga	(producer only)	any	unchanged
stream	each line as text; a List with groupLines; bytes with readLine=false	text, bytes, stream, file or no body	unchanged
stub	the body the producer sent	any	unknown: unchanged for InOnly or without a consumer
validator	(producer only)	XML: text, bytes, stream, file or a DOM	unchanged
wasm	(producer only)	text, bytes, stream, file or no body, as the standard input	bytes: the standard output
xslt-saxon	(producer only)	as xslt, and JSON text with useJsonBody	as xslt

Language	Reads	Gives
bean (method)	any: the first parameter of the method	unknown: what the method returns; null for a void method
header, exchangeProperty, variable	(not the body)	unknown: the value as it is
ref	any	unknown
file	any, as simple	unknown: text, a Long for file:size and file:modified
tokenize	text, bytes, stream or file	an iterator of text
xtokenize	XML: text, bytes, stream, file or a DOM	an iterator of XML text

The xpath and jq languages read the source option instead of the body when it is set, so their input side now depends on it, as for tokenize and xtokenize.

The bodies a step needs have one word for whatever the body is: any. The build now refuses unknown on those sides; unknown stays for the body after a step.

Checked at runtime. Routes run with camel run logged the class of the body after each step:

• bean:
  • a void method keeps the body, and a method that returns null makes it null;
  • a Map given to a String parameter is its toString();
  • the method language gives null for a void method.
• language:
  • transform=false keeps the body;
  • binary=true with a resource: script gives a stream;
  • the script is never taken from the body.
• controlbus:
  • status gives the text of the state, and stats XML;
  • start and stop keep the body, and so does a route that does not exist;
  • the language command gives the result of the expression.
• stream:
  • the consumer gives each line as a String, a List with groupLines, and a byte[] with readLine=false;
  • stream:out writes text, bytes, a stream and the content of a file, and a Map as its toString(); a List fails.
• exec: the body is the standard input (cat), and the result is an ExecResult; a Map is not sent.
• validator: text, bytes and a stream pass; a Map and no body fail.
• xslt-saxon: the outputs string, bytes and DOM.
• browse and stub: the producer keeps the body, and their consumers get it.
• Also run:
  • once, dataset, event, and dynamic-router with its control endpoint;
  • knative, with binary and structured events over a local environment file;
  • the header, exchangeProperty, variable, file, tokenize and xtokenize languages in setBody.
• Read from the code only: ref, rest-api, saga, wasm and dataset-test.

Docs fixed. These pages said things about the body that the code does not do:

• stream:
  • the producer writes bytes, streams and files too, each with a new line (appendNewLine);
  • stream:header reads the stream header, not header.
• exec:
  • the package of ExecResult was wrong;
  • with outFile, the body is still the ExecResult, which converts to the content of the file.
• language:
  • a script in the header needs allowTemplateFromHeader=true;
  • the groovy example was not valid Groovy.
• once: body=file:data.json (it said file.data.json, which is the literal text).
• browse: the Java example did not compile.
• dataset: defaultHeaders is the headers, not the body.

Measured.

• I ran the validator over the 1204 human-written and 1209 model-written route files, and the reports are the same as with CAMEL-24961: Catalog body types for cloud messaging #28275.
• The share of the endpoint uses in the human-written routes whose component has body types goes from 90.2% to 91.4%.

Tests

• TextBodyFlowTest.testTheBodyOfCoreComponents:
  • a field read after the stream consumer is reported;
  • parsed data sent to stream:out is reported;
  • the knative consumer and the body after a bean are not reported.
• These pass:
  • the 283 tests of camel-yaml-dsl-validator;
  • the 265 validator and catalog doc tests of camel-jbang-core;
  • the build of camel-yaml-dsl-deserializers, which reads the catalog.
• The answers of camel_catalog_doc stay under 18 000 characters: knative, the largest of this group, is 12 555.

Claude Code on behalf of davsclaus

🤖 Generated with Claude Code

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[gnodet-bot]

All 6 documentation fixes verified against source code and official documentation:

1. browse-component.adoc — getBody() → getBody(String.class): correct — the variable is typed String, so getBody(String.class) is the type-safe Camel idiom.
2. dataset-component.adoc — defaultHeaders described as "default message body" → "default message headers": correct — the property is Map<String,Object> for headers.
3. language-component.adoc — ${body} * 2} → body * 2: correct — ${body} is Simple language syntax, not Groovy; also fixes the trailing mismatched }.
4. language-component.adoc — added allowTemplateFromHeader=true: correct — required when providing a script via the CamelLanguageScript header (security default is false).
5. once-component.adoc — body=file.data.json → body=file:data.json: correct — file: is the documented URI scheme prefix per the body parameter description.
6. stream-component.adoc — header → stream: correct — StreamProducer.java confirms exchange.getIn().getHeader("stream").

The @BodyTypes annotation additions and JSON catalog changes are consistent metadata enhancements.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[gnodet-bot]

Following up on my earlier review — the documentation fixes from the previous SHA are all present and verified in the new commit.

This PR's new commits add @BodyTypes annotations to the core component and language endpoint classes, with matching JSON catalog regeneration. I've verified the following:

• Carrier semantics: no production code uses Carrier.UNKNOWN on input sides (producerIn, consumerIn, expressionIn) or Carrier.ANY on output sides (producerOut, consumerOut, expressionOut). The one UNKNOWN-on-input occurrence is in SomeEndpointWithBadBodyTypes.java — a negative test confirming the validator rejects it correctly.
• Annotation ↔ JSON consistency: spot-checked StreamEndpoint (complex byOption/dependsOn / javaType), KnativeEndpoint, ControlBusEndpoint. Java annotations and generated JSON are in sync.
• dependsOn option names: all validated against component option names (groupLines, readLine, body, batchSize, binding, consumerComponentName, headerName, failOnNullBody, source, useJsonBody, output). All exist.
• BodyType.java Javadoc: UNKNOWN carrier doc updated identically in both tooling/spi-annotations (source) and core/camel-api (generated copy). The added sentence correctly states the carrier constraint.
• File pairing: all 20 components/languages have changes in both the component-local generated JSON and the catalog copy — no orphans.

LGTM.

This review was generated by an AI agent, Hermès on behalf of @gnodet.