In Java, the following does the trick:
// Extend Arithmetic
public static class ExtendedJexlArithmetic extends JexlArithmetic {
public ExtendedJexlArithmetic(boolean strict){
super(strict);
}
public double xor(Number l, Number r){
return Math
Sorry, I misread your original problem; JEXL does follow Java's operator
precedence and there is no way to alter this behaviour (besides modifying the
grammar in Parser.jjt file).
On 2020/09/23 14:28:33, BENGUIGUI Michael
wrote:
> Dear all,
>
> I am trying to evaluate the following expressio
Hi Francesco;
I'm sorry, I've tried and failed setting up a dev env for syncope to debug your
pb (java8 vs java11...).
I don't see any obvious reason for templates to misbehave.
Not sure how to help.
I'll keep digging...
On 2021/06/07 15:42:55, Francesco Chicchiricc�� wrote:
> Hi there,
> at Sy
Hi Francesco;
I was able to reproduce your problem and found the source of the regression
that I logged as JEXL-351.
The culprit is an unfortunate implementation change in 3.2 that break templates
used with strict sandboxing.
On your side, if you want to go further with JEXL 3.2, you may want to
No, there is no such documentation but if you face difficulties, we'll gladly
help.
Found a trace of JEXL combat here:
https://apache.googlesource.com/commons-jexl/+/refs/heads/2.0-API-COMPAT/jexl2-compat/src/main/java/org/apache/commons/jexl
Time flies though, JEXL 3.3 is coming soon, JEXL3 wa
Hi Vipul;
I agree the documentation is at best scarce on the matter.
The Javadoc for JexlExpression describe them as 'simply a reference to a single
expression, not to multiple statements' and ''if','for','while','var' and
blocks '{'... '}'are not allowed'.
So an expression is composed of identif
Hi Nilesh;
Wrt thread safety, yes, JexlEngine and JexlExpression are thread-safe. Objects
whose access is shared through scripts - your classes - must be too though.
Btw, in your case, note that JEXL uses a (configurable thread-safe) cache for
expressions which may mitigate your need for 'greed
/proper/commons-jexl/
Changes: https://commons.apache.org/proper/commons-jexl/changes-report.html
Download it from:
https://commons.apache.org/proper/commons-jexl/download_jexl.cgi
Henri Biestro,
for the Apache Commons JEXL team
Hi Rinke;
>From the looks of it, I'd say the 'private static ' and permissions are
>the most likely culprit (if you are using JEXL 3.3).
JEXL will only see/introspect public classes for which it is allowed to through
permissions; you own classes/packages must be allowed (they aren't by defaul
Hi Robert;
There is no configuration that can help but you can certainly customize and
create your own derivation of JexlArithmetic that would forego trying to narrow
results for the common arithmetic operators. In your case, it might be enough
to just override narrowBigInteger(...bigi) to retur
Hi Robert;
It took me a while to realize it but this behavior is indeed a bug; if user
input is a BigDecimal, JEXL should not try and coerce with precision loss.
Created JEXL-417.
Sorry about the delay.
Cheers
Henri
-
To unsubsc
Hello;
In a word, JexlPermissions is the missing piece (
https://commons.apache.org/proper/commons-jexl/apidocs/org/apache/commons/jexl3/introspection/JexlPermissions.html
).
At the beginning of the [release
notes|https://commons.apache.org/proper/commons-jexl/relnotes33.html], you'll
find the
Starting preparations for a 3.4 release :-)
Henrib
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
iling Lists" and "Issue Tracking" links here:
http://commons.apache.org/jexl/project-info.html
Henri Biestro
- On behalf of the Apache Commons community
Dear all;
I intend on starting the release of JEXL 3.3 with a landing (ideally) in
early March..
If you've any feedback on features, bugs, etc, that may impact that
release, please reach out now.
Cheers
15 matches
Mail list logo
