[
https://issues.apache.org/jira/browse/CAMEL-25750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18128536#comment-18128536
]
Claus Ibsen commented on CAMEL-25750:
-------------------------------------
h3. Design, as agreed with Claus (2026-10-18)
*1. A context plugin.* {{org.apache.camel.spi.BodyTypeRegistry}} in camel-api
({{@since 4.24}}), looked up with
{{getCamelContextExtension().getContextPlugin(BodyTypeRegistry.class)}}, so no
new method on CamelContext. {{DefaultBodyTypeRegistry}} lives in
camel-base-engine, is installed with the message history (the dev profile), and
is fed by {{DefaultMessageHistory.captureBody}}, so every message history
factory feeds it. Per route node it keeps the body type the node was reached
with: the last one, and whether it varied.
*2. A revision per route.* For each route the registry keeps a revision and a
checksum of the source the route was loaded from
({{Route.getSourceResource()}}):
* a reload with code that differs bumps the revision and drops what the route's
nodes had seen;
* a reload of the same code keeps both.
*3. Both kinds of facts.*
* *Per line*, for the tools that show the running app:
{{RouteStructureDevConsole}} adds the observed type to each node, and the
revision and checksum to each route. {{camel cmd route-structure}}, the TUI and
{{camel_runtime_route_structure}} then show "what the body was at each step",
across exchanges, without --dev. A tool that holds a file (the TUI editor,
camel validate) compares its checksum with the route's. When they are the same,
the per-line facts apply to that file as they are.
* *Per endpoint*, for a file that differs from what runs (the next version,
checked before it is written): what an endpoint gave does not move with the
lines. That is the body after {{from: kafka:orders}} (the type the route's
first node saw) and after {{to: http://stock/...}} (the type the node after it
saw).
* camel-jbang passes them to the validator as a field of {{ProjectFacts}}
(CAMEL-25762): per line when the checksum matches, per endpoint otherwise. An
observation that varied is left out.
*4. The validator fills its gaps with them.* After a consumer or a to: whose
output the walk does not know, an observed type sets the state (text or data),
and the existing checks apply, saying where the type came from: "the running
app saw a ByteArrayInputStreamCache here". Gaps stay at first. They close as
more routes run with the registry on, and the facts are visible now to the
model benchmarks too.
*Follow-up: a body type survey.* Run the example routes and the doc samples
with the registry on, and collect what each endpoint gave. That is the ground
truth to check the validator's hand tables against, and to fill and verify the
catalog metadata of CAMEL-24961, the reference runs the 2026-10-05 note asks
for.
*PRs, in order:*
# the registry, the route revision and checksum, and the route-structure
console fields (core, console);
# camel-jbang reads them from the running app, and the validator uses them
(camel-jbang, validator);
# the survey (later, its own issue).
_Claude Code on behalf of davsclaus_
> camel-jbang - camel validate fills the gaps of its body walk with the body
> types a running app observed, and an MCP tool says what the body was at each
> step
> ------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25750
> URL: https://issues.apache.org/jira/browse/CAMEL-25750
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang, camel-yaml-dsl
> Reporter: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> Step 2 of the design note of 2026-10-05 on CAMEL-24844 (observed types feed
> the authoring tools).
> The body walk of the YAML validator ({{BodyTypeFlow}} and {{TextBodyFlow}} in
> camel-yaml-dsl-validator) reports only where it is certain what the body is:
> after the file consumer, a setBody with a constant, a marshal, a
> convertBodyTo String or byte[], or a {{direct:}} route that ends with one of
> those. After kafka, jms, an HTTP call, a bean or a Kamelet it does not know
> the body and says nothing, which is right for a file that has never run.
> In a dev loop the app has usually run those steps already ({{camel run
> --dev}}, or a model through camel-jbang-mcp), and the message history
> recorded the body type at each one ({{MessageHistory.getBodyType()}}, 4.23).
> Today that fact is shown for one exchange only: {{camel history}} and the
> {{camel_runtime_history}} tool return the history of the last completed
> exchange.
> h3. Proposal
> # *Observed types per step.* With message history on (the dev profile), the
> running app keeps the body types seen at each route node: the last one, and
> whether it varied. Each node carries its source location (CAMEL-24972), so a
> tool can match it to a line of the file. camel-jbang reads it like the other
> runtime facts.
> # *The validator takes them as facts.* When {{camel validate}} or
> {{camel_validate_source}} checks a file of a running app, an observed type
> fills a step where the static walk says unknown, and the existing checks
> apply: {{$\{body\[x\]\}}} on a body that was seen to be a String is reported,
> whatever component produced it. A type that varied, or a step that has not
> run, stays unknown and gets no report.
> # *An MCP tool says what the body was at each step* of the running app, from
> the same data and not only the last exchange, so a model reads it before it
> writes the next step instead of guessing.
> This covers what was run, and only that. Paths that were not tried stay
> unknown, which is honest.
> h3. Measure
> The body type collisions per series of the local-model benchmark, with the
> static walk alone and with observed types.
> h3. Not in scope
> The error messages (step 1, CAMEL-25749), the catalog metadata (CAMEL-24961).
> _Filed by Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
