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:
-
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.
-
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 consumerstimestamp-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
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:Header leaking: Previously, old-style
kafka.TOPIC/kafka.KEYheaders could leak through HTTP because they weren't filtered by the HTTP component'sDefaultHeaderFilterStrategy. With the migration toCamelKafka*names, the HTTP component now correctly filters them — but this broke tests that relied on the leak.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 inspec.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-sinkexpects the caller to setCamelKafkaKey/CamelKafkaPartitionKeyheaders directly (or viakey/ce-keyCloudEvents headers that the template maps)kafka-sourceexposesCamelKafkaTopic/CamelKafkaKey/CamelKafkaPartitionas outgoing headers that leak to downstream consumerstimestamp-router-actionandmessage-timestamp-router-actionreadCamelKafkaTopic/CamelKafkaTimestampfrom the exchange — the caller must set these as Camel-internal headerskafka.TOPICheaders passing through HTTP, which was a leak, not a featureProposed fix
kafkaTopic,kafkaKey,kafkaPartition) to the relevant kameletsCamelKafka*headersCamelKafka*headers to non-internal output headers (e.g.kafka-topic,kafka-key) so downstream consumers can access them without depending on Camel internalstimestamp-router-actionto accept a kamelet property for the topic instead of reading a Camel-internal header directlyThis 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