[
https://issues.apache.org/jira/browse/CAMEL-24467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18114172#comment-18114172
]
Federico Mariani commented on CAMEL-24467:
------------------------------------------
Cross-reference from CAMEL-24688 / apache/camel#26309 (camel-quickjs {{camel}}
facade):
Follow-up noted while reviewing this PR: with the {{camel}} facade,
camel-quickjs becomes the only language that exposes the exchange through a
named, whitelisted set of operations. The others use one of two models: live
Java objects with no boundary (groovy, mvel, ognl, jexl, jOOR,
camel-javascript) or data-only bindings with an all-or-nothing switch to live
objects ({{createWithHostAccess()}} in camel-jactl and camel-python3). There is
also no shared definition of the binding names: {{header}}/{{headers}},
{{exchangeProperty}}/{{properties}}, {{variable}}/{{variables}},
{{request}}/{{in}}/{{message}} vary per language, and
{{ExchangeHelper.populateVariableMap}} is used by groovy and thymeleaf only.
A shared definition would be a good separate change: one place in camel-support
that lists the binding names and the facade operations ({{getBody/setBody}},
{{get/set/removeHeader}}, {{get/set/removeProperty}},
{{get/set/removeVariable}}, {{log}}) so that jactl and python3 can offer
mutation without trusted mode, and the docs of every scripting language can
point to the same table. CAMEL-24467 already covers the bindings side; the
facade side can join it or get its own ticket.
_Claude Code on behalf of Croway_
> 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)
