k-krawczyk opened a new pull request, #25945:
URL: https://github.com/apache/camel/pull/25945
The `simple` language throws `NumberFormatException` when it compares
numbers with more digits
than a long can hold, such as bank account numbers. `ObjectHelper.isNumber`
only checks that the
text is all digits, and the callers then parse it with `Long.parseLong` or
`Integer.valueOf`.
The reproducer from the issue:
```java
from("timer:test?repeatCount=1&delay=1000")
.setHeader("Account1").constant("12345678901234567890")
.setHeader("Account2").constant("12345678901234567890")
.filter().simple("${header.Account1} == ${header.Account2}")
.log(LoggingLevel.INFO, "Accounts equals")
.end();
```
### Scope
The failure is wider than the reported `==` case:
* `<`, `>`, `<=`, `>=` between two such strings
* a numeric literal in the expression itself (`${header.Account1} ==
12345678901234567890`),
which already fails while the route is being built
* the same literal in quotes, so quoting is not a workaround
* a String compared against an `Integer` when the string does not fit in an
int
(for example `"99999999999"`)
### Affected versions
Reproduced on `ObjectHelper.typeCoerceEquals` / `typeCoerceCompare` in
3.20.2, 4.10.7, 4.18.2,
4.22.0 and current main. On 2.25.4 the same comparison returns `true`, so
this is a regression
introduced in the Camel 3 line rather than in 4.
### Fix
String to String comparisons fall back to `BigInteger` when the value does
not fit in a long.
A number outside the long range can never equal an int or a long, so
equality against one is
`false`, and ordering against one is decided as `BigInteger`. A numeric
literal in a predicate
that does not fit in a long is now kept as literal text, so it takes the
same comparison path
as a header would.
`isNumber()` is left alone on purpose: `SimplePredicateParser` and
`camel-attachments` rely on
its "digits only" meaning.
### Tests
* `isLongNumber` cases in `camel-support` `ObjectHelperTest`
* big number equality in `camel-core` `ObjectHelperTest`
* big number ordering in `TypeCoerceCompareTest`
* the reported scenario in `SimpleOperatorTest`
_Reported by Claude Code on behalf of Karol Krawczyk_
--
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]
