Re: New release for commons jexl

2024-05-24 Thread Henri Biestro


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



Re: commons-jexl3 issues while calling functions

2024-04-24 Thread Henri Biestro
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 remediation.

Cheers

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [jexl] Problem with division of integer values and narrowing of BigDecimal to Integer

2023-11-28 Thread Henri Biestro
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 unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [jexl] Problem with division of integer values and narrowing of BigDecimal to Integer

2023-11-08 Thread Henri Biestro
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 return bigi.
Cheers
Henri

On 2023/11/01 18:45:49 Robert Lucas wrote:
> Hi,
> 
> We've run into an issue with using JEXL due to a combination of integer 
> division on integer values and narrowing of BigDecimals to Integer. Not sure 
> if this type of problem has come up before. This forum only seems to have 4 
> jexl issues and the Jira didn't have anything similar either.
> 
> We use JEXL to allow our end users to write simple "Excel" like expressions. 
> All the numeric variables in our expressions are presented to JEXL as 
> BigDecimals.
> 
> The problem was exposed by the simple expression "(a-12)/12".
> 
>   *   If BigDecimal a = 56.1
>  *   Then 56.1 - 12 -> BigDecimal 44.1
>  *   Then BigDecimal 44.1 / 12 -> BigDecimal 44.1 / BigDecimal 12 -> 
> BigDecimal 3.675
>   *   If BigDecimal a = 56
>  *   Then BigDecimal 56 - 12 -> BigDecimal 44 -> narrows to Integer 44
>  *   Then Integer 44 / Integer 12 -> Integer 3! Not 3.6 recuring 
> (because division of integer values is done as integer division)
> 
> So the value of the result becomes incorrect based on the initial value of 
> "a" not it's type.
> 
> A work around is to change the expression to "(a-12)/12.0" to force Double 
> arithmetic, but that use of 12.0 isn't natural to ordinary users used to 
> Excel.
> 
> Also if you had an expression like "(a-12)/(b-3)" you wouldn't have any way 
> to force the use of BigDecimal division instead of integer divisions as JEXL 
> chooses which based on the narrowed result value.
> 
> Also you could have a case of "a * (7/8)", e.g. 7 8ths of 'a' where the users 
> is more comfortable with expression 7/8 as a faction not a decimal. Here 7/8 
> -> 0 as integer division.
> 
> It would be useful if there was a way to:
> 
>   *   Force BigDecimal division not integer division
>   *   Disable the narrowing to keep the intermediate and result types as 
> BigDecimal.
> 
> I haven't seem anything in the JexlArithmetic class that would allow the 
> above. Is there any other way to force this?
> 
> Kind regards,
> Robert Lucas
> 
> NICE Systems UK Limited ("NICE") is registered in England under company 
> number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, 
> Southampton, Hampshire SO30 2ZP.
> 
> Confidentiality: This communication and any attachments are intended for the 
> above-named persons only and may be confidential and/or legally privileged. 
> Any opinions expressed in this communication are not necessarily those of 
> NICE. If this communication has come to you in error you must take no action 
> based on it, nor must you copy or show it to anyone; please delete/destroy 
> and inform the sender by e-mail immediately.
> 
> Monitoring: NICE may monitor incoming and outgoing e-mails.
> Viruses: Although we have taken steps toward ensuring that this e-mail and 
> attachments are free from any virus, we advise that in keeping with good 
> computing practice the recipient should ensure they are actually virus free.
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: JEXL: all object variables return null

