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)
