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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