2023-11-08 Thread Henri Biestro
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 default) 
and they must be public. (see 
https://commons.apache.org/proper/commons-jexl/apidocs/org/apache/commons/jexl3/introspection/JexlPermissions.html#parse-java.lang.String...-)
Cheers

On 2023/11/03 13:28:50 "r.c.hoekstra" wrote:
> I'm trying to get a jexl script to work.
> 
> |// arranging namespace Print Map ns = new HashMap<>(1); 
> ns.put("Print", System.out); // make System.out.println available in 
> expressions JexlEngine je = new JexlBuilder().namespaces(ns).create(); 
> // arranging custom Map for accessible variable 'agent' in script 
> Map myMap = ; myMap.put("test", testRef); 
> JexlContext jc = new MapContext(myMap); // arranging script JexlScript 
> script = je.createScript(expression); Object result = script.execute(jc); 
> |
> 
> |The testRef is just a simple instance of this class: |
> 
> privatestaticclassTestContextVar {
> 
> publicString getInstanceVar(){
> 
> return"instanceValue";
> 
> }
> 
> }
> 
> 
> with the expression being this:
> 
> |{ Print:println("blabla"); const x = test.getInstanceVar(); 
> Print:println(x); return true; } |
> 
> ||
> 
> The first command just prints "blabla" to the console, so the printing 
> via System.out.println works flawless.
> 
> However, for the variable test: it does exist, because jexl doesn't 
> report "unsolvable variable". Also, Print:println(test) just prints the 
> memory address as expected.
> 
> However, any method of the test Object which I try to call, always 
> returns null. I just get a null printed to the console.
> 
> Also, when I call test.instanceVar (which should be possible, it is just 
> a POJO), I get "undefined property 'id', assuming false". Whereas 
> test.getInstanceVar() returns just null.
> 
> Anyone any idea what could go wrong here?
> 
> 
> thanks, Rinke
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



[ANNOUNCEMENT] Apache Commons JEXL 3.3

2023-03-27 Thread Henri Biestro
The Apache Commons JEXL team is happy to announce the release of version
3.3.

JEXL is a library intended to facilitate the implementation of dynamic and
scripting features in applications and frameworks written in Java.

This is a feature and bug-fix release.

Site: https://commons.apache.org/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


Re: [ JEXL ] Engine and expression thread safety

2023-03-01 Thread Henri Biestro
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 'greedy' expression creation.

Wrt security, as of JEXL 3.3 - soon to be released -, the default permissions 
will restrict what a user can access to a very limited set of classes. Those 
are configurable and can be tailored (JexlPermissions/JexlSandbox/@NoJexl 
annotation). In JEXL 3.2.1, *by default*, any public class/method/field is 
accessible which ultimately allows all kinds of shenanigans.
You can also restrict parts of the language to disallow constructs like 
side-effects (JexlFeatures).

Hope this helps,
Cheers

On 2023/02/23 15:36:18 Nilesh PS wrote:
> Hello Jexl users,
> 
> First of all, thank you devs for building and maintaining this library. I
> was about to give up my search for a simple expression evaluator when I
> came across Jexl.
> 
> I'm hoping to use Jexl in a web service to evaluate simple expressions.
> Having tried out a few simple expressions successfully, a couple of
> questions immediately came to mind.
> 
> 1. Are classes like JexlEngine and JexlExpression thread safe ?  I'm
> running a spring boot service with one thread per request and have to
> evaluate some expressions with the values given in the request. Would it be
> safe to create a JexlExpression during service init and share it between
> all request threads ? I'm hoping this would reduce the latency overhead
> since the expression is parsed only once, but I couldn't figure out whether
> it's safe to do so.
> 
> 2.  Are there any obvious security risks in evaluating expressions (not
> scripts) that come from an external user ? I know this will heavily depend
> on my implementation, but I'm hoping expressions are side effect free (e.g
> no calls to System.setProperty allowed) under all circumstances so they can
> be used with simple string and number inputs.
> 
> Any inputs are appreciated.
> 
> Thanks,
> Nilesh
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: Jexl Expression Documentation

2023-02-16 Thread Henri Biestro
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 identifiers, literals, arrays connected by 
operators -arithmetic operators (+, -, ...), comparison operators (>, <, ...), 
assignments ( x= ..., x+=...), function/method calls.
Btw, you can further restrict those using JexlFeatures (to disallow side 
effects for instance).
Hope this helps.

On 2023/02/16 04:59:15 Vipul Goyal wrote:
> Hi Team,
> 
> I struggling to find the documentation just for Jexl Expression. I want to
> share reference documentation with my users on what syntax and operators
> are supported.
> 
> I see documentation is being mixed up with expression and script and not
> able to find explicitly for Jexl expression.
> 
> Please help.
> 
> Regards,
> Vipul
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



[ JEXL ] Getting ready to release 3.3

2023-02-14 Thread Henri Biestro (Apache)
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


Re: jexl upgrade path from 1.x

2023-02-14 Thread Henri Biestro
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 was released in 2015, JEXL 2 
was released in 2010 and JEXL 1 in 2006...

On 2023/02/01 23:35:19 Alex O'Ree wrote:
> Perhaps I wasn't clear. Let's pretend I'm a user of jexl 1.x looking to
> upgrade to a newer version. Is there any documentation for migrating to a
> newer version?
> 
> On Tue, Jan 31, 2023 at 8:56 PM Gilles Sadowski 
> wrote:
> 
> > Hi.
> >
> > Le mer. 1 févr. 2023 à 02:37, Alex O'Ree  a écrit :
> > >
> > > Hi i'm doing some maintenance work on the bsf library
> >
> > Please move the discussion to the "dev" mailing list.
> >
> > > which currently
> > > depends on a jexl 1.x. There's a few imports that aren't exactly
> > resolving.
> > >
> > > import org.apache.commons.jexl.JexlContext;
> > > moved to import org.apache.commons.jexl3.JexlContext;
> > >
> > > import org.apache.commons.jexl.JexlHelper;
> > > unknown what happened to this but seems to have been removed in 2.x
> > >
> > > import org.apache.commons.jexl.Script;
> > > i think moved to import org.apache.commons.jexl3.JexlScriptScript;
> > >
> > > import org.apache.commons.jexl.ScriptFactory;
> > > not sure what this maps to in the current code base
> > >
> > > I found some notes in the release notes about a jexl-comat library but
> > > couldn't find it published anywhere. I also poked around the website
> > > looking for some kind of migration guide.
> > >
> > > Any pointers to how i can update this code base?
> >
> > I'd be wary to release a new version of this component, using a
> > dependency that is more than 10 years old.
> > IMHO, the way to go is to depend on the lastest (i.e. supported)
> > version of JEXL.
> >
> > Please post specific questions about upgrading the BSF codebase
> > using a "Subject:" line with the "[BSF]" prefix (on "dev@").[1]
> >
> > Thanks,
> > Gilles
> >
> > [1] There are dozens of components, sharing the same ML.
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
> >
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [JEXL] Troubles upgrading to 3.2

