[jira] [Created] (CAMEL-23630) camel-dapr - add HeaderFilterStrategy and avoid copying routing-relevant CloudEvent fields into Camel exchange headers

["Andrea Cosentino (Jira)" <ji...@apache.org>]

Andrea Cosentino created CAMEL-23630:
----------------------------------------

             Summary: 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


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)