oscerd opened a new pull request, #2978: URL: https://github.com/apache/camel-kamelets/pull/2978
Partially addresses #2973 — the tier-3 slice (templates that deliberately consume *one* header from their component's family and pass the rest through). HTTP is #2976, SQL/CQL is #2977. Broker sinks remain, and per the corrected reachability note in the issue they are the lowest-value part. | Kamelet | kept (documented interface) | stripped | |---|---|---| | `exec-sink` | `args` / `ce-args` → `CamelExecCommandArgs` | `CamelExecCommandExecutable`, `CamelExecCommandWorkingDir`, `CamelExecCommandOutFile` | | `kafka-sink` | `key` / `ce-key`, `partition-key` / `ce-partitionkey` | `CamelKafkaOverrideTopic`, `CamelKafkaOverrideTimestamp` | | `aws-ec2-sink` | `instanceIds` / `ce-instanceids` | `CamelAwsEC2Operation` | Each keeps the header the template maps and the docs advertise, and drops the ones it never asked for. `aws-ec2-sink` is the clearest shape: it pins `operation: describeInstancesStatus` — a read-only call — while deliberately letting the sender name instances. Each strip carries a comment saying which headers are the contract, so the distinction survives future edits. ## Please read the exec-sink half sceptically The original report treated `CamelExecCommandExecutable` as an open door. **I could not reproduce that.** On Camel 4.21, tested both ways: | endpoint | header set | command that actually ran | |---|---|---| | `exec:hostname` | `whoami` | `hostname` | | `exec:whoami` | `hostname` | `whoami` | The header also survived the call unconsumed. `camel-exec` reads it via `getAndRemoveHeader`, so it was never looked at — while the component catalog documents it as *"Overrides executable in the URI."* That is either a `camel-exec` documentation/behaviour mismatch worth raising upstream, or a 4.21-vs-4.22 difference (I tested with the 4.21 JBang CLI against 4.22 catalog metadata). Someone who knows `camel-exec` should confirm on 4.22. The strip is harmless either way and I have kept it as cheap insurance, but I did not want it merged under a claim I could not stand behind. `CamelKafkaOverrideTopic` and `CamelAwsEC2Operation` are **not** verified end-to-end either — both need a live broker / AWS account. They are documented as overriding, and unlike the exec case I have no evidence against that, but treat them as documentation-based rather than demonstrated. The HTTP (#2976) and SQL (#2977) slices are the two I proved end-to-end. ## Framing Defence in depth, not an open hole. Every header here is `Camel`-prefixed and so subject to source-side ingest filtering — see the corrected *Reachability* section of #2973. ## Verification - `script/validator` reports no errors - `mvn verify` passes - exec override behaviour probed with `camel run` as tabulated; kafka and EC2 not exercised against live endpoints --- _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]
