[
https://issues.apache.org/jira/browse/CAMEL-25749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-25749:
--------------------------------
Description:
Step 1 of the design note of 2026-10-05 on CAMEL-24844 (runtime errors).
When a step fails because of the Java type of the body, the reader of the error
(a person, or a model in a dev loop) needs three facts: what the body is, which
step made it so, and the step that fixes it. For example:
bq. {{$\{body\[amount\]\}}} failed: the body is a GenericFile (the file as
read), unchanged since {{from: file:inbox}} (invoices.yaml:30). Unmarshal it
first ({{unmarshal: json}}) to read its fields.
The facts are recorded already: the message history has the body type of every
step ({{MessageHistory.getBodyType()}}, 4.23) and the source location of each
step (CAMEL-24972). What is missing is one place that says them. Today each
failure writes its own partial hint, in its own words:
* camel-groovy {{GroovyExpression}}: a property read on a body that is still
text (CAMEL-25330)
* camel-support {{UnmarshalProcessor}}: unmarshal on a null body (CAMEL-25285)
* camel-jsonpath {{JsonPathEngine}} and camel-jq {{JqExpression}}: a null body
(CAMEL-24838)
* camel-bean {{BeanExpression}}: a missing Map key lists the keys of the Map
(CAMEL-25322)
* {{InvalidPayloadException}} and {{NoTypeConversionAvailableException}} name
the type of the body, and take a hint from a caller that knows more
h3. Proposal
* One helper in camel-support that builds the sentence from the exchange:
** the body in plain words: text, bytes, a cached stream, the file as read,
parsed data (a Map or a List), an object of a named class, or null;
** the step that set it, from the message history: route, node and source
location;
** the step that fixes it: unmarshal with the data format of the payload,
convertBodyTo String, or setBody.
* With message history off, it still names the body; only the step that set it
is left out.
* The hints above move onto it, so the wording is the same everywhere.
* Only failures about the body use it: an expression that reads the body
(simple and bean OGNL, Groovy, jsonpath, jq), a conversion of the body,
{{InvalidPayloadException}}. An error about a header or an exchange property
gets no body sentence, as agreed on CAMEL-24844 on 2026-09-20.
h3. Measure
The body type collisions per series of the local-model benchmark (19 of 156
attempts in the round-2 series), before and after.
h3. Not in scope
The static checks of the validator, the observed types (step 2, CAMEL-25750),
the catalog metadata (CAMEL-24961).
_Filed by Claude Code on behalf of davsclaus_
was:
Step 1 of the design note of 2026-10-05 on CAMEL-24844 (runtime errors).
When a step fails because of the Java type of the body, the reader of the error
(a person, or a model in a dev loop) needs three facts: what the body is, which
step made it so, and the step that fixes it. For example:
bq. {{$\{body\[amount\]\}}} failed: the body is a GenericFile (the file as
read), unchanged since {{from: file:inbox}} (invoices.yaml:30). Unmarshal it
first ({{unmarshal: json}}) to read its fields.
The facts are recorded already: the message history has the body type of every
step ({{MessageHistory.getBodyType()}}, 4.23) and the source location of each
step (CAMEL-24972). What is missing is one place that says them. Today each
failure writes its own partial hint, in its own words:
* camel-groovy {{GroovyExpression}}: a property read on a body that is still
text (CAMEL-25330)
* camel-support {{UnmarshalProcessor}}: unmarshal on a null body (CAMEL-25285)
* camel-jsonpath {{JsonPathEngine}} and camel-jq {{JqExpression}}: a null body
(CAMEL-24838)
* camel-bean {{BeanExpression}}: a missing Map key lists the keys of the Map
(CAMEL-25322)
* {{InvalidPayloadException}} and {{NoTypeConversionAvailableException}} name
the type of the body, and take a hint from a caller that knows more
h3. Proposal
* One helper in camel-support that builds the sentence from the exchange:
** the body in plain words: text, bytes, a cached stream, the file as read,
parsed data (a Map or a List), an object of a named class, or null;
** the step that set it, from the message history: route, node and source
location;
** the step that fixes it: unmarshal with the data format of the payload,
convertBodyTo String, or setBody.
* With message history off, it still names the body; only the step that set it
is left out.
* The hints above move onto it, so the wording is the same everywhere.
* Only failures about the body use it: an expression that reads the body
(simple and bean OGNL, Groovy, jsonpath, jq), a conversion of the body,
{{InvalidPayloadException}}. An error about a header or an exchange property
gets no body sentence, as agreed on CAMEL-24844 on 2026-09-20.
h3. Measure
The body type collisions per series of the local-model benchmark (19 of 156
attempts in the round-2 series), before and after.
h3. Not in scope
The static checks of the validator, the observed types (step 2, STEP2KEY), the
catalog metadata (CAMEL-24961).
_Filed by Claude Code on behalf of davsclaus_
> camel-support - one helper for errors about the message body: what the body
> is, which step set it, and the step that fixes it
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25749
> URL: https://issues.apache.org/jira/browse/CAMEL-25749
> Project: Camel
> Issue Type: Improvement
> Components: camel-bean, camel-groovy, camel-jq, camel-jsonpath,
> camel-support
> Reporter: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> Step 1 of the design note of 2026-10-05 on CAMEL-24844 (runtime errors).
> When a step fails because of the Java type of the body, the reader of the
> error (a person, or a model in a dev loop) needs three facts: what the body
> is, which step made it so, and the step that fixes it. For example:
> bq. {{$\{body\[amount\]\}}} failed: the body is a GenericFile (the file as
> read), unchanged since {{from: file:inbox}} (invoices.yaml:30). Unmarshal it
> first ({{unmarshal: json}}) to read its fields.
> The facts are recorded already: the message history has the body type of
> every step ({{MessageHistory.getBodyType()}}, 4.23) and the source location
> of each step (CAMEL-24972). What is missing is one place that says them.
> Today each failure writes its own partial hint, in its own words:
> * camel-groovy {{GroovyExpression}}: a property read on a body that is still
> text (CAMEL-25330)
> * camel-support {{UnmarshalProcessor}}: unmarshal on a null body (CAMEL-25285)
> * camel-jsonpath {{JsonPathEngine}} and camel-jq {{JqExpression}}: a null
> body (CAMEL-24838)
> * camel-bean {{BeanExpression}}: a missing Map key lists the keys of the Map
> (CAMEL-25322)
> * {{InvalidPayloadException}} and {{NoTypeConversionAvailableException}} name
> the type of the body, and take a hint from a caller that knows more
> h3. Proposal
> * One helper in camel-support that builds the sentence from the exchange:
> ** the body in plain words: text, bytes, a cached stream, the file as read,
> parsed data (a Map or a List), an object of a named class, or null;
> ** the step that set it, from the message history: route, node and source
> location;
> ** the step that fixes it: unmarshal with the data format of the payload,
> convertBodyTo String, or setBody.
> * With message history off, it still names the body; only the step that set
> it is left out.
> * The hints above move onto it, so the wording is the same everywhere.
> * Only failures about the body use it: an expression that reads the body
> (simple and bean OGNL, Groovy, jsonpath, jq), a conversion of the body,
> {{InvalidPayloadException}}. An error about a header or an exchange property
> gets no body sentence, as agreed on CAMEL-24844 on 2026-09-20.
> h3. Measure
> The body type collisions per series of the local-model benchmark (19 of 156
> attempts in the round-2 series), before and after.
> h3. Not in scope
> The static checks of the validator, the observed types (step 2, CAMEL-25750),
> the catalog metadata (CAMEL-24961).
> _Filed by Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
