shashank created CAMEL-25531:
--------------------------------
Summary: 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
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)
