[
https://issues.apache.org/jira/browse/CAMEL-24464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Omar Atie reassigned CAMEL-24464:
---------------------------------
Assignee: Omar Atie
> 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
> Assignee: Omar Atie
> Priority: Major
>
> 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)
