Andrea Cosentino created CAMEL-24464:
----------------------------------------
Summary: camel-exec ignores its documented CamelExecCommand*
headers (executable and args have no effect)
Key: CAMEL-24464
URL: https://issues.apache.org/jira/browse/CAMEL-24464
Project: Camel
Issue Type: Bug
Components: camel-exec
Reporter: Andrea Cosentino
h3. Summary
{{camel-exec}} does not honour any of its documented {{CamelExecCommand*}}
in-headers. The component reads its configuration only from the endpoint URI.
The component documentation states the opposite.
h3. Documented behaviour
>From the component catalog metadata (4.22.0):
* {{CamelExecCommandExecutable}} — "The name of the system command that will be
executed. *Overrides executable in the URI.*"
* {{CamelExecCommandArgs}} — "Command-line argument(s) to pass to the executed
process ... *Overrides any existing args in the URI.*"
h3. Observed behaviour on 4.22.0
*Arguments* — identical route shape in both cases, only the mechanism differs:
|| how the argument is passed || stdout || header after the call ||
| {{exec:echo?args=URIARGS-WORK}} (URI parameter) | {{URIARGS-WORK}} | n/a |
| {{CamelExecCommandArgs}} header, {{exec:echo}} | _(empty)_ | still present,
unconsumed |
*Executable* — tested in both directions so neither result can be a coincidence
of which binary was picked:
|| endpoint || {{CamelExecCommandExecutable}} || command that actually ran ||
| {{exec:hostname}} | {{whoami}} | {{hostname}} |
| {{exec:whoami}} | {{hostname}} | {{whoami}} |
In every header case the header was still on the message after the call.
{{camel-exec}} reads its command headers with {{getAndRemoveHeader}}, so a
header that survives was never read.
h3. Reproducer
{code:yaml}
- route:
from:
uri: "timer:a"
parameters: {repeatCount: 1}
steps:
- setHeader: {name: CamelExecCommandArgs, constant: "ARGS-WORK"}
- to: "exec:echo"
- log: "hdrAfter=[${header.CamelExecCommandArgs}]"
- setBody: {simple: "${body.stdout}"}
- convertBodyTo: {type: "java.lang.String"}
- log: "OUT=[${body.trim()}]"
{code}
Run with {{camel run <file>.yaml --camel-version=4.22.0}}. Observed:
{{hdrAfter=[ARGS-WORK]}} and {{OUT=[]}}. Expected per the documentation:
{{OUT=[ARGS-WORK]}} and the header consumed.
Replacing the header with {{exec:echo?args=ARGS-WORK}} prints
{{OUT=[ARGS-WORK]}}, which is the control showing the harness is sound.
h3. Impact
Either the behaviour or the documentation is wrong, and it matters which:
* If the headers are meant to work, this is a functional regression in
{{camel-exec}} and the header-based interface is unusable.
* If URI-only is intended, the catalog metadata for all {{group: in}}
{{CamelExecCommand*}} headers is misleading and should be corrected, since it
is what downstream projects build against.
Concretely downstream: the {{exec-sink}} Kamelet in {{apache/camel-kamelets}}
documents an {{args}} / {{ce-args}} input header and implements it by setting
{{CamelExecCommandArgs}}. That interface therefore has no effect today. Filed
there as apache/camel-kamelets#2980, which is blocked on the answer here.
h3. Notes
Reproduced on Camel 4.22.0 and on the 4.21.0-SNAPSHOT JBang CLI, on Linux.
----
_Reported via Claude Code on behalf of Andrea Cosentino_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
