gnodet-bot commented on code in PR #27525:
URL: https://github.com/apache/camel/pull/27525#discussion_r4213326430
##########
components/camel-python3/src/main/java/org/apache/camel/language/python3/Python3Expression.java:
##########
@@ -33,6 +36,7 @@ public Python3Expression(String text) {
Python3Expression(String text, Python3Language language) {
this.text = text;
+ this.bindVariables = text != null && text.contains("variables");
Review Comment:
💡 **Asymmetry note:** Python3 uses `contains("variables")` (plural) while JS
and Jython use `contains("variable")` (singular). If this is intentional (e.g.
Python3 binds only the map, not the singular accessor), a brief comment here
would help future readers understand why the check differs.
##########
components/camel-ognl/src/main/java/org/apache/camel/language/ognl/RootObject.java:
##########
@@ -78,4 +78,27 @@ public <T> T getHeader(String name, Class<T> type) {
return exchange.getMessage().getHeader(name, type);
}
Review Comment:
🔧 **Nit:** This blank line contains a trailing space character. Most editors
and `git diff --check` will flag it.
```suggestion
```
##########
components/camel-javascript/src/main/java/org/apache/camel/language/js/JavaScriptExpression.java:
##########
@@ -34,6 +39,7 @@ public JavaScriptExpression(String expressionString, Class<?>
type) {
JavaScriptExpression(String expressionString, Class<?> type,
JavaScriptLanguage language) {
Review Comment:
💡 **Heuristic caveat:** `contains("variable")` is a plain substring match —
a script that merely mentions the word in a string literal or comment (e.g. `//
bind variable to foo`) would cause `bindVariables = true` unnecessarily. The
comment above documents why the lazy-binding approach is needed, but it may be
worth noting this limitation there too, so future maintainers don't
over-tighten it and break the common case.
##########
components/camel-mvel/src/main/java/org/apache/camel/language/mvel/RootObject.java:
##########
@@ -81,4 +81,27 @@ public Object getHeader(String name) {
public <T> T getHeader(String name, Class<T> type) {
return exchange.getMessage().getHeader(name, type);
}
+
+ /**
+ * The variables of the exchange (exchange-scoped only; global and route
variables are not in this map).
+ */
+ public Map<String, Object> getVariables() {
+ return exchange.getVariables();
+ }
Review Comment:
💡 **Design note:** `getVariables()` returns the raw map from
`exchange.getVariables()`, which contains only exchange-scoped variables.
`getVariable(String name)`, on the other hand, delegates to
`exchange.getVariable(name)` which resolves `global:` and `route:` prefixes.
This means `getVariables().get("global:myVar")` will return `null`, while
`getVariable("global:myVar")` works correctly. The Javadoc on `getVariables()`
calls this out ("exchange-scoped only"), which is good, but it may be worth
adding a `@see #getVariable(String)` cross-reference to guide users who need
cross-scope access.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
