davsclaus opened a new pull request, #28355: URL: https://github.com/apache/camel/pull/28355
Fixes the bugs in 16 data formats found while adding the catalog body types (CAMEL-24961). Several data formats wrote a body they cannot handle as empty or wrong output, or returned a stream that Camel closes when unmarshal returns (since CAMEL-21293). The changes per JIRA: | JIRA | Data format | Fix | |---|---|---| | [CAMEL-25995](https://issues.apache.org/jira/browse/CAMEL-25995) | base64 | Unmarshal decodes into the stream cache, as gzipDeflater does. Before, it returned a `Base64InputStream` over the input stream, so a file body failed with `Stream closed`. | | [CAMEL-25996](https://issues.apache.org/jira/browse/CAMEL-25996) | univocity | With asMap, the iterator keeps the header names from the parsing context. One data row with no final newline gave an NPE, because `processEnded` had cleared the thread-local value. | | [CAMEL-25997](https://issues.apache.org/jira/browse/CAMEL-25997) | bindy | Marshal of a body that is not a model object, a List of them, or a Map of model class names fails with an `InvalidPayloadException`, instead of writing empty lines. bindyFixed takes a Map as a record of class names, as csv and kvp do. | | [CAMEL-25998](https://issues.apache.org/jira/browse/CAMEL-25998) | groovyJson, groovyXml | groovyJson writes a List or other Collection as a JSON array. groovyXml fails with a clear `InvalidPayloadException`, since a List has no root element. | | [CAMEL-25999](https://issues.apache.org/jira/browse/CAMEL-25999) | toon | `byte[]`, streams and files (including a `GenericFile`) are read as JSON text in the exchange charset, as a String is. Before, they gave an array of numbers, nothing, or the file path. | | [CAMEL-26001](https://issues.apache.org/jira/browse/CAMEL-26001) | ical | Marshal uses `mandatoryConvertTo`, so a body that is not a `Calendar` gets a type conversion error instead of an NPE. | | [CAMEL-26002](https://issues.apache.org/jira/browse/CAMEL-26002) | iso8583 | A missing ISO-Type fails with a message that says so. The `configFile` is loaded with the Camel resource loader (`classpath:` by default, `file:`, `http:`) and `ConfigParser.configureFromReader`. A `configFile` that is set but not found fails at startup; the implicit default stays lenient, since marshal works without it. | | [CAMEL-26003](https://issues.apache.org/jira/browse/CAMEL-26003) | flatpack | A single Map is one row, and other bodies fail with an `InvalidPayloadException` (not a `ClassCastException`). The name is `flatpack`, not `flatback`. | | [CAMEL-26004](https://issues.apache.org/jira/browse/CAMEL-26004) | tarFile | Iterator entries are copied into a stream cache, as `ZipIterator` does, so a split that is not streaming gets their content. | | [CAMEL-26005](https://issues.apache.org/jira/browse/CAMEL-26005) | protobufJackson (Jackson 2 and 3) | `JacksonDataFormat` gets a protected `isWriteJsonAsIs()` hook, and the protobuf subclasses return false. JSON text is no longer passed through as `application/protobuf`. | | [CAMEL-26006](https://issues.apache.org/jira/browse/CAMEL-26006) | cbor | `unmarshalType` defaults to `Object`, as Jackson does, so the first example of the docs works, and so does `useList` without a type. | | [CAMEL-26007](https://issues.apache.org/jira/browse/CAMEL-26007) | mimeMultipart | A body that is not a multipart is returned as it was, by overriding `unmarshal(Exchange, Object)`. Before, unmarshal returned the input stream, which was then closed. This works for a variable too. | | [CAMEL-26008](https://issues.apache.org/jira/browse/CAMEL-26008) | zipFile, tarFile | Unmarshal without the iterator skips folder entries, so an archive of a folder with one file works. | | [CAMEL-26009](https://issues.apache.org/jira/browse/CAMEL-26009) | tarFile | Marshal takes the entry size from the body: the length of a `byte[]` or a file, or else the bytes counted while copying into a stream cache. It no longer uses `CamelFileLength` or `available()`. The messages of the tar and zip iterators carry their entry's size in `CamelFileLength`, not the archive's. | | [CAMEL-26010](https://issues.apache.org/jira/browse/CAMEL-26010) | xmlSecurity | The `secureTag` XPath runs on the parsed `Document`, not on the body read again, so a stream that is not cached works. The model defaults now match the code: `secureTagContents` is `true` and `keyCipherAlgorithm` has none. This regenerates the catalog, the XSDs, the YAML DSL and the XML/YAML/Java route dump writers. Behaviour is unchanged. | | [CAMEL-26011](https://issues.apache.org/jira/browse/CAMEL-26011) | barcode | The `barcodeFormat` description says that MAXICODE, RSS_14, RSS_EXPANDED and UPC_EAN_EXTENSION cannot be written by marshal. The enum is kept, since unmarshal reads any of them. | [CAMEL-26000](https://issues.apache.org/jira/browse/CAMEL-26000) (jsonapi collection documents) is a feature and not part of this PR. ## Upgrade guide 4.24 gets a new section, "Data formats - bodies they cannot write fail, and stream bodies". It covers: - the new failures - the flatpack name - the protobufJackson behaviour - the tarFile sizes and `CamelFileLength` - the folder entries, including that an archive with only folder entries now fails - iso8583 `configFile` loading - the xmlSecurity catalog defaults ## Tests Every module has new unit tests, and each of them failed before its fix. All modules pass: | Module | Tests | |---|---| | base64 | 21 | | mail | 255 | | ical | 5 | | univocity | 127 | | bindy | 260 | | flatpack | 45 | | groovy | 123 | | toon | 27 | | cbor | 12 | | jackson | 106 | | jackson3 | 116 | | jackson-protobuf | 26 | | jackson3-protobuf | 25 | | iso8583 | 10 | | xmlsecurity | 201 | | barcode | 40 | | tarfile | 55 | | zipfile | 59 | _Claude Code on behalf of davsclaus_ 🤖 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]
