Hi Can you post an example camel route code that shows this from that point of view.\ And what camel version do you use
On Tue, Jul 21, 2026 at 4:03 PM Marcus Ionker <[email protected]> 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. -- Claus Ibsen
