Hello,
we tried header in a separate test route project and that only worked with
useList set to true.
Regards,
Marcus Ionker
On 2026/07/21 14:01:54 Marcus Ionker wrote:
> Hello Apache Camel Developers,
>
> I suspect a bug GenericFilePollDynamicAware.resolveStaticUri. I did not find
> an existing Jira ticket in ASF pertaining to this issue.I prepared the
> following ticket, which contains a detailed description of the problem. I
> hope I have not overlooked anything. My current workaround is to set
> allowOptimisedComponents to false. Maybe the problem is related to the fact
> that although the file endpoints (incl. ftp, fps and sftp) support
> expressions in the URI, they are resolved with an empty dummy exchange,
> rather than an actual exchange.
>
> Best Regads,
> Marcus Ionker
>
> ----------------------------
>
> Bug:
>
> GenericFilePollDynamicAware.resolveStaticUri incorrectly returns static URI
> for dynamic fileNameexpressions, breaking PollEnricher optimization
>
> Description:
>
> There is an optimization regression in
> org.apache.camel.component.file.GenericFilePollDynamicAware when used
> alongside pollEnrich.
>
> When a pollEnrich endpoint contains a dynamic simple expression targeting a
> parameter like fileName (e.g., in a File or FTP/SFTP endpoint),
> GenericFilePollDynamicAware.resolveStaticUri fails to return null. Other
> implementations of PollDynamicAwareSupport correctly yield null when a
> component configuration is dynamic. Because it incorrectly evaluates to a
> non-null static URI base, PollEnricher.java falls into an invalid
> optimization block.
>
> Root Cause Analysis:
>
> GenericFilePollDynamicAware.resolveStaticUri is returning the resolved
> dynamic URI instead of null
>
> if (fileName) {
> Map<String, Object> params = entry.getProperties();
> Map<String, Object> originalParams =
> URISupport.parseQuery(URISupport.extractQuery(entry.getOriginalUri()));
> compute(originalParams, PROP_FILE_NAME, params);
> return asEndpointUri(exchange, uri, params);
> } else {
> return uri;
> }
>
> Inside org.apache.camel.processor.PollEnricher.process(), the framework
> attempts to evaluate and optimize the dynamic endpoint.
>
> try {
> recipient = expression.evaluate(exchange, Object.class);
> if (dynamicAware != null) {
> // if its the same scheme as the pre-resolved dynamic aware then we can
> optimise to use it
> String originalUri = uri;
> String uri = resolveUri(exchange, recipient);
> String scheme = resolveScheme(exchange, uri);
> if (dynamicAware.getScheme().equals(scheme)) {
> PollDynamicAware.DynamicAwareEntry entry =
> dynamicAware.prepare(exchange, uri, originalUri);
> if (entry != null) {
> staticUri = dynamicAware.resolveStaticUri(exchange, entry);
> if (staticUri != null) {
> if (LOG.isDebugEnabled()) {
> LOG.debug("Optimising poll via PollDynamicAware component:
> {} to use static uri: {}", scheme,
> URISupport.sanitizeUri(staticUri));
> }
> }
> }
> }
> }
> }...
>
>
> The Breakdown:
>
> - expression.evaluate(...) correctly resolves the dynamic endpoint.
>
> - However, because GenericFilePollDynamicAware.resolveStaticUri provides a
> fallback staticUri string rather than null, PollEnricher assumes it can
> safety optimize the consumer.
>
> - Instead of using the fully evaluated runtime endpoint string (recipient),
> the route erroneously falls back to using the unparsed simple expression
> itself as the literal target.
>
> - The FTP/File consumer subsequently tries to poll using the literal
> expression text, resulting in a lookup failure because the string syntax does
> not match an actual file name on the remote target file system.
>
> Current Workaround:
>
> Configuring the EIP via
> .pollEnrich().simple("...").allowOptimisedComponents(false)bypasses
> PollDynamicAware entirely, forcing Camel to correctly interpret the parsed
> expression string on every exchange.
>
> Expected Fix:
>
> GenericFilePollDynamicAware.resolveStaticUri must return null if the URI is
> dynamic to disable optimization, mirroring standard PollDynamicAwareSupport
> behavior.
