[
https://issues.apache.org/jira/browse/CAMEL-24467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18119150#comment-18119150
]
shashank commented on CAMEL-24467:
----------------------------------
Correction to my comment above: I wrote that {{variable('foo')}} would work in
MVEL/OGNL like {{header('foo')}}. Neither does. Both languages call root-object
methods by their Java name, so the working forms are {{getHeader('foo')}} and
{{getVariable('foo')}}; the map form {{variables.foo}} / {{variables['foo']}}
works as well. The docs of both languages currently list {{header(name)}} and
{{property(name)}}, which do not resolve either, so I would correct those rows
to {{getHeader(...)}} / {{getProperty(...)}} in the same change. The rest of
the scope is unchanged, and the implementation (with tests for all five
languages) is ready once the issue is assigned.
_Claude Code on behalf of allthingssecurity_
> 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
> Priority: Minor
>
> 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)
