[
https://issues.apache.org/jira/browse/CAMEL-26004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130937#comment-18130937
]
Claus Ibsen commented on CAMEL-26004:
-------------------------------------
Fix in PR https://github.com/apache/camel/pull/28355 (one PR for the 16 data
format tickets CAMEL-25995 to CAMEL-26011, except CAMEL-26000). The PR
description lists the change per ticket.
_Claude Code on behalf of davsclaus_
> camel-tarfile - with usingIterator, a split that is not streaming gives every
> entry an empty body
> -------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26004
> URL: https://issues.apache.org/jira/browse/CAMEL-26004
> Project: Camel
> Issue Type: Bug
> Components: camel-tarfile
> Affects Versions: 4.18.0, 4.22.0, 4.23.0
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> With {{usingIterator=true}}, the tarFile data format returns a
> {{TarIterator}} whose messages stream their entry from the one
> {{TarArchiveInputStream}} of the archive ({{TarIterator}}, main 56aa5f4970a6,
> lines 142-151). A body must therefore be read before the next entry is taken.
> A split that is not streaming, the default of the split EIP, takes all the
> elements of the iterator first and processes the messages after, when the tar
> stream is at its end. So every entry has an empty body, with no error.
> The zipFile data format does not have the problem: its iterator copies each
> entry into a stream cache. The tarFile docs only show {{.streaming()}} in the
> examples and warn about parallel mode.
> Checked on 4.24.0-SNAPSHOT with {{camel run}}, with a tar of one 52-byte file
> (made by marshal tarFile, and by {{tar --format ustar}}):
> * {{unmarshal: tarFile: usingIterator: true}}, then {{split: simple:
> ${body}}}: one message, CamelTarFileEntryName plain.txt, body length 0;
> * the same with {{streaming: true}}: body length 52, the content of the file;
> * zipFile with the same split, not streaming: the content of the file.
> *Proposed change*: copy each entry into a stream cache, as ZipIterator does,
> so the split works in both modes.
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
