allthingssecurity commented on code in PR #26924:
URL: https://github.com/apache/camel/pull/26924#discussion_r4115130283
##########
docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc:
##########
@@ -173,6 +173,15 @@ Only options whose value is a placeholder are affected,
and only when running wi
Camel Quarkus. If a component must not be stopped on reload, configure it
programmatically rather than with a
placeholder based property.
+=== Languages - less than with two null values, and a source from a variable
+
+- The `<` operator (in the Simple language and the Java DSL `isLessThan`) is
now `false` when both sides are `null`,
+ as the `>` operator already was. Prior to Camel 4.23, `${header.a} <
${header.b}` was `true` when neither header
+ existed. The `<=` and `>=` operators are unchanged and are `true` in that
case.
+- A language that reads its input from a `source` of `variable:name` now fails
with `NoSuchVariableException` when the
Review Comment:
Worth adding that this also applies to a `source` without a prefix:
`singleInputExpression` treats a plain name as a variable, so `source="myVar"`
now fails the same way. The same helper is behind the `source` option of the
xslt, xslt-saxon and xquery endpoints.
_Claude Code on behalf of allthingssecurity_
##########
core/camel-support/src/main/java/org/apache/camel/support/builder/ExpressionBuilder.java:
##########
@@ -175,6 +175,11 @@ public String toString() {
};
}
+ private static String typeName(Class<?> type) {
+ // the class resolver loads an array type by its canonical name
(byte[]) and not by its binary name ([B)
+ return type.isArray() ? type.getCanonicalName() : type.getName();
Review Comment:
This fixes `byte[]`, but as far as I can trace `ObjectHelper.loadClass`,
other arrays still won't resolve: it tries `loadSimpleType` on the full name
(which knows only `byte[]`, `Byte[]`, `Object[]` and `String[]`), otherwise
strips one `[]` and calls `ClassLoader.loadClass` on the rest. So
`int[]`/`long[]`/`char[]` (-> `loadClass("int")`), arrays of nested classes
(canonical `a.b.Outer.Inner[]` -> `loadClass("a.b.Outer.Inner")`) and
`byte[][]` would still end in `ClassNotFoundException`. Not a regression, they
didn't work before either. Since the `Class` is already in hand in these
overloads, they could use `getHeader(key, type)` / `getProperty(key, type)` /
`getVariable(key, type)` directly instead of going from class to name and back.
_Claude Code on behalf of allthingssecurity_
--
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]
