[
https://issues.apache.org/jira/browse/CAMEL-25810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-25810:
-------------------------------------
Description:
CAMEL-24282 moved property-placeholder resolution for the dynamic-URI EIPs from
every message to build time. Its description covered toD, recipientList,
routingSlip, dynamicRouter, enrich and pollEnrich, but the change landed in
SendDynamicProcessor only, which serves toD, enrich and wireTap. CAMEL-24414
then did the same for the endpoint that pollEnrich resolves. Two paths still
resolve property placeholders on the recipient evaluated for each message:
# recipientList, routingSlip and dynamicRouter prepare each evaluated recipient
with ProcessorHelper.prepareRecipient(), which calls
CamelContextExtension.normalizeUri().
DefaultCamelContextExtension.normalizeUri() resolves property placeholders
(EndpointHelper.resolveEndpointUriPropertyPlaceholders) before normalizing.
# pollEnrich, when the target scheme has a PollDynamicAware (file, ftp, ftps,
sftp, smb, azure-files), computes the URI for the poll-dynamic optimisation
with PollEnricher.resolveUri(). That method still resolves property
placeholders on the evaluated recipient, and the result is passed to
PollDynamicAware.prepare() and can become the static URI that is polled.
Proposed change:
- ProcessorHelper.prepareRecipient(): normalize with
NormalizedUri.newNormalizedUri(uri, false), the variant SendDynamicProcessor
and PollEnricher.prepareRecipient() already use, instead of normalizeUri().
- PollEnricher.resolveUri(): drop the per-message
EndpointHelper.resolveEndpointUriPropertyPlaceholders() call, as CAMEL-24282
did for SendDynamicProcessor.
- Placeholders written in the route keep working: the expression text of these
EIPs is resolved when the route is built (ExpressionReifier.createExpression ->
parseString), as are the static pollEnrich URI and the
routingSlip/dynamicRouter uriDelimiter.
- Upgrade guide (4.24): a property-placeholder token that only appears at
runtime in the evaluated recipient, for example one that came from a message
header, is now kept as a literal part of the endpoint URI instead of being
expanded. Same wording as the 4.22 note for toD and enrich.
- Tests, per EIP: a recipient taken from a header that contains a
property-placeholder token is used literally; a placeholder written in the
route's expression is still resolved.
_Filed by Claude Code on behalf of Andrea Cosentino._
was:
CAMEL-24282 moved property-placeholder resolution for the dynamic-URI EIPs from
every message to build time. Its description covered toD, recipientList,
routingSlip, dynamicRouter, enrich and pollEnrich, but the change landed in
SendDynamicProcessor only, which serves toD, enrich and wireTap. CAMEL-24414
then did the same for the endpoint that pollEnrich resolves. Two paths still
resolve property placeholders on the recipient evaluated for each message:
# recipientList, routingSlip and dynamicRouter prepare each evaluated recipient
with ProcessorHelper.prepareRecipient(), which calls
CamelContextExtension.normalizeUri().
DefaultCamelContextExtension.normalizeUri() resolves property placeholders
(EndpointHelper.resolveEndpointUriPropertyPlaceholders) before normalizing.
# pollEnrich, when the target scheme has a PollDynamicAware (file, ftp, ftps,
sftp, smb, azure-files), computes the URI for the poll-dynamic optimisation
with PollEnricher.resolveUri(). That method still resolves property
placeholders on the evaluated recipient, and the result is passed to
PollDynamicAware.prepare() and can become the static URI that is polled.
Proposed change:
- ProcessorHelper.prepareRecipient(): normalize with
NormalizedUri.newNormalizedUri(uri, false), the variant SendDynamicProcessor
and PollEnricher.prepareRecipient() already use, instead of normalizeUri().
- PollEnricher.resolveUri(): drop the per-message
EndpointHelper.resolveEndpointUriPropertyPlaceholders() call, as CAMEL-24282
did for SendDynamicProcessor.
- Placeholders written in the route keep working: the expression text of these
EIPs is resolved when the route is built (ExpressionReifier.createExpression ->
parseString), as are the static pollEnrich URI and the
routingSlip/dynamicRouter uriDelimiter.
- Upgrade guide (4.24): a \{\{...\}\} token that only appears at runtime in the
evaluated recipient, for example one that came from a message header, is now
kept as a literal part of the endpoint URI instead of being expanded. Same
wording as the 4.22 note for toD and enrich.
- Tests, per EIP: a recipient taken from a header that contains a \{\{...\}\}
token is used literally; a placeholder written in the route's expression is
still resolved.
_Filed by Claude Code on behalf of Andrea Cosentino._
> camel-core - recipientList, routingSlip, dynamicRouter and pollEnrich:
> resolve dynamic-URI property placeholders at build time, matching toD and
> enrich
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25810
> URL: https://issues.apache.org/jira/browse/CAMEL-25810
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Minor
> Fix For: 4.24.0
>
>
> CAMEL-24282 moved property-placeholder resolution for the dynamic-URI EIPs
> from every message to build time. Its description covered toD, recipientList,
> routingSlip, dynamicRouter, enrich and pollEnrich, but the change landed in
> SendDynamicProcessor only, which serves toD, enrich and wireTap. CAMEL-24414
> then did the same for the endpoint that pollEnrich resolves. Two paths still
> resolve property placeholders on the recipient evaluated for each message:
> # recipientList, routingSlip and dynamicRouter prepare each evaluated
> recipient with ProcessorHelper.prepareRecipient(), which calls
> CamelContextExtension.normalizeUri().
> DefaultCamelContextExtension.normalizeUri() resolves property placeholders
> (EndpointHelper.resolveEndpointUriPropertyPlaceholders) before normalizing.
> # pollEnrich, when the target scheme has a PollDynamicAware (file, ftp, ftps,
> sftp, smb, azure-files), computes the URI for the poll-dynamic optimisation
> with PollEnricher.resolveUri(). That method still resolves property
> placeholders on the evaluated recipient, and the result is passed to
> PollDynamicAware.prepare() and can become the static URI that is polled.
> Proposed change:
> - ProcessorHelper.prepareRecipient(): normalize with
> NormalizedUri.newNormalizedUri(uri, false), the variant SendDynamicProcessor
> and PollEnricher.prepareRecipient() already use, instead of normalizeUri().
> - PollEnricher.resolveUri(): drop the per-message
> EndpointHelper.resolveEndpointUriPropertyPlaceholders() call, as CAMEL-24282
> did for SendDynamicProcessor.
> - Placeholders written in the route keep working: the expression text of
> these EIPs is resolved when the route is built
> (ExpressionReifier.createExpression -> parseString), as are the static
> pollEnrich URI and the routingSlip/dynamicRouter uriDelimiter.
> - Upgrade guide (4.24): a property-placeholder token that only appears at
> runtime in the evaluated recipient, for example one that came from a message
> header, is now kept as a literal part of the endpoint URI instead of being
> expanded. Same wording as the 4.22 note for toD and enrich.
> - Tests, per EIP: a recipient taken from a header that contains a
> property-placeholder token is used literally; a placeholder written in the
> route's expression is still resolved.
> _Filed by Claude Code on behalf of Andrea Cosentino._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
