davsclaus opened a new issue, #2871: URL: https://github.com/apache/camel-kamelets/issues/2871
## Summary The Kafka kamelets currently rely on Camel-internal headers (`CamelKafkaTopic`, `CamelKafkaKey`, `CamelKafkaPartition`, `CamelKafkaTimestamp`) being forwarded across transport boundaries (e.g. HTTP → Kafka). This is a design issue: 1. **Header leaking**: Previously, old-style `kafka.TOPIC` / `kafka.KEY` headers could leak through HTTP because they weren't filtered by the HTTP component's `DefaultHeaderFilterStrategy`. With the migration to `CamelKafka*` names, the HTTP component now correctly filters them — but this broke tests that relied on the leak. 2. **Wrong abstraction level**: If a kamelet needs to let users dynamically control the Kafka topic, key, or partition, that should be exposed as a kamelet-level property (e.g. `kafkaTopic`) declared in `spec.definition.properties`, not by requiring the caller to set a Camel-internal header directly. The kamelet template should map the property to the internal header. ## Current behavior - `kafka-sink` expects the caller to set `CamelKafkaKey` / `CamelKafkaPartitionKey` headers directly (or via `key` / `ce-key` CloudEvents headers that the template maps) - `kafka-source` exposes `CamelKafkaTopic` / `CamelKafkaKey` / `CamelKafkaPartition` as outgoing headers that leak to downstream consumers - `timestamp-router-action` and `message-timestamp-router-action` read `CamelKafkaTopic` / `CamelKafkaTimestamp` from the exchange — the caller must set these as Camel-internal headers - Tests relied on `kafka.TOPIC` headers passing through HTTP, which was a leak, not a feature ## Proposed fix - Add kamelet-level properties (e.g. `kafkaTopic`, `kafkaKey`, `kafkaPartition`) to the relevant kamelets - The kamelet template maps these properties to the internal `CamelKafka*` headers - For source kamelets, map `CamelKafka*` headers to non-internal output headers (e.g. `kafka-topic`, `kafka-key`) so downstream consumers can access them without depending on Camel internals - Update tests to use the kamelet properties / non-internal headers - Update the `timestamp-router-action` to accept a kamelet property for the topic instead of reading a Camel-internal header directly This aligns with the kamelet design principle that the template is the trust boundary — callers should interact through declared properties, not by manipulating Camel-internal headers. ## Related - #2869 — optional parameter endpoint creation failure - #2868 — integration test failures (header migration) -- 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]
