[jira] [Created] (CAMEL-24467) Scripting languages (JS, MVEL, OGNL, python/python3) do not bind Exchange variables and hand-roll bindings instead of reusing ExchangeHelper.populateVariableMap

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

Claus Ibsen created CAMEL-24467:
-----------------------------------

             Summary: Scripting languages (JS, MVEL, OGNL, python/python3) do not bind Exchange variables and hand-roll bindings instead of reusing ExchangeHelper.populateVariableMap
                 Key: CAMEL-24467
                 URL: https://issues.apache.org/jira/browse/CAMEL-24467
             Project: Camel
          Issue Type: Improvement
          Components: camel-core
            Reporter: Claus Ibsen


Camel's scripting-language expressions bind Exchange data (body, headers, properties, exchangeId, exchange, message, context) into the script's variable scope, but each language implements this independently instead of sharing common code, and only one of them exposes Exchange *variables* (exchange.getVariables()/getVariable()).

Findings from a review of PR #25551 (CAMEL-24337, camel-python3):

* core/camel-support/src/main/java/org/apache/camel/support/ExchangeHelper.java has a shared populateVariableMap(Exchange, Map, boolean) helper that binds a common set of names including "variable"/"variables". It is used by camel-groovy (GroovyExpression.createBinding) and several templating engines (Freemarker, Velocity, Mustache, etc.), but NOT by the other scripting languages.
* camel-javascript (JavaScriptExpression), camel-mvel/camel-ognl (RootObject), and the legacy Jython-based camel-python (PythonExpression) each hand-roll their own bindings: exchange, context, exchangeId, message, headers, properties, body — with no "variables" binding at all.
* The new camel-python3 (GraalPy-based) language added in CAMEL-24337 follows this same hand-rolled JS/old-python pattern (body, headers, properties, exchangeId, plus exchange/message/context only in trusted mode) — consistent with its closest sibling, but it means Exchange variables remain inaccessible from python3, js, mvel, and ognl scripts without dropping into host object method calls (e.g. exchange.getVariable(...) where host access is allowed at all).

This was previously attempted in CAMEL-5954 ("Unify the variables which are exports to script", resolved 2013) but the languages have since diverged again, and Exchange variables (a newer Camel concept, introduced after 2013) were never retrofitted.

Proposed direction (open for discussion, not prescriptive):
* Evaluate whether JS, MVEL, OGNL, camel-python, and camel-python3 can reuse ExchangeHelper.populateVariableMap (or a shared subset of it) instead of duplicating the binding logic in each language.
* At minimum, expose Exchange variables ("variable"/"variables") consistently across all scripting languages that currently omit them, matching what Groovy already provides.

Note: any change here touches default script bindings, which is user-visible behavior — should be scoped carefully and documented in the upgrade guide if any naming changes are involved (see CAMEL-21213 for a precedent of aligning Groovy's naming to Simple's).



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