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.