[
https://issues.apache.org/jira/browse/CAMEL-24467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18119141#comment-18119141
]
shashank commented on CAMEL-24467:
----------------------------------
I would like to work on this one. Could a committer assign it to me
(smjainblr)? My JIRA account cannot assign issues itself.
Proposed scope, keeping the change additive (no binding is renamed or removed,
so existing scripts keep working):
* camel-javascript and the legacy camel-python: add {{variable}} and
{{variables}} (the Exchange variables map) next to the existing {{headers}},
{{properties}} and {{body}}, matching what Groovy gets from
{{ExchangeHelper.populateVariableMap}}.
* camel-mvel and camel-ognl: add {{getVariables()}}, {{getVariable(name)}} and
{{getVariable(name, type)}} to their {{RootObject}}, so {{variables.foo}} and
{{variable('foo')}} work like {{headers}} and {{header(...)}} do today.
* camel-python3: add {{variables}} as data, in the same way {{headers}} is
bound in untrusted mode, so it does not widen host access. In trusted mode the
Exchange is already reachable.
* Tests for each language, and the binding tables in each language's
documentation, with the catalog regenerated. No upgrade guide entry is needed
if nothing is renamed.
Reusing {{populateVariableMap}} wholesale would also add names like {{header}}
and {{exchangeProperty}}, and in the "context map all" mode it would expose
{{exchange}}, {{in}}, {{out}} and so on to languages that currently gate them.
So I would share only the variables part in this ticket. The shared
binding-name definition and the facade that Federico describes could then
follow in its own ticket, as he suggests. Does that scope sound right?
_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)
