davsclaus opened a new pull request, #28087: URL: https://github.com/apache/camel/pull/28087
[CAMEL-25792](https://issues.apache.org/jira/browse/CAMEL-25792): `poll` and `pollEnrich` with a file based component evaluated a dynamic `fileName` for each file found, on an exchange whose body is that file. So `fileName=${body}` or `fileName=${body[customer]}.json` did not read the message being enriched, though the docs say dynamic uris are "computed based on information from the current Exchange": - `${body}` gave the path of each file found, so no file matched and the poll timed out. - `${body[customer]}` failed on the `java.io.File`, for every file on every poll: "Key: customer not found in bean: .../customers/C-482.json of type: java.io.File". Headers, variables and exchange properties worked, as they are copied to that exchange. In a benchmark of Oct 18-19 2026, a local model wrote `${body[customer]}` in all 8 runs of an enrich-and-dedupe example, and failed on it each time. ## What The rule (agreed with Claus): a `fileName` that uses the file functions reads the file found; any other reads the current message. - **`GenericFileEndpoint.setFileName(String)`** records whether the expression uses the file functions (`${file:...}`, `${date:file:...}`, also as `$simple{...}`). An `Expression` object keeps today's behaviour, as what it reads is unknown. - **`GenericFileConsumer`**: when `poll` or `pollEnrich` polls for a message (`poll(Exchange dynamic)`), a `fileName` without the file functions is evaluated once for that poll on a copy of the message: its body, headers, variables and exchange properties, without the file found. A `fileName` with the file functions is evaluated for each file found, as before. A plain route consumer is unchanged. - **Endpoint reuse (CAMEL-21733) stays**: the static uri still carries the unevaluated `fileName`. - **Scope**: the code is shared, so this covers file, ftp, ftps, sftp, smb and azure-files, the file based components with a poll dynamic aware. camel-mina-sftp extends camel-file too but has no poll dynamic aware: its poll and pollEnrich evaluate the whole uri on the message, with an endpoint for each file name. That is not changed here. - **Docs**: the poll and pollEnrich pages get a section on the file name of a dynamic uri, with an example in Java, XML and YAML (validated). The pollEnrich example reads the customer of an order into a variable with `variableReceive`. - **Upgrade guide**: `${body}` in such a `fileName` is now the incoming body. A `fileName` that read the file found through its headers, such as `${header.CamelFileName}`, must use the file functions (`${file:name}`). ## Tests - New `PollDynamicFileNameBodyTest` (camel-core): `${body}` and `${body[customer]}.json` now read the message, `${variable.target}` still works, `${file:onlyname.noext}.txt` still matches per file found, and one file endpoint is reused. - Without the fix, the two body tests fail; the variable and file function tests pass. - `PollDynamicFileNameTest` of camel-ftp (embedded FTP server) gets a `${body}` test, which passes. - 191 poll and pollEnrich tests of camel-core pass, and the 28 tests of camel-file. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01STT6whBgK1AqsSsUKrnE8m -- 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]
