allthingssecurity opened a new pull request, #28034: URL: https://github.com/apache/camel/pull/28034
# Description [CAMEL-25726](https://issues.apache.org/jira/browse/CAMEL-25726) The Azure Files producer creates the remote file with its final size, then writes the body. Whenever a `CamelFileLength` header was set, its value was used as the size, whatever the body was. File-family consumers set that header to the length of the consumed file, and it stays on the message when the route changes the body (split, transform, marshal). So `from("file:in").split(...).to("azure-files:...")` stored each part as a file of the original file's size: the part, then zero bytes up to that size. The exchange completed normally. A body longer than the header fails at the write past the end of the file (read, not run against Azure). The header value was also narrowed with `intValue()`. CAMEL-25167 made the same choice for the other file and object-storage producers: `PayloadHelper.getBodyLength` does not use `CamelFileLength`, because it can be stale once the route changed the body. Change (in `FilesOperations.storeFile`): - the size is the length of the body when it is known without reading it (`PayloadHelper.getBodyLength`: a file or wrapped file, `byte[]`, a cached stream, a byte-array or file stream); - a body that is not a stream (for example a `String`) is converted to `byte[]`, as before when there was no header; - `CamelFileLength` is only used for a stream whose length is not known otherwise, which is the documented streaming case; - the size is passed as a `long`. What users can notice: a file is created with the size of its body even when a stale `CamelFileLength` header is on the message. Upgrade guide (4.24): a note under `camel-azure-files`. The component page says when the header is used. Tests: - New `FilesOperationsStoreLengthTest` (3 tests, mocked share directory and file clients, no Azure service): - `bodyShorterThanTheFileLengthHeader` (3-byte body, header 10) and `stringBodyLongerThanTheFileLengthHeader` (20 characters, header 10) fail without the change: the file is created with 10 bytes (`expected: <3> but was: <10>`, `expected: <20> but was: <10>`, 3 of 3 runs). - `streamOfUnknownLengthUsesTheFileLengthHeader` passes with and without the change. It guards the documented streaming case, which the change could break. - With the change the camel-azure-files tests pass: 31 run, 0 failures, 0 errors, 0 skipped. - `mockito-core` added as a test dependency of the module. What is not changed (possible follow-up): `storeFileDirectly` uses the platform charset. What was not run: the full root build; no test against an Azure storage account. # 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-25726](https://issues.apache.org/jira/browse/CAMEL-25726). # 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-azure-files, including the formatter and import-sort plugins, and updated the catalog copy of the component page. 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]
