[
https://issues.apache.org/jira/browse/CAMEL-24414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106764#comment-18106764
]
Andrea Cosentino commented on CAMEL-24414:
------------------------------------------
*Scope reduced.* The first revision of the patch changed the shared
ProcessorHelper.prepareRecipient, which covered recipientList, routingSlip,
dynamicRouter and pollEnrich in one go. CI rejected it: camel-ftp
FtpProducerRecipientListIT sends
{noformat}
ftp://admin@localhost:{{ftp.server.port}}/list?password=admin&fileName=hello.txt
{noformat}
into a recipientList header with the placeholder *unresolved*, and relies on
the per-message resolution to expand it. The recipient is supplied at runtime
but the placeholder comes from configuration, not from an untrusted sender - a
legitimate pattern with an in-tree user.
The 4.22 upgrade guide justified excluding those three EIPs by saying they have
no static template resolved at build time. That reason is not accurate - a
placeholder written in the route (for example
recipientList(constant("mock:{{target}}"))) is resolved at build time by the
model regardless, and there is now a test recording that. But the conclusion
was right for a different reason, so the exclusion stands.
This issue is therefore narrowed to *pollEnrich only*, which is the alignment
the 4.22 guide explicitly deferred to a follow-up. PollEnricher overrides
prepareRecipient with the same build-time behaviour SendDynamicProcessor uses;
the shared helper is untouched and recipientList/routingSlip/dynamicRouter keep
their current behaviour.
*Follow-up worth a dev-list thread, not a unilateral change*: should
recipientList, routingSlip and dynamicRouter continue to expand placeholders in
a runtime recipient? The engine cannot tell an operator config template from a
sender-supplied token arriving in a header. There is a real argument for
aligning them, and FtpProducerRecipientListIT is the concrete migration cost.
> camel-core - resolve pollEnrich property placeholders at build time
> -------------------------------------------------------------------
>
> Key: CAMEL-24414
> URL: https://issues.apache.org/jira/browse/CAMEL-24414
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> CAMEL-24282 changed toD and enrich so that {{...}} property placeholders are
> resolved once at build time instead of being re-expanded per message on the
> evaluated recipient, matching the documented contract that placeholder
> resolution operates on route and configuration text. That change explicitly
> left the other dynamic-URI EIPs alone - its commit message states
> "recipientList/routingSlip/dynamicRouter/pollEnrich are unchanged".
> Those EIPs still call ProcessorHelper.prepareRecipient():
> * RecipientListProcessor.java:260
> * RoutingSlip.java:265 (synchronous path) and RoutingSlip.java:469
> (asynchronous continuation path - both need the change)
> * PollEnricher.java:305
> ProcessorHelper.prepareRecipient() ends in
> ecc.getCamelContextExtension().normalizeUri(uri), and
> DefaultCamelContextExtension.normalizeUri() calls
> EndpointHelper.resolveEndpointUriPropertyPlaceholders() - so a {{...}} token
> that only appears in the per-message recipient value is still expanded.
> SendDynamicProcessor already carries its own overridden prepareRecipient()
> with the build-time behaviour (the CAMEL-24282 fix). This issue is to give
> the remaining four EIPs the same treatment so the whole dynamic-URI family
> behaves consistently.
> Note the allowedSchemes allow-list added in CAMEL-24298 is opt-in and
> orthogonal - it constrains the scheme, not placeholder expansion.
> Behaviour change, so main only, with an upgrade-guide entry mirroring the
> CAMEL-24282 one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
