[davsclaus]

Stacked on #28246. This is the AI group of the catalog body types (CAMEL-24961). The group is openai, langchain4j-chat, a2a, docling, milvus, qdrant, ai-tool and ibm-watson-language: of the components the human-written routes use, these are the ones used most that had no body types yet.

What the catalog says now

Component	Producer input	Producer output
openai	any: the prompt, which userMessage can replace. audio, image-edit, batch and decisions take their own body	text. With streaming=true, an iterator. With autoToolExecution=false, the tool calls. Per operation: embeddings gives a list, audio-speech bytes, batch-results an iterator, decisions a Decision, and batch and moderation keep the body
langchain4j-chat	any. CHAT_SINGLE_MESSAGE_WITH_PROMPT takes a map, CHAT_MULTIPLE_MESSAGES a list	text
a2a	text, bytes, stream, file or pojo (a Message). The task and push config operations read headers	text. Per operation and dataFormat: an iterator of events, a list of tasks, a config
docling	any, as CamelDoclingInputFilePath can replace the body. The batch operations take a list	text. A DoclingDocument, a status, metadata, or the batch and chunk results
milvus	pojo: the request of the SDK	pojo: the result of the SDK
qdrant	pojo, list or null, by the action header	list, pojo or unchanged
ibm-watson-language	any, as a header can give the text	pojo: AnalysisResults

The consumers:

• the openai webhook gives the event (UnwrapWebhookEvent) and answers without a body;
• a2a gives the text of the message (the Message with dataFormat=POJO) and replies with text or a Message;
• docling gives the converted document as text;
• ai-tool gives no body, as the arguments are headers, and sends the body back as text.

Checked at runtime against llama3.2 on a local Ollama, through its OpenAI API:

• chat-completion gives a String, also with jsonSchema;
• with streaming=true, an Iterator of ChatCompletionChunk;
• responses gives a String;
• with autoToolExecution=false, a java.util.Optional of the tool calls; when the tools run, a String;
• the ai-tool route gets no body, and the argument as a header;
• the three operations of langchain4j-chat give a String.

The local server was not started for embeddings, so I took that body from the SDK, where Embedding.embedding() returns a List<Float>. The other components were read from their code.

Two changes, for openai

• The validator reads the options in the path of an endpoint, as the catalog parses them. The operation of openai is in the path (openai:embeddings). A path the catalog cannot read, such as a toD with an expression, says nothing about its options.
• The build rejects a byOption value that its option cannot have: it must be a value of the enum, or true or false for a boolean, ignoring case. A misspelled embedding would otherwise never hold. The 166 values in the catalog pass.

When a header can replace the body. Tooling cannot see headers. The prompt of openai, the text of Watson and the file of docling can each come from a header, and then the body is not used. So those inputs are any, and the description says what the body must be without the header. This way the validator never reports a body that a header replaces.

Measured. I ran the validator over the 1204 human-written and 1209 model-written route files: the reports are the same as with #28246. The human files use openai 7 times, a2a 5, langchain4j-chat 2, ibm-watson-language 2, and milvus, qdrant and ai-tool once each. None reads a field of the text answer without an unmarshal: the milvus example splits the text with ${body.trim().split(';')[0]}.

Tests

• TextBodyFlowTest.testTheOptionsInThePathOfTheEndpoint:
  • a field read on the JSON answer of chat-completion is reported;
  • llm:embeddings gives a List;
  • a toD with an expression in the path says nothing.
• EndpointSchemaGeneratorMojoTest: a value the option does not have.
• These pass:
  • the 280 tests of camel-yaml-dsl-validator;
  • the 187 validator tests of camel-jbang-core;
  • the 102 tests of camel-package-maven-plugin.

Docs: the validation page has the openai example, and the catalog page lists the new build check.

Claude Code on behalf of davsclaus

🤖 Generated with Claude Code

[gnodet-bot]

LGTM. No issues found.

Clean enhancement: @BodyTypes annotations on 8 AI component endpoints, readPath() correctly handles null URIs, dynamic URIs (falls through to configurable), and static path options. checkValue() NPE safety is guaranteed by checkOption() running first. The new test covers all three cases (static path → error, list indexing → ok, dynamic path → silent). Enum values in the annotations were verified against the component models.

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

[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]

Following up on my earlier review — previous findings are all addressed.

The new commit (1ef9d76) is a clean mechanical rename of the carrier field to carriers in every @BodyType.When annotation across A2AEndpoint, DoclingEndpoint, and LangChain4jChatEndpoint. The rename is applied consistently across all occurrences in all three files. No logic change, no runtime behavior change — this is a pure API alignment with the updated @BodyType.When annotation definition in the parent stack. LGTM.

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