2021-06-08 Thread Henri Biestro
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 'allow' 
TemplateInterpreter in your SandoxUberspect getMethod.
On mine, the fix is coming momentarily but the release might take a little 
longer.
Sorry for the inconvenience,
Henri

On 2021/06/07 15:42:55, Francesco Chicchiricc��  wrote: 
> Hi there,
> at Syncope we are using Commons JEXL for various tasks, including 
> notification e-mail templates.
> 
> All is working fine with 3.1 but when I switch to 3.2 all the tests from [1] 
> are failing because no output is produced at all after template evaluation.
> 
> Anything obvious I am missing here?
> 
> TIA
> Regards.
> 
> [1] 
> https://github.com/apache/syncope/blob/master/core/provisioning-api/src/test/java/org/apache/syncope/core/provisioning/api/jexl/MailTemplateTest.java
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [JEXL] Troubles upgrading to 3.2

2021-06-07 Thread Henri Biestro
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 Syncope we are using Commons JEXL for various tasks, including 
> notification e-mail templates.
> 
> All is working fine with 3.1 but when I switch to 3.2 all the tests from [1] 
> are failing because no output is produced at all after template evaluation.
> 
> Anything obvious I am missing here?
> 
> TIA
> Regards.
> 
> [1] 
> https://github.com/apache/syncope/blob/master/core/provisioning-api/src/test/java/org/apache/syncope/core/provisioning/api/jexl/MailTemplateTest.java
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [jexl] Make jexl consider power operator

2020-10-28 Thread Henri Biestro
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 expression via jexl :  x^y
> What I've tried, is to extend JexlArithmetic:
> 
> // Extend Arithmetic
> public class ExtendedJexlArithmetic extends JexlArithmetic
> {
> public ExtendedJexlArithmetic(boolean strict){
> super(strict);
> }
> 
> public xor(Object l, Object r){
> return Math.pow(l, r);
> }
> }
> 
> def engine = new 
> JexlBuilder().cache(512).strict(true).silent(false).namespaces(ns).arithmetic(new
>  ExtendedJexlArithmetic(true)).create();
> engine.createExpression(model_formula).evaluate(contextMap);
> 
> 
> However, it does not consider operator priority. As a result, I am still 
> getting wrong results:
> 
> 2+4^3 -> 216 (instead of 66).
> 
> How can I properly fix this ?
> 
> Thhhx!
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [jexl] Make jexl consider power operator

2020-10-27 Thread Henri Biestro
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.pow(l.doubleValue(), r.doubleValue());
}
}

@Test
public void test333() throws Exception {
JexlEngine jexl = new JexlBuilder().arithmetic(new 
ExtendedJexlArithmetic(true)).create();
JexlScript spow = jexl.createScript("x ^ y", "x", "y");
Object r =  spow.execute(null, 2, 3);
Assert.assertTrue(r instanceof Number);
Assert.assertEquals(8.d, ((Number) r).doubleValue(), 1e-7);
}

On 2020/09/23 14:28:33, BENGUIGUI Michael 
 wrote: 
> Dear all,
> 
> I am trying to evaluate the following expression via jexl :  x^y
> What I've tried, is to extend JexlArithmetic:
> 
> // Extend Arithmetic
> public class ExtendedJexlArithmetic extends JexlArithmetic
> {
> public ExtendedJexlArithmetic(boolean strict){
> super(strict);
> }
> 
> public xor(Object l, Object r){
> return Math.pow(l, r);
> }
> }
> 
> def engine = new 
> JexlBuilder().cache(512).strict(true).silent(false).namespaces(ns).arithmetic(new
>  ExtendedJexlArithmetic(true)).create();
> engine.createExpression(model_formula).evaluate(contextMap);
> 
> 
> However, it does not consider operator priority. As a result, I am still 
> getting wrong results:
> 
> 2+4^3 -> 216 (instead of 66).
> 
> How can I properly fix this ?
> 
> Thhhx!
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org