Re: [I] Kafka kamelets should use kamelet properties instead of leaking Camel internal headers [camel-kamelets]

["oscerd (via GitHub)" <gi...@apache.org>]

oscerd commented on issue #2871:
URL: https://github.com/apache/camel-kamelets/issues/2871#issuecomment-5678009345

   Most of this has been overtaken by #2868, which landed after this was filed. Checking each proposal against `main` today:
   
   **Done — `timestamp-router-action` no longer forces a Camel-internal header.** 622edd686 added `topicHeaderName`, and `timestampHeaderName` was already there. Both are declared properties, passed to the transform as exchange properties, so the caller names the header instead of being required to use `CamelKafkaTopic`.
   
   **Done — `kafka-sink` does not ask callers for `CamelKafka*`.** The template maps `key` / `ce-key` to `CamelKafkaKey` and `partition-key` / `ce-partitionkey` to `CamelKafkaPartitionKey`. Callers use the friendly names; the internal ones never appear in the contract.
   
   **Done — the test side.** The `kafka.TOPIC` through HTTP leak was dealt with in #2868 (2e373d5d6, 49d30bc75).
   
   **Still open — the source side.** `kafka-source` has no mapping at all: whatever `camel-kafka` puts on the exchange is what downstream sees, so a consumer wanting the topic or key has to read `CamelKafkaTopic` / `CamelKafkaKey`. This is the one item here with nothing done against it.
   
   ## One part I would not implement as written
   
   The proposal is to expose `kafkaTopic` / `kafkaKey` / `kafkaPartition` as **Kamelet properties**. A Kamelet property is bound once, when the template is instantiated, so it cannot carry a value that differs per message — and topic, key and partition are per-message values. Making them properties would either freeze them for the lifetime of the binding or need a placeholder indirection that is harder to use than a header.
   
   The friendly-header mapping that `kafka-sink` already does is, I think, the abstraction this issue is actually reaching for: the caller never touches a `CamelKafka*` name, but the value still varies per message. So the sink side is arguably already finished, just not in the shape described here.
   
   ## Proposed remaining scope
   
   Give `kafka-source` the mirror of what `kafka-sink` does — surface the Kafka metadata as non-internal output headers (`kafka-topic`, `kafka-key`, `kafka-partition`, `kafka-offset`, and a `ce-` CloudEvents counterpart each, which is how this catalog names source output headers). Purely additive: existing consumers reading `CamelKafka*` keep working, and new ones get a name that is not a Camel internal.
   
   That is the same shape as the Ceph extension headers just added in #3030, so there is a recent precedent for the naming.
   
   Picking this up with that reduced scope unless you would rather it stay as filed.
   
   ---
   _Claude Code on behalf of Andrea Cosentino_
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org