[jira] [Resolved] (CAMEL-25531) camel-wasm - Run WASI Preview 1 command modules instead of the custom alloc/dealloc ABI

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-25531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-25531.
---------------------------------
    Resolution: Fixed

Fixed by https://github.com/apache/camel/pull/27678 (merged to main as 2e7febe42485, 4.24.0).

_Claude Code on behalf of Claus Ibsen_

> camel-wasm - Run WASI Preview 1 command modules instead of the custom alloc/dealloc ABI
> ---------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25531
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25531
>             Project: Camel
>          Issue Type: Improvement
>            Reporter: shashank
>            Assignee: shashank
>            Priority: Major
>             Fix For: 4.24.0
>
>
> The {{wasm}} endpoint only runs modules that export Camel's own ABI: {{alloc}}/{{dealloc}} functions, a JSON envelope of the headers and a base64 body written into guest memory, and a 64-bit pointer/length result with an error bit. No existing program works without a wrapper written for that ABI, and nothing that imports WASI even links, so an ordinary Rust ({{wasm32-wasip1}}) or Go ({{GOOS=wasip1 GOARCH=wasm}}) program cannot be used. The endpoint also has no configurable memory cap or invocation timeout, and one instance per producer is shared by every exchange under a lock.
> camel-wasm is Experimental and the custom ABI is not really used, so, as agreed on the Camel Zulip with Claus Ibsen, the endpoint moves to the model every WASI toolchain already targets: a WASI Preview 1 command module that reads standard input and writes standard output, run in the JVM on Endive. The custom ABI is dropped from the endpoint, with a short upgrade-guide note.
> h3. Agreed design
> * Endpoint: the path is the module itself, for example {{wasm:classpath:upper.wasm}} (a command module has no function name).
> * The message body is standard input, standard output becomes the new body; the exit code and standard error are in the {{CamelWasmExitCode}} and {{CamelWasmStderr}} headers.
> * {{failOnNonZeroExit=true}} by default.
> * A fresh instance per exchange: the module is parsed (and, later, compiled) once, then instantiated for every exchange.
> * Environment only from the route ({{environment.X=...}}) plus an explicit allow-list of header names ({{environmentHeaders=...}}), not a {{HeaderFilterStrategy}}. No other header reaches the module.
> * Fixed arguments from the route; no preopened directories, no sockets.
> * Limits: {{maxMemoryPages}}, a timeout, and a cap on the buffered standard output and error.
> * Runtime compiler: opt-in ({{compile=true}}), off by default, because a runtime ASM compiler is a problem for native images; document the Endive build-time compiler plugin as the alternative.
> * The {{wasm}} language: rebase it on the same WASI runner, or drop it.
> * Dependencies: align the Endive version in one place (camel-wasm uses 1.1.0, quickjs4j 0.1.0 pulls 1.0.0, opa-java-wasm 1.1.0 pulls 1.0.0).
> Security model: modules stay trusted route code, chosen by the route author like a processor or a bean (see the security model page). The limits are robustness controls, not a sandbox: they keep a misbehaving module from turning one message into unbounded memory, time or threads, and they are not a defence against a module written to attack the host. Message bodies and headers stay untrusted data: the body only reaches the module as standard input, and headers only through the allow-list.
> h3. Plan (small pull requests under this ticket)
> # WASI runner, endpoint and limits replacing the custom ABI, with docs and the upgrade-guide note.
> # Optional runtime compiler ({{compile=true}}, off by default) and docs for the build-time compiler plugin; Endive version alignment in the parent POM.
> # The {{wasm}} language: rebase it on the WASI runner, or drop it.
> # Rust and Go examples in camel-examples, with a timing for a standard Go program (large {{wasip1}} binaries, a fresh interpreted instance per exchange).
> Duplicate check (2026-10-10): JIRA text "WASI" or summary "wasm" (8 hits: CAMEL-25455, CAMEL-25456, CAMEL-24059, CAMEL-21569 for camel-wasm, all resolved bug fixes or upgrades, and 4 camel-opa WASM-mode tickets); GitHub pull requests "wasi" and "camel-wasm": none about WASI support in camel-wasm, no open pull request touches camel-wasm.
> _Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v8.20.10#820010)