[
https://issues.apache.org/jira/browse/CAMEL-23630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino resolved CAMEL-23630.
--------------------------------------
Resolution: Fixed
Fixed via the following pull requests:
* main (4.21.0): https://github.com/apache/camel/pull/23886
* camel-4.18.x backport (4.18.3, in review):
https://github.com/apache/camel/pull/23889
* 4.18 upgrade-guide doc-sync to main (in review):
https://github.com/apache/camel/pull/23891
_Comment by Claude Code on behalf of Andrea Cosentino._
> camel-dapr - add HeaderFilterStrategy and avoid copying routing-relevant
> CloudEvent fields into Camel exchange headers
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-23630
> URL: https://issues.apache.org/jira/browse/CAMEL-23630
> Project: Camel
> Issue Type: Improvement
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.18.3, 4.21.0
>
>
> camel-dapr does not currently ship a HeaderFilterStrategy. Sibling messaging
> components such as camel-iggy (IggyHeaderFilterStrategy), camel-kafka
> (KafkaHeaderFilterStrategy), and camel-jms (JmsHeaderFilterStrategy) all
> provide one to keep external message metadata from colliding with the
> component's own "Camel*"-prefixed configuration headers.
> Today, DaprPubSubConsumer.createServiceBusExchange(CloudEvent) copies several
> CloudEvent fields directly into the exchange as headers:
> {code}
> cloudEvent.getPubsubName() -> DaprConstants.PUBSUB_NAME
> ("CamelDaprPubSubName")
> cloudEvent.getTopic() -> DaprConstants.TOPIC
> ("CamelDaprTopic")
> cloudEvent.getId() -> DaprConstants.ID
> cloudEvent.getSource() -> DaprConstants.SOURCE
> cloudEvent.getType() -> DaprConstants.TYPE
> cloudEvent.getSpecversion() -> DaprConstants.SPECIFIC_VERSION
> cloudEvent.getDatacontenttype() -> DaprConstants.DATA_CONTENT_TYPE
> cloudEvent.getBinaryData() -> DaprConstants.BINARY_DATA
> cloudEvent.getTime() -> DaprConstants.TIME
> cloudEvent.getTraceParent() -> DaprConstants.TRACE_PARENT
> cloudEvent.getTraceState() -> DaprConstants.TRACE_STATE
> {code}
> Two of these headers (CamelDaprPubSubName and CamelDaprTopic) are also read
> on the producer side by DaprConfigurationOptionsProxy.getPubSubName /
> getTopic via the getOption(...) helper, which prefers header values over the
> endpoint-configured destination. As a result, a route such as
> {code}
> from("dapr-pubsub:configured-pubsub:configured-topic")
> .to("dapr-pubsub:configured-pubsub:another-topic");
> {code}
> will carry the inbound CloudEvent's pubsubName / topic into the producer hop
> instead of using the configured destination.
> Proposed change (mirrors the camel-iggy pattern):
> # Add a DaprHeaderFilterStrategy extending DefaultHeaderFilterStrategy with
> in/out filters on the "Camel" / "camel" prefix (lowerCase=true, in/out
> FilterStartsWith = DefaultHeaderFilterStrategy.CAMEL_FILTER_STARTS_WITH).
> # Expose it via DaprComponent / DaprEndpoint as the standard
> headerFilterStrategy URI option, default-instantiated to the new class.
> # In DaprPubSubConsumer.createServiceBusExchange(...), either (a) consult the
> configured HeaderFilterStrategy before setting each header, or (b) stop
> copying PUBSUB_NAME and TOPIC from the inbound CloudEvent, since those
> constants are documented as producer-direction routing headers rather than
> consumer-direction metadata.
> This brings camel-dapr into consistency with the rest of the messaging
> component family and removes the consumer-to-producer header carry-over for
> routing-relevant fields.
> Reference implementation:
> components/camel-iggy/src/main/java/org/apache/camel/component/iggy/IggyHeaderFilterStrategy.java
> Affects: camel-dapr 4.12.0 through 4.20.0 and current main.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
