Claus Ibsen created CAMEL-26004:
-----------------------------------
Summary: 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
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)
