[
https://issues.apache.org/jira/browse/CAMEL-24797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Federico Mariani updated CAMEL-24797:
-------------------------------------
Fix Version/s: 4.23.0
> camel-core - Splitter should unwrap Exchange parts like Message parts
> (List<Exchange> from batching consumers)
> --------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24797
> URL: https://issues.apache.org/jira/browse/CAMEL-24797
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, camel-kafka
> Reporter: Federico Mariani
> Assignee: Federico Mariani
> Priority: Major
> Fix For: 4.23.0
>
>
> Splitting a body of type {{List<Exchange>}} (the shape produced by the
> camel-kafka batching consumer, {{batching=true}}, and by
> {{GroupedExchangeAggregationStrategy}}) creates child exchanges whose *body
> is the {{Exchange}} object itself* and whose *headers are empty*. Only
> {{Message}} parts are unwrapped by the Splitter today (the branch added for
> CAMEL-9252).
> Verified on 4.22.0 with a plain {{from("direct:a").split(body())}} route:
> ||Body shape||Child {{${body}}}||Child headers||
> |{{List<Exchange>}}|{{Exchange[]}}|none|
> |{{List<Message>}}|the record body|preserved|
> So {{.split(body()).to("kafka:out")}} after a batching consumer silently
> publishes {{Exchange[]}} as record value, and any filter/transform on the
> record headers sees nothing.
> *Why this matters now*: the Kafka batching docs added in 4.22 (CAMEL-20428,
> PR #25006, "Batch Headers" section) explicitly recommend {{.split(body())}}
> on the batch exchange, and work around the header loss by storing the topic
> in a variable before the split. The batching consumer proposed for camel-sjms
> (dev list thread, CAMEL-16039 / CAMEL-20368) will copy the same
> {{List<Exchange>}} shape, so the gap gets copied with it.
> CAMEL-9323 asked for this in 2015 and was closed as Won't Fix, pointing to
> {{List<Message>}} as the supported shape. That predates a core component
> producing {{List<Exchange>}} itself and documenting a split over it.
> *Proposed outcomes* (one of):
> # Splitter unwraps {{Exchange}} parts like it does {{Message}} parts: set the
> child's message from {{part.getMessage()}} (a few lines next to the existing
> {{instanceof Message}} branch in {{Splitter}}), plus an upgrade-guide note
> since {{getBody()}} on the child changes for that case.
> # Or: keep the Splitter as is, and change the Kafka batching docs to stop
> recommending {{split}} and show reading each child with
> {{getBody(Exchange.class)}} instead; future batching consumers document the
> same.
> _Claude Code on behalf of Federico Mariani_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
