[jira] [Created] (CAMEL-24464) camel-exec ignores its documented CamelExecCommand* headers (executable and args have no effect)

["Andrea Cosentino (Jira)" <ji...@apache.org>]

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)