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.

Reply via email to