allthingssecurity opened a new pull request, #28428: URL: https://github.com/apache/camel/pull/28428
# Description [CAMEL-25904](https://issues.apache.org/jira/browse/CAMEL-25904) `BeanIOSplitter` opened a file body with BeanIO's `StreamFactory.createReader(String, File)`, which uses a `FileReader` and so the default charset of the JVM, and converted any other body to a `Reader` with the charset of the exchange or the default charset. Its `encoding` option was never used. With the usual route for big files, `from("file:in?charset=ISO-8859-1").split(beanIOSplitter).streaming()`, the body is a `File`, so both the file consumer's `charset` and `setEncoding(...)` were ignored: an ISO-8859-1 or windows-1252 file was split with every non-ASCII character replaced by U+FFFD, without an error. CAMEL-12284 fixed the same for `BeanIODataFormat`. Changes: - `BeanIOSplitter.evaluate` decodes a file, stream or byte array body itself, with the charset of the exchange (`CamelCharsetName` header or property, as set by the `charset` option of the file consumer), else with its `encoding` (default: the default charset of the JVM, as before). A `String` or `Reader` body is read as before. Other text (`CharSequence`, such as a `StringBuilder`) is read as text with a `StringReader` (found in review: it went through the byte conversion and was decoded with the `encoding`; on main it failed, as there is no `StringBuilder` to `Reader` converter). - The reader is closed if BeanIO cannot create its reader (an unknown stream name; before, BeanIO checked the stream name before it opened the file), and if reading the first record fails (`BeanIOIterator` reads it in its constructor), so a file is not left open until GC. - Upgrade note in the 4.24 guide. The exchange charset comes first because that is what the file consumer's `charset` sets and what the stream path already used; `BeanIODataFormat` only uses its `encoding`. If you prefer the splitter's `encoding` to win when both are set, it is a one-line change. Tests: - New `BeanIOSplitterEncodingTest` (4 tests, ISO-8859-1 data with ö, ü, é, ß). On main 3 fail with `expected: <[Jörg Müller Développeur, Renée Straße Architect]> but was: <[J�rg M�ller D�veloppeur, Ren�e Stra�e Architect]>`: `fileIsReadWithTheEncodingOfTheSplitter` (a `File` body and `setEncoding(ISO_8859_1)`), `fileFromTheFileConsumerIsReadWithItsCharset` (a file consumer with `charset=ISO-8859-1`) and `bytesAreReadWithTheEncodingOfTheSplitter`. `bytesAreReadWithTheCharsetOfTheExchange` is a control: it passes on main and with the fix. - `textIsReadAsItIs` (a `StringBuilder` body, splitter `encoding` UTF-16BE): on the previous version of this branch (f2c2c27571) it fails with `InvalidRecordException: Invalid 'employee' record at line 1` (the text was encoded with the JVM charset and decoded as UTF-16BE); on main it fails with `No type converter available to convert from type: java.lang.StringBuilder to the required type: java.io.Reader`. - camel-beanio unit tests: 26 run, 0 failures, 0 errors, 0 skipped. What was not run: the full root build. Not changed: `BeanIOIterator` reads the first record in its constructor, before `evaluate` sets the error handler on the reader, so `ignoreInvalidRecords`, `ignoreUnexpectedRecords` and a custom `BeanReaderErrorHandler` do not apply to the first record (an invalid first record fails the split, loudly). I can file a follow-up JIRA for it. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-25904](https://issues.apache.org/jira/browse/CAMEL-25904). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-beanio, including the formatter and import-sort plugins; no generated file changes. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
