[jira] [Resolved] (JEXL-422) Add strict equality (===) and inequality (!==) operators
[ https://issues.apache.org/jira/browse/JEXL-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-422. Resolution: Fixed [Commited|https://github.com/apache/commons-jexl/commit/b640ba6820eb07ffc23043f118a3497f64339df5] > Add strict equality (===) and inequality (!==) operators > > > Key: JEXL-422 > URL: https://issues.apache.org/jira/browse/JEXL-422 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.3 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Minor > Fix For: 3.4 > > > As in Javascript, === is a comparison operator that checks the equality of > two values without performing any type conversion. This means that if the > values being compared have different data types, === will return false. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-423) Add support for instanceof / !instanceof
[
https://issues.apache.org/jira/browse/JEXL-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-423.
Resolution: Fixed
[Commited|https://github.com/apache/commons-jexl/commit/b640ba6820eb07ffc23043f118a3497f64339df5]
> Add support for instanceof / !instanceof
>
>
> Key: JEXL-423
> URL: https://issues.apache.org/jira/browse/JEXL-423
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.4
>
>
> The *instanceof* operator allows to check whether an object belongs to a
> certain class.
> It is using Class.isInstance to perform the check. As a convenience, {{
> !instanceof }} is supported as well avoiding parenthesis as in:
> {code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
> y){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-396) Add explicit Java module descriptor
[ https://issues.apache.org/jira/browse/JEXL-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-396. Resolution: Fixed > Add explicit Java module descriptor > --- > > Key: JEXL-396 > URL: https://issues.apache.org/jira/browse/JEXL-396 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Andres Almiray >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > Follow up from a > [topic|https://lists.apache.org/thread/kxcwqyx026rhhx4v8q8bkbljj7lw8c32] > started at the mailing list. > Henri suggested using the ModiTect plugin guarded by a profile with JDK > activation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-235) Verify JexlScriptEngineFactory.{getLanguageVersion,getEngineVersion} before release
[
https://issues.apache.org/jira/browse/JEXL-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849306#comment-17849306
]
Henri Biestro commented on JEXL-235:
Checked [3.4|
https://github.com/apache/commons-jexl/commit/b640ba6820eb07ffc23043f118a3497f64339df5].
> Verify JexlScriptEngineFactory.{getLanguageVersion,getEngineVersion} before
> release
> ---
>
> Key: JEXL-235
> URL: https://issues.apache.org/jira/browse/JEXL-235
> Project: Commons JEXL
> Issue Type: Task
>Affects Versions: 3.2
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: Later
>
>
> JexlScriptEngineFactory.getLanguageVersion and
> JexlScriptEngineFactory.getEngine version should reflect the syntax version
> and the engine version respectively.
> As a rule, any new operator or syntax should bump the language version, any
> release should update the engine version that should match the jar version.
> (see JEXL-227 for discussion on the issue).
> This task must be checked for each version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-397) Dynamic proxy should not require specific permission
[
https://issues.apache.org/jira/browse/JEXL-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-397:
---
Fix Version/s: 3.3.1
(was: 3.4)
> Dynamic proxy should not require specific permission
>
>
> Key: JEXL-397
> URL: https://issues.apache.org/jira/browse/JEXL-397
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> With the default restricted permissions, dynamic proxies can not be
> introspected since they extend java.lang.reflect.Proxy whose package is
> denied.
> A workaround is to explicitly allow them as in:
> {code:java}
> JexlPermissions p = new JexlPermissions.Delegate(JexlPermissions.RESTRICTED) {
> @Override public boolean allow(Class clazz) {
> return Proxy.isProxyClass(clazz) || super.allow(clazz);
> }
> };
> {code}
> This workaround should not be necessary.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-396) Add explicit Java module descriptor
[ https://issues.apache.org/jira/browse/JEXL-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-396: --- Fix Version/s: 3.3.1 (was: 3.4) > Add explicit Java module descriptor > --- > > Key: JEXL-396 > URL: https://issues.apache.org/jira/browse/JEXL-396 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Andres Almiray >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > Follow up from a > [topic|https://lists.apache.org/thread/kxcwqyx026rhhx4v8q8bkbljj7lw8c32] > started at the mailing list. > Henri suggested using the ModiTect plugin guarded by a profile with JDK > activation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-396) Add explicit Java module descriptor
[ https://issues.apache.org/jira/browse/JEXL-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-396: --- Fix Version/s: 3.4 > Add explicit Java module descriptor > --- > > Key: JEXL-396 > URL: https://issues.apache.org/jira/browse/JEXL-396 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Andres Almiray >Assignee: Henri Biestro >Priority: Major > Fix For: 3.4 > > > Follow up from a > [topic|https://lists.apache.org/thread/kxcwqyx026rhhx4v8q8bkbljj7lw8c32] > started at the mailing list. > Henri suggested using the ModiTect plugin guarded by a profile with JDK > activation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-423) Add support for instanceof / !instanceof
[
https://issues.apache.org/jira/browse/JEXL-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-423:
---
Description:
The *instanceof* operator allows to check whether an object belongs to a
certain class.
It is using Class.isInstance to perform the check. As a convenience, {{
!instanceof }} is supported as well avoiding parenthesis as in:
{code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
y){code}
was:
The {code:java} instanceof {code}
operator allows to check whether an object belongs to a certain class.
It is using Class.isInstance to perform the check. As a convenience, {{
!instanceof }} is supported as well avoiding parenthesis as in:
{code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
y){code}
> Add support for instanceof / !instanceof
>
>
> Key: JEXL-423
> URL: https://issues.apache.org/jira/browse/JEXL-423
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> The *instanceof* operator allows to check whether an object belongs to a
> certain class.
> It is using Class.isInstance to perform the check. As a convenience, {{
> !instanceof }} is supported as well avoiding parenthesis as in:
> {code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
> y){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-423) Add support for instanceof / !instanceof
[
https://issues.apache.org/jira/browse/JEXL-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-423:
---
Description:
The {code:java} instanceof {code}
operator allows to check whether an object belongs to a certain class.
It is using Class.isInstance to perform the check. As a convenience, {{
!instanceof }} is supported as well avoiding parenthesis as in:
{code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
y){code}
was:
The {{instanceof}} operator allows to check whether an object belongs to a
certain class.
It is using Class.isInstance to perform the check. As a convenience,
{{!instanceof}} is supported as well avoiding parenthesis as in:
{{x !instanceof y}} is equivalent to {{!(x instanceof y)}}
> Add support for instanceof / !instanceof
>
>
> Key: JEXL-423
> URL: https://issues.apache.org/jira/browse/JEXL-423
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> The {code:java} instanceof {code}
> operator allows to check whether an object belongs to a certain class.
> It is using Class.isInstance to perform the check. As a convenience, {{
> !instanceof }} is supported as well avoiding parenthesis as in:
> {code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
> y){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-423) Add support for instanceof / !instanceof
Henri Biestro created JEXL-423:
--
Summary: Add support for instanceof / !instanceof
Key: JEXL-423
URL: https://issues.apache.org/jira/browse/JEXL-423
Project: Commons JEXL
Issue Type: New Feature
Affects Versions: 3.3
Reporter: Henri Biestro
Assignee: Henri Biestro
Fix For: 3.3.1
The {{instanceof}} operator allows to check whether an object belongs to a
certain class.
It is using Class.isInstance to perform the check. As a convenience,
{{!instanceof}} is supported as well avoiding parenthesis as in:
{{x !instanceof y}} is equivalent to {{!(x instanceof y)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-422) Add strict equality (===) and inequality (!==) operators
Henri Biestro created JEXL-422: -- Summary: Add strict equality (===) and inequality (!==) operators Key: JEXL-422 URL: https://issues.apache.org/jira/browse/JEXL-422 Project: Commons JEXL Issue Type: New Feature Affects Versions: 3.3 Reporter: Henri Biestro Assignee: Henri Biestro Fix For: 3.3.1 As in Javascript, === is a comparison operator that checks the equality of two values without performing any type conversion. This means that if the values being compared have different data types, === will return false. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-418) Add try-catch support
[ https://issues.apache.org/jira/browse/JEXL-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-418. Fix Version/s: 3.3.1 Resolution: Fixed Merged [b7f7201|https://github.com/apache/commons-jexl/commit/b7f720162deda73c273cb2668e1433fe82b37b65] > Add try-catch support > - > > Key: JEXL-418 > URL: https://issues.apache.org/jira/browse/JEXL-418 > Project: Commons JEXL > Issue Type: New Feature >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Minor > Fix For: 3.3.1 > > > Hi, > Is it possible to add try-catch support? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-418) Add try-catch support
[ https://issues.apache.org/jira/browse/JEXL-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818106#comment-17818106 ] Henri Biestro commented on JEXL-418: Development started in [JEXL-418|https://github.com/apache/commons-jexl/tree/JEXL-418] Syntax is in (try/try-with-resource/catch/finally); only one catch clause. More tests to follow. > Add try-catch support > - > > Key: JEXL-418 > URL: https://issues.apache.org/jira/browse/JEXL-418 > Project: Commons JEXL > Issue Type: New Feature >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Minor > > Hi, > Is it possible to add try-catch support? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-418) Add try-catch support
[ https://issues.apache.org/jira/browse/JEXL-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-418: --- Assignee: Henri Biestro > Add try-catch support > - > > Key: JEXL-418 > URL: https://issues.apache.org/jira/browse/JEXL-418 > Project: Commons JEXL > Issue Type: New Feature >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Minor > > Hi, > Is it possible to add try-catch support? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-421) ArrayBuilder: array type should reflect common class of its entries
[ https://issues.apache.org/jira/browse/JEXL-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-421. Resolution: Fixed Commit [b10477e|https://github.com/apache/commons-jexl/commit/b10477ec25c7b7ed52e58aca30e8ab3c940eeaa9] > ArrayBuilder: array type should reflect common class of its entries > --- > > Key: JEXL-421 > URL: https://issues.apache.org/jira/browse/JEXL-421 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Minor > Fix For: 3.3.1 > > > WHAT: > The ArrayBuilder (used on syntax like [1,3,5]) tries hard to unbox if > possible (Integer to int) or keep Number as common class but falls short of > strong typing for other classes. > It would be convenient to type arrays using the strongest (in sense of > abstraction) common class from the entries. > HOW: > When detecting entry class mismatch (and not a unboxing or Number), find > better common class; Object class should only be last resort. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JEXL-421) ArrayBuilder: array type should reflect common class of its entries
Henri Biestro created JEXL-421: -- Summary: ArrayBuilder: array type should reflect common class of its entries Key: JEXL-421 URL: https://issues.apache.org/jira/browse/JEXL-421 Project: Commons JEXL Issue Type: Improvement Affects Versions: 3.3 Reporter: Henri Biestro Assignee: Henri Biestro Fix For: 3.3.1 WHAT: The ArrayBuilder (used on syntax like [1,3,5]) tries hard to unbox if possible (Integer to int) or keep Number as common class but falls short of strong typing for other classes. It would be convenient to type arrays using the strongest (in sense of abstraction) common class from the entries. HOW: When detecting entry class mismatch (and not a unboxing or Number), find better common class; Object class should only be last resort. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815979#comment-17815979
]
Henri Biestro edited comment on JEXL-420 at 2/9/24 9:09 AM:
* Added specific CoercionException (subclass of ArithmeticException) to be
ignored during comparisons to allow fall through.
* Throw CoercionException from parse\{Number*} methods.
* Added consistency in treating NaN and '' in all cases
* Avoid going through parse(value.toString()) since type system is (seems)
stable enough
Commit
[f5bf27ca|https://github.com/apache/commons-jexl/commit/f5bf27caaf7c577ed039232e5db81bcb835bc228]
was (Author: henrib):
Commit
[f5bf27ca|https://github.com/apache/commons-jexl/commit/f5bf27caaf7c577ed039232e5db81bcb835bc228]
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-420.
Resolution: Fixed
Commit
[f5bf27ca|https://github.com/apache/commons-jexl/commit/f5bf27caaf7c577ed039232e5db81bcb835bc228]
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-420:
---
Fix Version/s: 3.3.1
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-420:
---
Affects Version/s: 3.3
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-420:
---
Assignee: Henri Biestro
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815639#comment-17815639
]
Henri Biestro commented on JEXL-420:
You are right; it makes more sense to follow the Java convention. The type
system is already lenient so it might as well be convenient and coherent.
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815391#comment-17815391
]
Henri Biestro edited comment on JEXL-420 at 2/7/24 6:24 PM:
It is always possible to use an arithmetic (ie a JexlArithmetic derived class)
of your choosing.
In your case, you might want to override the method:
{code:java}
public double toDouble(final Object val){code}
so it returns NaN when encountering a String.
Alternatively, you could override:
{code:java}
protected int compare(final Object left, final Object right, final JexlOperator
operator) {
try {
return super.compare(left, right, operator);
} catch(ArithmeticException xa) {
if (EQ.equals(operator)) {
return Integer.MAX_VALUE;
}
throw xa;
}
}{code}
to return a comparison value leading to false for the operator when catching an
ArithmeticException.
As for the general case, I'd rather not weaken the type system; the empty
string is already an (historic) convenient exception.
was (Author: henrib):
It is always possible to use an arithmetic (ie a JexlArithmetic derived class)
of your choosing.
In your case, you might want to override the method:
{code:java}
public double toDouble(final Object val){code}
so it returns NaN when encountering a String.
Alternatively, you could override:
{code:java}
protected int compare(final Object left, final Object right, final JexlOperator
operator){code}
to return a comparison value leading to false for the operator when catching an
ArithmeticException.
As for the general case, I'd rather not weaken the type system; the empty
string is already an (historic) convenient exception.
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815391#comment-17815391
]
Henri Biestro edited comment on JEXL-420 at 2/7/24 6:14 PM:
It is always possible to use an arithmetic (ie a JexlArithmetic derived class)
of your choosing.
In your case, you might want to override the method:
{code:java}
public double toDouble(final Object val){code}
so it returns NaN when encountering a String.
Alternatively, you could override:
{code:java}
protected int compare(final Object left, final Object right, final JexlOperator
operator){code}
to return a comparison value leading to false for the operator when catching an
ArithmeticException.
As for the general case, I'd rather not weaken the type system; the empty
string is already an (historic) convenient exception.
was (Author: henrib):
It is always possible to use an arithmetic (ie a JexlArithmetic derived class)
of your choosing.
In your case, you might want to override the method {code}public double
toDouble(final Object val){code} so it returns NaN when encountering a String.
As for the general case, I'd rather not weaken the type system; the empty
string is already an (historic) convenient exception.
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815391#comment-17815391
]
Henri Biestro commented on JEXL-420:
It is always possible to use an arithmetic (ie a JexlArithmetic derived class)
of your choosing.
In your case, you might want to override the method {code}public double
toDouble(final Object val){code} so it returns NaN when encountering a String.
As for the general case, I'd rather not weaken the type system; the empty
string is already an (historic) convenient exception.
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-419) Add permission syntax to allow class/method/field
[
https://issues.apache.org/jira/browse/JEXL-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-419.
Resolution: Fixed
Commit
[1aeec98|https://github.com/apache/commons-jexl/commit/1aeec98893992c799b42fcca7cb1a914a250b33e]
> Add permission syntax to allow class/method/field
> -
>
> Key: JEXL-419
> URL: https://issues.apache.org/jira/browse/JEXL-419
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> WHAT
> The class permissions can only deny access to methods/fields. It is
> cumbersome to use when only a few methods need to be allowed. Adding a syntax
> to explicitly allow class members would also enable easier composition from
> the RESTRICTED permissions.
> HOW
> Add a +/- (default is -) in front of class name in permissions for the parser
> to determine whether an allow or deny set is to be created.
> Example:
> {code}
> final String src = "java.lang { +Class { getName(); getSimpleName(); } }";
> final JexlPermissions p = RESTRICTED.compose(src);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-419) Add permission syntax to allow class/method/field
Henri Biestro created JEXL-419:
--
Summary: Add permission syntax to allow class/method/field
Key: JEXL-419
URL: https://issues.apache.org/jira/browse/JEXL-419
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.3
Reporter: Henri Biestro
Fix For: 3.3.1
WHAT
The class permissions can only deny access to methods/fields. It is cumbersome
to use when only a few methods need to be allowed. Adding a syntax to
explicitly allow class members would also enable easier composition from the
RESTRICTED permissions.
HOW
Add a +/- (default is -) in front of class name in permissions for the parser
to determine whether an allow or deny set is to be created.
Example:
{code}
final String src = "java.lang { +Class { getName(); getSimpleName(); } }";
final JexlPermissions p = RESTRICTED.compose(src);
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-419) Add permission syntax to allow class/method/field
[
https://issues.apache.org/jira/browse/JEXL-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-419:
---
Assignee: Henri Biestro
> Add permission syntax to allow class/method/field
> -
>
> Key: JEXL-419
> URL: https://issues.apache.org/jira/browse/JEXL-419
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> WHAT
> The class permissions can only deny access to methods/fields. It is
> cumbersome to use when only a few methods need to be allowed. Adding a syntax
> to explicitly allow class members would also enable easier composition from
> the RESTRICTED permissions.
> HOW
> Add a +/- (default is -) in front of class name in permissions for the parser
> to determine whether an allow or deny set is to be created.
> Example:
> {code}
> final String src = "java.lang { +Class { getName(); getSimpleName(); } }";
> final JexlPermissions p = RESTRICTED.compose(src);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (JEXL-398) Allow 'trailing commas' or ellipsis while defining array, map and set literals
[ https://issues.apache.org/jira/browse/JEXL-398 ]
Henri Biestro deleted comment on JEXL-398:
was (Author: garydgregory):
The build is red.
> Allow 'trailing commas' or ellipsis while defining array, map and set literals
> --
>
> Key: JEXL-398
> URL: https://issues.apache.org/jira/browse/JEXL-398
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> Allowing trailing commas in structured literals (array, set, map) as a
> convenient syntactic leniency. :)
> {code:java}
> let m = { "foo": 1, "bar": 2, };
> let a = [ 1, 2, ];
> let s = (1, 2, );{code}
> Using a trailing ellipsis (...) to alter the concrete class materialized as a
> convenient semantic shortcut.
> {code:java}
> let m = { "foo": 1, "bar": 2, ... }; // LinkedHashMap
> let a = [ 1, 2, ...]; // ArrayList
> let s = (1, 2, ...); // LinkedHashSet{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-398) Allow 'trailing commas' or ellipsis while defining array, map and set literals
[
https://issues.apache.org/jira/browse/JEXL-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-398.
Resolution: Fixed
Commit
[ca55aa8e|https://github.com/apache/commons-jexl/commit/ca55aa8e9ad4265e4a764ac3c7eab8f057bd5e1c]
Many thanks to Vincent for catching and fixing those :)
> Allow 'trailing commas' or ellipsis while defining array, map and set literals
> --
>
> Key: JEXL-398
> URL: https://issues.apache.org/jira/browse/JEXL-398
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> Allowing trailing commas in structured literals (array, set, map) as a
> convenient syntactic leniency. :)
> {code:java}
> let m = { "foo": 1, "bar": 2, };
> let a = [ 1, 2, ];
> let s = (1, 2, );{code}
> Using a trailing ellipsis (...) to alter the concrete class materialized as a
> convenient semantic shortcut.
> {code:java}
> let m = { "foo": 1, "bar": 2, ... }; // LinkedHashMap
> let a = [ 1, 2, ...]; // ArrayList
> let s = (1, 2, ...); // LinkedHashSet{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (JEXL-398) Allow 'trailing commas' or ellipsis while defining array, map and set literals
[
https://issues.apache.org/jira/browse/JEXL-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro reopened JEXL-398:
* Dot-expressions are no longer accepted as map keys;
* [,...] is no longer accepted;
* array/set/map builders never receive the extended argument
> Allow 'trailing commas' or ellipsis while defining array, map and set literals
> --
>
> Key: JEXL-398
> URL: https://issues.apache.org/jira/browse/JEXL-398
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> Allowing trailing commas in structured literals (array, set, map) as a
> convenient syntactic leniency. :)
> {code:java}
> let m = { "foo": 1, "bar": 2, };
> let a = [ 1, 2, ];
> let s = (1, 2, );{code}
> Using a trailing ellipsis (...) to alter the concrete class materialized as a
> convenient semantic shortcut.
> {code:java}
> let m = { "foo": 1, "bar": 2, ... }; // LinkedHashMap
> let a = [ 1, 2, ...]; // ArrayList
> let s = (1, 2, ...); // LinkedHashSet{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-412) Ambiguous syntax between namespace function call and map object definition.
[
https://issues.apache.org/jira/browse/JEXL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-412.
Resolution: Fixed
- Kinda restored previous behavior by looking at the whole ns:func sequence and
adding a grammar disambiguation for map entries.
Commit
[5072cd|https://github.com/apache/commons-jexl/commit/5072cdd36c1e80e0889f24133606a8cf6d7d4fe7]
> Ambiguous syntax between namespace function call and map object definition.
> ---
>
> Key: JEXL-412
> URL: https://issues.apache.org/jira/browse/JEXL-412
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> {code:java}
> function test() {
> return 'x';
> }
> let var1 = 'var1';
> let x = {
> var1: test(),
> 'var2': 1
> } {code}
> this code caused a parse error.
> Looks like the reason is the parser consider `var1: test()` as a namespace
> function call but here I just want define a map keyed by variable.
> Is it possible to disable 'namespace' feature to avoid this ambiguous syntax?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (JEXL-412) Ambiguous syntax between namespace function call and map object definition.
[
https://issues.apache.org/jira/browse/JEXL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro reopened JEXL-412:
Some people experience regressions; modules in particular declare namespaces.
> Ambiguous syntax between namespace function call and map object definition.
> ---
>
> Key: JEXL-412
> URL: https://issues.apache.org/jira/browse/JEXL-412
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> {code:java}
> function test() {
> return 'x';
> }
> let var1 = 'var1';
> let x = {
> var1: test(),
> 'var2': 1
> } {code}
> this code caused a parse error.
> Looks like the reason is the parser consider `var1: test()` as a namespace
> function call but here I just want define a map keyed by variable.
> Is it possible to disable 'namespace' feature to avoid this ambiguous syntax?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790946#comment-17790946 ] Henri Biestro commented on JEXL-414: As with any benchmark, I'd take the result with a grain of salt. :-) A tight loop of 500 create/execute of a constant script definitely biases the result by emphasizing cache performance wrt actual code parsing/execution. Anyhow, the code as is allows you to choose. Since you must create a JexlBuilder and set a few options to use JEXL, you might as well take that opportunity to use the cache implementation you want. Add the eventual dependency to your project, copy the ConcurrentCache code from JEXL test to some of your packages and you're good to go. > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-417) JexlArithmetic looses precision during arithmetic operator execution
[
https://issues.apache.org/jira/browse/JEXL-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-417.
Assignee: Henri Biestro
Resolution: Fixed
Commit
[5ab46d|https://github.com/apache/commons-jexl/commit/5ab46d9935c992eab7ab7dce4f1fde196976c789]
and
[d894074||https://github.com/apache/commons-jexl/commit/d894074fb485c8f23ca5111ad1470dc6018bc9fb]
> JexlArithmetic looses precision during arithmetic operator execution
>
>
> Key: JEXL-417
> URL: https://issues.apache.org/jira/browse/JEXL-417
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
> convert it to double/long during arithmetic operator execution leading to
> unexpected results.
> See
> [discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
> {code:java}(56.1B - 12) / 12 = 3.6B != 3{code}
> User intent about precision should be maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-417) JexlArithmetic looses precision during arithmetic operator execution
[
https://issues.apache.org/jira/browse/JEXL-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790745#comment-17790745
]
Henri Biestro edited comment on JEXL-417 at 11/28/23 8:45 PM:
--
Commit
[5ab46d|https://github.com/apache/commons-jexl/commit/5ab46d9935c992eab7ab7dce4f1fde196976c789]
and
[d894074|https://github.com/apache/commons-jexl/commit/d894074fb485c8f23ca5111ad1470dc6018bc9fb]
was (Author: henrib):
Commit
[5ab46d|https://github.com/apache/commons-jexl/commit/5ab46d9935c992eab7ab7dce4f1fde196976c789]
and
[d894074||https://github.com/apache/commons-jexl/commit/d894074fb485c8f23ca5111ad1470dc6018bc9fb]
> JexlArithmetic looses precision during arithmetic operator execution
>
>
> Key: JEXL-417
> URL: https://issues.apache.org/jira/browse/JEXL-417
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
> convert it to double/long during arithmetic operator execution leading to
> unexpected results.
> See
> [discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
> {code:java}(56.1B - 12) / 12 = 3.6B != 3{code}
> User intent about precision should be maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-414. Resolution: Fixed > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-417) JexlArithmetic looses precision during arithmetic operator execution
[
https://issues.apache.org/jira/browse/JEXL-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-417:
---
Description:
When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
convert it to double/long during arithmetic operator execution leading to
unexpected results.
See
[discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
{code:java}(56.1B - 12) / 12 = 3.6B != 3{code}
User intent about precision should be maintained.
was:
When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
convert it to double/long during arithmetic operator execution leading to
unexpected results.
See
[discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
{code:java}
(56.1B - 12) / 12 = 3.6B != 3
{code}
User intent about precision should be maintained.
> JexlArithmetic looses precision during arithmetic operator execution
>
>
> Key: JEXL-417
> URL: https://issues.apache.org/jira/browse/JEXL-417
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
> convert it to double/long during arithmetic operator execution leading to
> unexpected results.
> See
> [discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
> {code:java}(56.1B - 12) / 12 = 3.6B != 3{code}
> User intent about precision should be maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-417) JexlArithmetic looses precision during arithmetic operator execution
[
https://issues.apache.org/jira/browse/JEXL-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-417:
---
Description:
When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
convert it to double/long during arithmetic operator execution leading to
unexpected results.
See
[discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
{code:java}
(56.1B - 12) / 12 = 3.6B != 3
{code}
User intent about precision should be maintained.
was:
When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
convert it to double/long during arithmetic operator execution leading to
unexpected results.
(56.1B - 12) / 12 = 3.6
User intent about precision should be maintained.
> JexlArithmetic looses precision during arithmetic operator execution
>
>
> Key: JEXL-417
> URL: https://issues.apache.org/jira/browse/JEXL-417
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
> convert it to double/long during arithmetic operator execution leading to
> unexpected results.
> See
> [discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
> {code:java}
> (56.1B - 12) / 12 = 3.6B != 3
> {code}
> User intent about precision should be maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-417) JexlArithmetic looses precision during arithmetic operator execution
Henri Biestro created JEXL-417: -- Summary: JexlArithmetic looses precision during arithmetic operator execution Key: JEXL-417 URL: https://issues.apache.org/jira/browse/JEXL-417 Project: Commons JEXL Issue Type: Bug Affects Versions: 3.3 Reporter: Henri Biestro Fix For: 3.3.1 When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and convert it to double/long during arithmetic operator execution leading to unexpected results. (56.1B - 12) / 12 = 3.6 User intent about precision should be maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-411) Leading zeroes in floating point numbers should be optional
[ https://issues.apache.org/jira/browse/JEXL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789513#comment-17789513 ] Henri Biestro commented on JEXL-411: The logic for parsing is described in the [Parser.jjt|https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/parser/Parser.jjt] grammar, a [Javacc|https://javacc.github.io/javacc/tutorials/] grammar. I could not find an easy way to introduce the syntax you seek; controlling the production of float literals by adding states quickly became a tangled mess. May be you'll find a cleaner way. > Leading zeroes in floating point numbers should be optional > --- > > Key: JEXL-411 > URL: https://issues.apache.org/jira/browse/JEXL-411 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Felix Rudolphi >Priority: Minor > > When parsing arithmetic expressions, JEXL should be able to deal with omitted > leading zeroes in floating point numbers between -1.0 and 1.0, e.g. ".1" > "(1+0.1)*2" evaluates to 2.2, while "(1+.1)*2" gives a parsing error. In > Java, this is valid code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-411) Leading zeroes in floating point numbers should be optional
[ https://issues.apache.org/jira/browse/JEXL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789206#comment-17789206 ] Henri Biestro commented on JEXL-411: Tried to modify the grammar but this is not easy; JEXL allows 'x.3' as an (almost) equivalent for 'x[3]' , lexical states are probably required. If you've submit a PR, I'll gladly look at it. > Leading zeroes in floating point numbers should be optional > --- > > Key: JEXL-411 > URL: https://issues.apache.org/jira/browse/JEXL-411 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Felix Rudolphi >Priority: Minor > > When parsing arithmetic expressions, JEXL should be able to deal with omitted > leading zeroes in floating point numbers between -1.0 and 1.0, e.g. ".1" > "(1+0.1)*2" evaluates to 2.2, while "(1+.1)*2" gives a parsing error. In > Java, this is valid code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-416) Null-valued pragma throws NPE in 3.3
[
https://issues.apache.org/jira/browse/JEXL-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-416.
Resolution: Fixed
Thanks for catching this regression.
Commit
[0a2e943|https://github.com/apache/commons-jexl/commit/0a2e94323a642cc224b1b97ce28e87aaf073408e]
> Null-valued pragma throws NPE in 3.3
>
>
> Key: JEXL-416
> URL: https://issues.apache.org/jira/browse/JEXL-416
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: JEXL 3.3
> Java 21 (21+35) Red Hat, Inc.
> Linux 5.15.133.1-microsoft-standard-WSL2 (amd64)
>Reporter: William Price
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> Version 3.2.1 seemed to allow {{null}} as a value for pragmas, but version
> 3.3 throws NPE. I'm not necessarily advocating for null pragma values, but
> it's a behavior regression due to the use of {{{}TreeMap::merge{}}}. Even if
> disallowing nulls was desired, it should be a JexlException not NPE.
> Passes on 3.2.1:
> {code:java}
> var script = engine.createScript("#pragma myNull null\n");
> var pragmas = script.getPragmas();
> assertTrue(pragmas.containsKey("myNull"), "pragma key present?");
> assertNull(pragmas.get("myNull"), "expected null value"); {code}
> Behavior on 3.3:
> {code:java}
> assertThrows(
> NullPointerException.class,
> () -> engine.createScript("#pragma myNull null\n"));
> {code}
> {noformat}
> java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:233)
> at java.base/java.util.TreeMap.merge(TreeMap.java:743)
> at
> org.apache.commons.jexl3.parser.JexlParser.declarePragma(JexlParser.java:557)
> at org.apache.commons.jexl3.parser.Parser.Pragma(Parser.java:1246)
> at org.apache.commons.jexl3.parser.Parser.JexlScript(Parser.java:63)
> at org.apache.commons.jexl3.parser.Parser.parse(Parser.java:25)
> at org.apache.commons.jexl3.internal.Engine.parse(Engine.java:1009)
> at
> org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:617)
> at org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:69)
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:375)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-416) Null-valued pragma throws NPE in 3.3
[
https://issues.apache.org/jira/browse/JEXL-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-416:
---
Assignee: Henri Biestro
> Null-valued pragma throws NPE in 3.3
>
>
> Key: JEXL-416
> URL: https://issues.apache.org/jira/browse/JEXL-416
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: JEXL 3.3
> Java 21 (21+35) Red Hat, Inc.
> Linux 5.15.133.1-microsoft-standard-WSL2 (amd64)
>Reporter: William Price
>Assignee: Henri Biestro
>Priority: Major
>
> Version 3.2.1 seemed to allow {{null}} as a value for pragmas, but version
> 3.3 throws NPE. I'm not necessarily advocating for null pragma values, but
> it's a behavior regression due to the use of {{{}TreeMap::merge{}}}. Even if
> disallowing nulls was desired, it should be a JexlException not NPE.
> Passes on 3.2.1:
> {code:java}
> var script = engine.createScript("#pragma myNull null\n");
> var pragmas = script.getPragmas();
> assertTrue(pragmas.containsKey("myNull"), "pragma key present?");
> assertNull(pragmas.get("myNull"), "expected null value"); {code}
> Behavior on 3.3:
> {code:java}
> assertThrows(
> NullPointerException.class,
> () -> engine.createScript("#pragma myNull null\n"));
> {code}
> {noformat}
> java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:233)
> at java.base/java.util.TreeMap.merge(TreeMap.java:743)
> at
> org.apache.commons.jexl3.parser.JexlParser.declarePragma(JexlParser.java:557)
> at org.apache.commons.jexl3.parser.Parser.Pragma(Parser.java:1246)
> at org.apache.commons.jexl3.parser.Parser.JexlScript(Parser.java:63)
> at org.apache.commons.jexl3.parser.Parser.parse(Parser.java:25)
> at org.apache.commons.jexl3.internal.Engine.parse(Engine.java:1009)
> at
> org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:617)
> at org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:69)
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:375)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-416) Null-valued pragma throws NPE in 3.3
[
https://issues.apache.org/jira/browse/JEXL-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-416:
---
Fix Version/s: 3.3.1
> Null-valued pragma throws NPE in 3.3
>
>
> Key: JEXL-416
> URL: https://issues.apache.org/jira/browse/JEXL-416
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: JEXL 3.3
> Java 21 (21+35) Red Hat, Inc.
> Linux 5.15.133.1-microsoft-standard-WSL2 (amd64)
>Reporter: William Price
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> Version 3.2.1 seemed to allow {{null}} as a value for pragmas, but version
> 3.3 throws NPE. I'm not necessarily advocating for null pragma values, but
> it's a behavior regression due to the use of {{{}TreeMap::merge{}}}. Even if
> disallowing nulls was desired, it should be a JexlException not NPE.
> Passes on 3.2.1:
> {code:java}
> var script = engine.createScript("#pragma myNull null\n");
> var pragmas = script.getPragmas();
> assertTrue(pragmas.containsKey("myNull"), "pragma key present?");
> assertNull(pragmas.get("myNull"), "expected null value"); {code}
> Behavior on 3.3:
> {code:java}
> assertThrows(
> NullPointerException.class,
> () -> engine.createScript("#pragma myNull null\n"));
> {code}
> {noformat}
> java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:233)
> at java.base/java.util.TreeMap.merge(TreeMap.java:743)
> at
> org.apache.commons.jexl3.parser.JexlParser.declarePragma(JexlParser.java:557)
> at org.apache.commons.jexl3.parser.Parser.Pragma(Parser.java:1246)
> at org.apache.commons.jexl3.parser.Parser.JexlScript(Parser.java:63)
> at org.apache.commons.jexl3.parser.Parser.parse(Parser.java:25)
> at org.apache.commons.jexl3.internal.Engine.parse(Engine.java:1009)
> at
> org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:617)
> at org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:69)
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:375)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789193#comment-17789193 ] Henri Biestro commented on JEXL-414: I've added a rough performance evaluation test class and another JexlCache implementation to compare to. I played with some parameters to get a sense of it but I feel confident the cache handling only has a small impact on overall performance. Let me know what you find. Commit [b36890|https://github.com/apache/commons-jexl/commit/b36890794bcbef32acc6b11899e5848f10905609] > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-414: --- Fix Version/s: 3.3.1 > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787449#comment-17787449 ] Henri Biestro edited comment on JEXL-414 at 11/18/23 4:32 AM: -- I've dropped a [version|https://github.com/apache/commons-jexl/commit/e4b6b3956ed4f7e1404e4523c6629216b2384476] that exposes a cache interface and method factories to create either synchronous or concurrent caches. The former uses a linkedhashmap but fully synchronized (to correct the initial bug) whilst the latter uses a concurrentlinkedhashmap-lru (from Google). Since this introduces a new dependency, it would be nice to ensure this improves concurrency; I suspect that under low contention, there is no disadvantage to the synchronized version. I may revise this to let the concurrent version in the test directory to avoid the new dependency; it might also be better to use Cafeine but that is an even bigger dependency. Let me know what you think and find. was (Author: henrib): I've dropped a [version|https://github.com/apache/commons-jexl/commit/e4b6b3956ed4f7e1404e4523c6629216b2384476] that exposes a cache interface and method factories to create either synchronous or concurrent caches. The former uses a linkedhashmap but fully synchronized (to correct the initial bug) whilst the latter uses a concurrentlinkedhashmap-lru (from Google). Since this introduces a new dependency, it would be nice to ensure this improves concurrency; I suspect that under low contention, there is no disadvantage to the synchronized version. I may revise this to let the concurrent version in the test directory to avoid the new dependency; it might also be better to use Cafeine but that is an even bigger dependency. > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787449#comment-17787449 ] Henri Biestro commented on JEXL-414: I've dropped a [version|https://github.com/apache/commons-jexl/commit/e4b6b3956ed4f7e1404e4523c6629216b2384476] that exposes a cache interface and method factories to create either synchronous or concurrent caches. The former uses a linkedhashmap but fully synchronized (to correct the initial bug) whilst the latter uses a concurrentlinkedhashmap-lru (from Google). Since this introduces a new dependency, it would be nice to ensure this improves concurrency; I suspect that under low contention, there is no disadvantage to the synchronized version. I may revise this to let the concurrent version in the test directory to avoid the new dependency; it might also be better to use Cafeine but that is an even bigger dependency. > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-415) incorrect template eval result
[
https://issues.apache.org/jira/browse/JEXL-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-415.
Fix Version/s: 3.3.1
Resolution: Fixed
Thanks for the report.
Commit
[b2431dd4|https://github.com/apache/commons-jexl/commit/b2431dd4bdc5ede8a2a7b163d039b3e8056c3110]
> incorrect template eval result
> --
>
> Key: JEXL-415
> URL: https://issues.apache.org/jira/browse/JEXL-415
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> The following code should return "#1", but actually returns "#${a}"
> {code:java}
> var a = 1;
> return `#${a}`; {code}
> I checked the syntax doc, seems there is no such rule.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-415) incorrect template eval result
[
https://issues.apache.org/jira/browse/JEXL-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-415:
---
Assignee: Henri Biestro
> incorrect template eval result
> --
>
> Key: JEXL-415
> URL: https://issues.apache.org/jira/browse/JEXL-415
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> The following code should return "#1", but actually returns "#${a}"
> {code:java}
> var a = 1;
> return `#${a}`; {code}
> I checked the syntax doc, seems there is no such rule.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787444#comment-17787444 ] Henri Biestro commented on JEXL-414: Very good catch and analysis, thank you. A correction is in the works. > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-414: --- Assignee: Henri Biestro > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-414: --- Description: I found the SoftCache used from within the JEXL class Engine to be very relevant for overall performance (depending on the application) on the one hand, but on the other hand it may suffer from race conditions. While solid efford was taken to protect it from race conditions by surrounding access using a ReadWriteLock, parallel read access actually do reach out on a LinkedHashMap having set accessOrder=true. This means that on every potentially parallel, non serialized invocation of LinkedHashMap#get the order of elements is modified to bring the last accessed element down to the tail of the internal linked list structure and modCount is incremented. In our application rendering web templates, we observe multiple of 1 access on the SoftCache per page impression and multiple of 10 page impressions per second per JVM instance. Not sure whether this is result of race condition claimed above, in heapdumps of that application I observed the LinkedHashMap used within SoftCache having a size of ~9500 elements while the SoftCache#size is set to limit the cache to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with arbitrary giant positive or negative numbers, telling me it has overflown already after some hours of application uptime. was: I found the SoftCache used from within the Jexcel class Engine to be very relevant for overall performance (depending on the application) on the one hand, but on the other hand it may suffer from race conditions. While solid efford was taken to protect it from race conditions by surrounding access using a ReadWriteLock, parallel read access actually do reach out on a LinkedHashMap having set accessOrder=true. This means that on every potentially parallel, non serialized invocation of LinkedHashMap#get the order of elements is modified to bring the last accessed element down to the tail of the internal linked list structure and modCount is incremented. In our application rendering web templates, we observe multiple of 1 access on the SoftCache per page impression and multiple of 10 page impressions per second per JVM instance. Not sure whether this is result of race condition claimed above, in heapdumps of that application I observed the LinkedHashMap used within SoftCache having a size of ~9500 elements while the SoftCache#size is set to limit the cache to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with arbitrary giant positive or negative numbers, telling me it has overflown already after some hours of application uptime. > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Priority: Major > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-413) Allow const capture runtime option
[
https://issues.apache.org/jira/browse/JEXL-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-413.
Assignee: Henri Biestro
Resolution: Fixed
Commit
[e0e3e690|https://github.com/apache/commons-jexl/commit/e0e3e690fa86312896ca313f61a10321fc24f899]
> Allow const capture runtime option
> --
>
> Key: JEXL-413
> URL: https://issues.apache.org/jira/browse/JEXL-413
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> As a follow-up on JEXL-401, add a runtime option (JexlOption) for 'const
> capture'.
> This is meant to ease migrating scripts that would otherwise fail at creation
> time if the engine is configured with the const-capture feature.
> By allowing it as an option, it is easy to add it to the code and make it
> fail at execution time as in:
> {code}#pragma jexl.options '+constCapture'{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-413) Allow const capture runtime option
Henri Biestro created JEXL-413:
--
Summary: Allow const capture runtime option
Key: JEXL-413
URL: https://issues.apache.org/jira/browse/JEXL-413
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.3
Reporter: Henri Biestro
Fix For: 3.3.1
As a follow-up on JEXL-401, add a runtime option (JexlOption) for 'const
capture'.
This is meant to ease migrating scripts that would otherwise fail at creation
time if the engine is configured with the const-capture feature.
By allowing it as an option, it is easy to add it to the code and make it fail
at execution time as in:
{code}#pragma jexl.options '+constCapture'{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-412) Ambiguous syntax between namespace function call and map object definition.
[
https://issues.apache.org/jira/browse/JEXL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-412.
Resolution: Fixed
> Ambiguous syntax between namespace function call and map object definition.
> ---
>
> Key: JEXL-412
> URL: https://issues.apache.org/jira/browse/JEXL-412
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> {code:java}
> function test() {
> return 'x';
> }
> let var1 = 'var1';
> let x = {
> var1: test(),
> 'var2': 1
> } {code}
> this code caused a parse error.
> Looks like the reason is the parser consider `var1: test()` as a namespace
> function call but here I just want define a map keyed by variable.
> Is it possible to disable 'namespace' feature to avoid this ambiguous syntax?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-412) Ambiguous syntax between namespace function call and map object definition.
[
https://issues.apache.org/jira/browse/JEXL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782545#comment-17782545
]
Henri Biestro commented on JEXL-412:
Commit
[4692b3c|https://github.com/apache/commons-jexl/commit/4692b3c606baca56a2d2f0a4cb34faa85f920eee]
> Ambiguous syntax between namespace function call and map object definition.
> ---
>
> Key: JEXL-412
> URL: https://issues.apache.org/jira/browse/JEXL-412
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> {code:java}
> function test() {
> return 'x';
> }
> let var1 = 'var1';
> let x = {
> var1: test(),
> 'var2': 1
> } {code}
> this code caused a parse error.
> Looks like the reason is the parser consider `var1: test()` as a namespace
> function call but here I just want define a map keyed by variable.
> Is it possible to disable 'namespace' feature to avoid this ambiguous syntax?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-412) Ambiguous syntax between namespace function call and map object definition.
[
https://issues.apache.org/jira/browse/JEXL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-412:
---
Assignee: Henri Biestro
> Ambiguous syntax between namespace function call and map object definition.
> ---
>
> Key: JEXL-412
> URL: https://issues.apache.org/jira/browse/JEXL-412
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> {code:java}
> function test() {
> return 'x';
> }
> let var1 = 'var1';
> let x = {
> var1: test(),
> 'var2': 1
> } {code}
> this code caused a parse error.
> Looks like the reason is the parser consider `var1: test()` as a namespace
> function call but here I just want define a map keyed by variable.
> Is it possible to disable 'namespace' feature to avoid this ambiguous syntax?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-412) Ambiguous syntax between namespace function call and map object definition.
[
https://issues.apache.org/jira/browse/JEXL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-412:
---
Fix Version/s: 3.3.1
> Ambiguous syntax between namespace function call and map object definition.
> ---
>
> Key: JEXL-412
> URL: https://issues.apache.org/jira/browse/JEXL-412
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Priority: Minor
> Fix For: 3.3.1
>
>
> {code:java}
> function test() {
> return 'x';
> }
> let var1 = 'var1';
> let x = {
> var1: test(),
> 'var2': 1
> } {code}
> this code caused a parse error.
> Looks like the reason is the parser consider `var1: test()` as a namespace
> function call but here I just want define a map keyed by variable.
> Is it possible to disable 'namespace' feature to avoid this ambiguous syntax?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-412) Ambiguous syntax between namespace function call and map object definition.
[
https://issues.apache.org/jira/browse/JEXL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-412:
---
Affects Version/s: 3.3
> Ambiguous syntax between namespace function call and map object definition.
> ---
>
> Key: JEXL-412
> URL: https://issues.apache.org/jira/browse/JEXL-412
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Priority: Minor
>
> {code:java}
> function test() {
> return 'x';
> }
> let var1 = 'var1';
> let x = {
> var1: test(),
> 'var2': 1
> } {code}
> this code caused a parse error.
> Looks like the reason is the parser consider `var1: test()` as a namespace
> function call but here I just want define a map keyed by variable.
> Is it possible to disable 'namespace' feature to avoid this ambiguous syntax?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-412) Ambiguous syntax between namespace function call and map object definition.
[
https://issues.apache.org/jira/browse/JEXL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782143#comment-17782143
]
Henri Biestro commented on JEXL-412:
I'll look into it. As a workaround, there is a 'syntactic hint' for this case,
add a space before the ':' as in '\{ var1 : test() }'.
> Ambiguous syntax between namespace function call and map object definition.
> ---
>
> Key: JEXL-412
> URL: https://issues.apache.org/jira/browse/JEXL-412
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Priority: Minor
>
> {code:java}
> function test() {
> return 'x';
> }
> let var1 = 'var1';
> let x = {
> var1: test(),
> 'var2': 1
> } {code}
> this code caused a parse error.
> Looks like the reason is the parser consider `var1: test()` as a namespace
> function call but here I just want define a map keyed by variable.
> Is it possible to disable 'namespace' feature to avoid this ambiguous syntax?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-408) Using JexlFeatures is tedious
[ https://issues.apache.org/jira/browse/JEXL-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-408. Resolution: Fixed > Using JexlFeatures is tedious > - > > Key: JEXL-408 > URL: https://issues.apache.org/jira/browse/JEXL-408 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The JexlFeatures class is not very easy to configure if one wants to disable > all but one or two features. This is because the only constructor includes > many features by default. These all have to be disabled individually. > It would be useful to have a constructor that disabled all the features; > these could then be enabled individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-410) JexlFeatures: ctor does not enable all features
[ https://issues.apache.org/jira/browse/JEXL-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-410. Resolution: Fixed > JexlFeatures: ctor does not enable all features > --- > > Key: JEXL-410 > URL: https://issues.apache.org/jira/browse/JEXL-410 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The ctor Javadoc says it "Creates an all-features-enabled instance." > However, that is not the case, as several flags are not included: > REGISTER > LEXICAL > LEXICAL_SHADE > FAT_ARROW > CONST_CAPTURE > (RESERVED is also omitted, but it is not a feature flag - it only indicates > reservedNames is non-empty) > If these are intentional omissions, they should be documented as such. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-408) Using JexlFeatures is tedious
[ https://issues.apache.org/jira/browse/JEXL-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1988#comment-1988 ] Henri Biestro commented on JEXL-408: - Restored protected JexlFeatures constructor, documented the caveats. Trying to avoid thread-adverse arguments will only reduce functionality with no real thread-safety insurance. (see [discussion|https://lists.apache.org/thread/bhxn6tko33szmrmssz3gng6zgtf6gty8]). Commit [2edb82|https://github.com/apache/commons-jexl/commit/2edb826947370d80c5c7826f0b5b6c713bdddb7]. > Using JexlFeatures is tedious > - > > Key: JEXL-408 > URL: https://issues.apache.org/jira/browse/JEXL-408 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The JexlFeatures class is not very easy to configure if one wants to disable > all but one or two features. This is because the only constructor includes > many features by default. These all have to be disabled individually. > It would be useful to have a constructor that disabled all the features; > these could then be enabled individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-408) Using JexlFeatures is tedious
[ https://issues.apache.org/jira/browse/JEXL-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1847#comment-1847 ] Henri Biestro commented on JEXL-408: - Renamed create() to createNone(); - Added createAll(); - Improved createScript(); - Updated Javadoc & tests; Commit [5451c3|https://github.com/apache/commons-jexl/commit/5451c30530af8dc1fc145bbee9ce23df73041b9c]. > Using JexlFeatures is tedious > - > > Key: JEXL-408 > URL: https://issues.apache.org/jira/browse/JEXL-408 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The JexlFeatures class is not very easy to configure if one wants to disable > all but one or two features. This is because the only constructor includes > many features by default. These all have to be disabled individually. > It would be useful to have a constructor that disabled all the features; > these could then be enabled individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-410) JexlFeatures: ctor does not enable all features
[ https://issues.apache.org/jira/browse/JEXL-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1223#comment-1223 ] Henri Biestro commented on JEXL-410: I'd rather correct the Javadoc than break production scripts. As to why not changing the default flags (again), even enabling new more permissive ones, this is to avoid breaking upwards syntactic compatibility in a micro release. The known pitfall is the following scenario. To check 3.3.1, one may install it on a dev environment; someone 'discovers' new syntactic elements are permitted and starts using them in dev. Scripts are then moved to staging/qa (or even worse, production) environments that are still in 3.3 and failures ensues. Lesson (hard) learnt. > JexlFeatures: ctor does not enable all features > --- > > Key: JEXL-410 > URL: https://issues.apache.org/jira/browse/JEXL-410 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The ctor Javadoc says it "Creates an all-features-enabled instance." > However, that is not the case, as several flags are not included: > REGISTER > LEXICAL > LEXICAL_SHADE > FAT_ARROW > CONST_CAPTURE > (RESERVED is also omitted, but it is not a feature flag - it only indicates > reservedNames is non-empty) > If these are intentional omissions, they should be documented as such. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-410) JexlFeatures: ctor does not enable all features
[ https://issues.apache.org/jira/browse/JEXL-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1223#comment-1223 ] Henri Biestro edited comment on JEXL-410 at 10/19/23 12:00 PM: --- I'd rather correct the Javadoc than break production scripts. As to why not changing the default flags (again), even enabling new more permissive ones, this is to avoid breaking upwards syntactic compatibility in a micro release. The known pitfall is the following scenario. To check 3.3.1, one may install it on a dev environment; someone 'discovers' new syntactic elements are permitted and starts using them in dev. Scripts are then moved to staging/qa (or even worse, production) environments that are still in 3.3 and failures ensue. Lesson (hard) learnt. was (Author: henrib): I'd rather correct the Javadoc than break production scripts. As to why not changing the default flags (again), even enabling new more permissive ones, this is to avoid breaking upwards syntactic compatibility in a micro release. The known pitfall is the following scenario. To check 3.3.1, one may install it on a dev environment; someone 'discovers' new syntactic elements are permitted and starts using them in dev. Scripts are then moved to staging/qa (or even worse, production) environments that are still in 3.3 and failures ensues. Lesson (hard) learnt. > JexlFeatures: ctor does not enable all features > --- > > Key: JEXL-410 > URL: https://issues.apache.org/jira/browse/JEXL-410 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The ctor Javadoc says it "Creates an all-features-enabled instance." > However, that is not the case, as several flags are not included: > REGISTER > LEXICAL > LEXICAL_SHADE > FAT_ARROW > CONST_CAPTURE > (RESERVED is also omitted, but it is not a feature flag - it only indicates > reservedNames is non-empty) > If these are intentional omissions, they should be documented as such. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-408) Using JexlFeatures is tedious
[ https://issues.apache.org/jira/browse/JEXL-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776823#comment-17776823 ] Henri Biestro commented on JEXL-408: I must mis-understand what 'tedious' means. Since the JexlFeatures instance can be created once and reused by multiple JexlBuilder if (ever) needed, knowing that being explicit is better than relying on defaults and that this API is fluent, are we talking about the 1 or 2 explicit calls (like .constCapture(true)) needed ? I can revert the change if this suits you better but will not add the flags to the default constructor since these would potentially break backwards runtime compatibility. > Using JexlFeatures is tedious > - > > Key: JEXL-408 > URL: https://issues.apache.org/jira/browse/JEXL-408 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The JexlFeatures class is not very easy to configure if one wants to disable > all but one or two features. This is because the only constructor includes > many features by default. These all have to be disabled individually. > It would be useful to have a constructor that disabled all the features; > these could then be enabled individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-410) JexlFeatures: ctor does not enable all features
[ https://issues.apache.org/jira/browse/JEXL-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776681#comment-17776681 ] Henri Biestro commented on JEXL-410: Updated Javadoc in commit [41d6999|https://github.com/apache/commons-jexl/commit/41d6999840bc54ad4b044924060406738337ffeb] > JexlFeatures: ctor does not enable all features > --- > > Key: JEXL-410 > URL: https://issues.apache.org/jira/browse/JEXL-410 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The ctor Javadoc says it "Creates an all-features-enabled instance." > However, that is not the case, as several flags are not included: > REGISTER > LEXICAL > LEXICAL_SHADE > FAT_ARROW > CONST_CAPTURE > (RESERVED is also omitted, but it is not a feature flag - it only indicates > reservedNames is non-empty) > If these are intentional omissions, they should be documented as such. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-409) Disable LEXICAL should disable LEXICAL_SHADE
[ https://issues.apache.org/jira/browse/JEXL-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-409. Resolution: Fixed > Disable LEXICAL should disable LEXICAL_SHADE > > > Key: JEXL-409 > URL: https://issues.apache.org/jira/browse/JEXL-409 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The code to enable LEXICAL_SHADE automatically enables LEXICAL. > However the code to disable LEXICAL does not disable LEXICAL_SHADE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-409) Disable LEXICAL should disable LEXICAL_SHADE
[ https://issues.apache.org/jira/browse/JEXL-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776679#comment-17776679 ] Henri Biestro commented on JEXL-409: Fixed in commit [41d6999|https://github.com/apache/commons-jexl/commit/41d6999840bc54ad4b044924060406738337ffeb] > Disable LEXICAL should disable LEXICAL_SHADE > > > Key: JEXL-409 > URL: https://issues.apache.org/jira/browse/JEXL-409 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The code to enable LEXICAL_SHADE automatically enables LEXICAL. > However the code to disable LEXICAL does not disable LEXICAL_SHADE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-408) Using JexlFeatures is tedious
[ https://issues.apache.org/jira/browse/JEXL-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776678#comment-17776678 ] Henri Biestro commented on JEXL-408: Added JexlFeatures#create() method to create new empty JexlFeatures instance. Commit [41d6999|https://github.com/apache/commons-jexl/commit/41d6999840bc54ad4b044924060406738337ffeb] > Using JexlFeatures is tedious > - > > Key: JEXL-408 > URL: https://issues.apache.org/jira/browse/JEXL-408 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The JexlFeatures class is not very easy to configure if one wants to disable > all but one or two features. This is because the only constructor includes > many features by default. These all have to be disabled individually. > It would be useful to have a constructor that disabled all the features; > these could then be enabled individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-408) Using JexlFeatures is tedious
[ https://issues.apache.org/jira/browse/JEXL-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-408: --- Assignee: Henri Biestro > Using JexlFeatures is tedious > - > > Key: JEXL-408 > URL: https://issues.apache.org/jira/browse/JEXL-408 > Project: Commons JEXL > Issue Type: Improvement >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > > The JexlFeatures class is not very easy to configure if one wants to disable > all but one or two features. This is because the only constructor includes > many features by default. These all have to be disabled individually. > It would be useful to have a constructor that disabled all the features; > these could then be enabled individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-409) Disable LEXICAL should disable LEXICAL_SHADE
[ https://issues.apache.org/jira/browse/JEXL-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-409: --- Affects Version/s: 3.3 > Disable LEXICAL should disable LEXICAL_SHADE > > > Key: JEXL-409 > URL: https://issues.apache.org/jira/browse/JEXL-409 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The code to enable LEXICAL_SHADE automatically enables LEXICAL. > However the code to disable LEXICAL does not disable LEXICAL_SHADE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-408) Using JexlFeatures is tedious
[ https://issues.apache.org/jira/browse/JEXL-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-408: --- Affects Version/s: 3.3 > Using JexlFeatures is tedious > - > > Key: JEXL-408 > URL: https://issues.apache.org/jira/browse/JEXL-408 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The JexlFeatures class is not very easy to configure if one wants to disable > all but one or two features. This is because the only constructor includes > many features by default. These all have to be disabled individually. > It would be useful to have a constructor that disabled all the features; > these could then be enabled individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-410) JexlFeatures: ctor does not enable all features
[ https://issues.apache.org/jira/browse/JEXL-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-410: --- Affects Version/s: 3.3 > JexlFeatures: ctor does not enable all features > --- > > Key: JEXL-410 > URL: https://issues.apache.org/jira/browse/JEXL-410 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The ctor Javadoc says it "Creates an all-features-enabled instance." > However, that is not the case, as several flags are not included: > REGISTER > LEXICAL > LEXICAL_SHADE > FAT_ARROW > CONST_CAPTURE > (RESERVED is also omitted, but it is not a feature flag - it only indicates > reservedNames is non-empty) > If these are intentional omissions, they should be documented as such. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-410) JexlFeatures: ctor does not enable all features
[ https://issues.apache.org/jira/browse/JEXL-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-410: --- Fix Version/s: 3.3.1 > JexlFeatures: ctor does not enable all features > --- > > Key: JEXL-410 > URL: https://issues.apache.org/jira/browse/JEXL-410 > Project: Commons JEXL > Issue Type: Bug >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The ctor Javadoc says it "Creates an all-features-enabled instance." > However, that is not the case, as several flags are not included: > REGISTER > LEXICAL > LEXICAL_SHADE > FAT_ARROW > CONST_CAPTURE > (RESERVED is also omitted, but it is not a feature flag - it only indicates > reservedNames is non-empty) > If these are intentional omissions, they should be documented as such. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-410) JexlFeatures: ctor does not enable all features
[ https://issues.apache.org/jira/browse/JEXL-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-410: --- Assignee: Henri Biestro > JexlFeatures: ctor does not enable all features > --- > > Key: JEXL-410 > URL: https://issues.apache.org/jira/browse/JEXL-410 > Project: Commons JEXL > Issue Type: Bug >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > > The ctor Javadoc says it "Creates an all-features-enabled instance." > However, that is not the case, as several flags are not included: > REGISTER > LEXICAL > LEXICAL_SHADE > FAT_ARROW > CONST_CAPTURE > (RESERVED is also omitted, but it is not a feature flag - it only indicates > reservedNames is non-empty) > If these are intentional omissions, they should be documented as such. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-409) Disable LEXICAL should disable LEXICAL_SHADE
[ https://issues.apache.org/jira/browse/JEXL-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-409: --- Fix Version/s: 3.3.1 > Disable LEXICAL should disable LEXICAL_SHADE > > > Key: JEXL-409 > URL: https://issues.apache.org/jira/browse/JEXL-409 > Project: Commons JEXL > Issue Type: Bug >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The code to enable LEXICAL_SHADE automatically enables LEXICAL. > However the code to disable LEXICAL does not disable LEXICAL_SHADE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-409) Disable LEXICAL should disable LEXICAL_SHADE
[ https://issues.apache.org/jira/browse/JEXL-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-409: --- Assignee: Henri Biestro > Disable LEXICAL should disable LEXICAL_SHADE > > > Key: JEXL-409 > URL: https://issues.apache.org/jira/browse/JEXL-409 > Project: Commons JEXL > Issue Type: Bug >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > > The code to enable LEXICAL_SHADE automatically enables LEXICAL. > However the code to disable LEXICAL does not disable LEXICAL_SHADE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-408) Using JexlFeatures is tedious
[ https://issues.apache.org/jira/browse/JEXL-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-408: --- Fix Version/s: 3.3.1 > Using JexlFeatures is tedious > - > > Key: JEXL-408 > URL: https://issues.apache.org/jira/browse/JEXL-408 > Project: Commons JEXL > Issue Type: Improvement >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The JexlFeatures class is not very easy to configure if one wants to disable > all but one or two features. This is because the only constructor includes > many features by default. These all have to be disabled individually. > It would be useful to have a constructor that disabled all the features; > these could then be enabled individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-407) Sum of values shows incorrect
[
https://issues.apache.org/jira/browse/JEXL-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-407.
Fix Version/s: 3.3
Resolution: Not A Bug
As surprising as it may be, the result is coherent with IEEE 754 computations
on binary64 (used by most computers nowadays).
The following test illustrates Java vs JEXL (double) vs JEXL (BigDecimal); none
of the 3 will return a 0.
{code:java}
@Test
public void test407() {
// Java version
double r = 99.0d + 7.82d -99.0d -7.82d;
Assert.assertEquals(0d, r, 8.e-15); // Not zero, IEEE 754
// jexl
final JexlEngine jexl = new JexlBuilder().create();
JexlScript script = jexl.createScript("a + b - a - b", "a", "b");
// using doubles, same as Java
Number result = (Number) script.execute(null, 99.0d, 7.82d);
Assert.assertEquals(0d, result.doubleValue(), 8.e-15);
// using BigdDecimal, more precise, still not zero
result = (Number) script.execute(null, new BigDecimal(99.0d), new
BigDecimal(7.82d));
Assert.assertEquals(0d, result.doubleValue(), 3.e-32);
}{code}
> Sum of values shows incorrect
> -
>
> Key: JEXL-407
> URL: https://issues.apache.org/jira/browse/JEXL-407
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: HAKR
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> We are using JEXL expression in our project which is 3.0 version.
> When adding these values
> *99.0 + 7.82 -99.0 -7.82*
> It should be zero but the result we are seeing is *-7.105427357601002E-15*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-407) Sum of values shows incorrect
[ https://issues.apache.org/jira/browse/JEXL-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-407: --- Assignee: Henri Biestro > Sum of values shows incorrect > - > > Key: JEXL-407 > URL: https://issues.apache.org/jira/browse/JEXL-407 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.0 >Reporter: HAKR >Assignee: Henri Biestro >Priority: Major > > We are using JEXL expression in our project which is 3.0 version. > When adding these values > *99.0 + 7.82 -99.0 -7.82* > It should be zero but the result we are seeing is *-7.105427357601002E-15* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-406) allow override Engine.createTemplateInterpreter ?
[
https://issues.apache.org/jira/browse/JEXL-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-406.
Resolution: Fixed
This issue - and the fix - pertain to *internal* APIs; these are under a +use
at your own maintenance cost+ policy and are thus not maintained like public
APIs; compatibility between versions are *not* guaranteed.
Commit
[f97dd2|https://github.com/apache/commons-jexl/commit/f97dd2f8f969bf8072ce099f34ad7381e10e9c55]
> allow override Engine.createTemplateInterpreter ?
> -
>
> Key: JEXL-406
> URL: https://issues.apache.org/jira/browse/JEXL-406
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
> Attachments: image-2023-09-22-08-57-22-860.png
>
>
> I defined a Interpreter for JexlEngine but found it does not work while
> evaluating template string, I debugged and found Interpreter of jexl is not
> applied for TemplateEngine by default.
> I found there is a method createTemplateInterpreter in Engine.class
> {code:java}
> /**
> * Creates a template interpreter.
> * @param args the template interpreter arguments
> */
> protected Interpreter createTemplateInterpreter(final
> TemplateInterpreter.Arguments args) {
> return new TemplateInterpreter(args);
> }{code}
> But the parameter TemplateInterpreter.Arguments is not visible outside of the
> package, is it possible to change the visibility so that we can override it?
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-406) allow override Engine.createTemplateInterpreter ?
[
https://issues.apache.org/jira/browse/JEXL-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-406:
---
Fix Version/s: 3.3.1
> allow override Engine.createTemplateInterpreter ?
> -
>
> Key: JEXL-406
> URL: https://issues.apache.org/jira/browse/JEXL-406
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
> Attachments: image-2023-09-22-08-57-22-860.png
>
>
> I defined a Interpreter for JexlEngine but found it does not work while
> evaluating template string, I debugged and found Interpreter of jexl is not
> applied for TemplateEngine by default.
> I found there is a method createTemplateInterpreter in Engine.class
> {code:java}
> /**
> * Creates a template interpreter.
> * @param args the template interpreter arguments
> */
> protected Interpreter createTemplateInterpreter(final
> TemplateInterpreter.Arguments args) {
> return new TemplateInterpreter(args);
> }{code}
> But the parameter TemplateInterpreter.Arguments is not visible outside of the
> package, is it possible to change the visibility so that we can override it?
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-406) allow override Engine.createTemplateInterpreter ?
[
https://issues.apache.org/jira/browse/JEXL-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767869#comment-17767869
]
Henri Biestro commented on JEXL-406:
Regarding your failed test, I've updated the code in
[fcf59afc|https://github.com/apache/commons-jexl/commit/fcf59afce4900c895b953867cd4fe7204aca52eb]
to have a clearer idea of where that fails. Note that this is based on the
latest git code, not the 3.3 (released) version.
Regarding the map literal modifications, they fit your purpose but not the
general case. Whether to interpret identifiers used as map keys as variables or
not can lead to much confusion (imho).
Back to the original ask, will expose Arguments momentarily.
> allow override Engine.createTemplateInterpreter ?
> -
>
> Key: JEXL-406
> URL: https://issues.apache.org/jira/browse/JEXL-406
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Attachments: image-2023-09-22-08-57-22-860.png
>
>
> I defined a Interpreter for JexlEngine but found it does not work while
> evaluating template string, I debugged and found Interpreter of jexl is not
> applied for TemplateEngine by default.
> I found there is a method createTemplateInterpreter in Engine.class
> {code:java}
> /**
> * Creates a template interpreter.
> * @param args the template interpreter arguments
> */
> protected Interpreter createTemplateInterpreter(final
> TemplateInterpreter.Arguments args) {
> return new TemplateInterpreter(args);
> }{code}
> But the parameter TemplateInterpreter.Arguments is not visible outside of the
> package, is it possible to change the visibility so that we can override it?
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-406) allow override Engine.createTemplateInterpreter ?
[
https://issues.apache.org/jira/browse/JEXL-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767664#comment-17767664
]
Henri Biestro edited comment on JEXL-406 at 9/21/23 5:58 PM:
-
Added more complete test in
[cbc89ed|https://github.com/apache/commons-jexl/commit/cbc89ed533913590a4f109ca0627ffd484a6a3c8]
was (Author: henrib):
Added more complete test in
[cbc89ed|https://github.com/apache/commons-jexl/commit/cbc89ed533913590a4f109ca0627ffd484a6a3c8
> allow override Engine.createTemplateInterpreter ?
> -
>
> Key: JEXL-406
> URL: https://issues.apache.org/jira/browse/JEXL-406
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> I defined a Interpreter for JexlEngine but found it does not work while
> evaluating template string, I debugged and found Interpreter of jexl is not
> applied for TemplateEngine by default.
> I found there is a method createTemplateInterpreter in Engine.class
> {code:java}
> /**
> * Creates a template interpreter.
> * @param args the template interpreter arguments
> */
> protected Interpreter createTemplateInterpreter(final
> TemplateInterpreter.Arguments args) {
> return new TemplateInterpreter(args);
> }{code}
> But the parameter TemplateInterpreter.Arguments is not visible outside of the
> package, is it possible to change the visibility so that we can override it?
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-406) allow override Engine.createTemplateInterpreter ?
[
https://issues.apache.org/jira/browse/JEXL-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767664#comment-17767664
]
Henri Biestro commented on JEXL-406:
Added more complete test in
[cbc89ed|https://github.com/apache/commons-jexl/commit/cbc89ed533913590a4f109ca0627ffd484a6a3c8
> allow override Engine.createTemplateInterpreter ?
> -
>
> Key: JEXL-406
> URL: https://issues.apache.org/jira/browse/JEXL-406
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> I defined a Interpreter for JexlEngine but found it does not work while
> evaluating template string, I debugged and found Interpreter of jexl is not
> applied for TemplateEngine by default.
> I found there is a method createTemplateInterpreter in Engine.class
> {code:java}
> /**
> * Creates a template interpreter.
> * @param args the template interpreter arguments
> */
> protected Interpreter createTemplateInterpreter(final
> TemplateInterpreter.Arguments args) {
> return new TemplateInterpreter(args);
> }{code}
> But the parameter TemplateInterpreter.Arguments is not visible outside of the
> package, is it possible to change the visibility so that we can override it?
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-406) allow override Engine.createTemplateInterpreter ?
[
https://issues.apache.org/jira/browse/JEXL-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767633#comment-17767633
]
Henri Biestro commented on JEXL-406:
Let me try and rephrase to see I get this right. If you want to add a 'join'
method to any list, you may expose it through your own context as in the
following code
{code:java}
/**
* Any function in a context can be used aa a method of its first parameter.
*/
public static class XuContext extends MapContext {
public String join(Iterator iterator, String str) {
if (!iterator.hasNext()) {
return "";
}
StringBuilder strb = new StringBuilder(256);
strb.append(iterator.next().toString());
while(iterator.hasNext()) {
strb.append(str);
strb.append(iterator.next().toString());
}
return strb.toString();
}
public String join(Iterable list, String str) {
return join(list.iterator(), str);
}
}
@Test
public void test406() {
final JexlEngine jexl = new JexlBuilder()
.cache(64)
.strict(true)
.safe(false)
.create();
JexlContext context = new XuContext();
String src;
JexlScript script;
Object result;
src = "[1, 2, 3, 4, ...].join('-')";
script = jexl.createScript(src);
result = script.execute(context);
Assert.assertEquals("1-2-3-4", result);
src = "x.join('*')";
script = jexl.createScript(src, "x");
result = script.execute(context, Arrays.asList(1, 2, 3, 4));
Assert.assertEquals("1*2*3*4", result);
}
{code}
> allow override Engine.createTemplateInterpreter ?
> -
>
> Key: JEXL-406
> URL: https://issues.apache.org/jira/browse/JEXL-406
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> I defined a Interpreter for JexlEngine but found it does not work while
> evaluating template string, I debugged and found Interpreter of jexl is not
> applied for TemplateEngine by default.
> I found there is a method createTemplateInterpreter in Engine.class
> {code:java}
> /**
> * Creates a template interpreter.
> * @param args the template interpreter arguments
> */
> protected Interpreter createTemplateInterpreter(final
> TemplateInterpreter.Arguments args) {
> return new TemplateInterpreter(args);
> }{code}
> But the parameter TemplateInterpreter.Arguments is not visible outside of the
> package, is it possible to change the visibility so that we can override it?
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-406) allow override Engine.createTemplateInterpreter ?
[
https://issues.apache.org/jira/browse/JEXL-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767435#comment-17767435
]
Henri Biestro edited comment on JEXL-406 at 9/21/23 7:43 AM:
-
May I ask what are you trying to achieve and/or why do you need to derive the
Interpreter/TemplateInterpreter ? May be some obscure feature could already
help.
was (Author: henrib):
May I ask what are you trying to achieve and/or why do you need to derive the
Interpreter ? May be some obscure feature could already help.
> allow override Engine.createTemplateInterpreter ?
> -
>
> Key: JEXL-406
> URL: https://issues.apache.org/jira/browse/JEXL-406
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> I defined a Interpreter for JexlEngine but found it does not work while
> evaluating template string, I debugged and found Interpreter of jexl is not
> applied for TemplateEngine by default.
> I found there is a method createTemplateInterpreter in Engine.class
> {code:java}
> /**
> * Creates a template interpreter.
> * @param args the template interpreter arguments
> */
> protected Interpreter createTemplateInterpreter(final
> TemplateInterpreter.Arguments args) {
> return new TemplateInterpreter(args);
> }{code}
> But the parameter TemplateInterpreter.Arguments is not visible outside of the
> package, is it possible to change the visibility so that we can override it?
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-406) allow override Engine.createTemplateInterpreter ?
[
https://issues.apache.org/jira/browse/JEXL-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767435#comment-17767435
]
Henri Biestro edited comment on JEXL-406 at 9/21/23 7:42 AM:
-
May I ask what are you trying to achieve and/or why do you need to derive the
Interpreter ? May be some obscure feature could already help.
was (Author: henrib):
May I ask what are you trying to achieve and/or why do you need to derive the
TemplateInterpreter ? May be some obscure feature could already help.
> allow override Engine.createTemplateInterpreter ?
> -
>
> Key: JEXL-406
> URL: https://issues.apache.org/jira/browse/JEXL-406
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> I defined a Interpreter for JexlEngine but found it does not work while
> evaluating template string, I debugged and found Interpreter of jexl is not
> applied for TemplateEngine by default.
> I found there is a method createTemplateInterpreter in Engine.class
> {code:java}
> /**
> * Creates a template interpreter.
> * @param args the template interpreter arguments
> */
> protected Interpreter createTemplateInterpreter(final
> TemplateInterpreter.Arguments args) {
> return new TemplateInterpreter(args);
> }{code}
> But the parameter TemplateInterpreter.Arguments is not visible outside of the
> package, is it possible to change the visibility so that we can override it?
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-406) allow override Engine.createTemplateInterpreter ?
[
https://issues.apache.org/jira/browse/JEXL-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767435#comment-17767435
]
Henri Biestro commented on JEXL-406:
May I ask what are you trying to achieve and/or why do you need to derive the
TemplateInterpreter ? May be some obscure feature could already help.
> allow override Engine.createTemplateInterpreter ?
> -
>
> Key: JEXL-406
> URL: https://issues.apache.org/jira/browse/JEXL-406
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> I defined a Interpreter for JexlEngine but found it does not work while
> evaluating template string, I debugged and found Interpreter of jexl is not
> applied for TemplateEngine by default.
> I found there is a method createTemplateInterpreter in Engine.class
> {code:java}
> /**
> * Creates a template interpreter.
> * @param args the template interpreter arguments
> */
> protected Interpreter createTemplateInterpreter(final
> TemplateInterpreter.Arguments args) {
> return new TemplateInterpreter(args);
> }{code}
> But the parameter TemplateInterpreter.Arguments is not visible outside of the
> package, is it possible to change the visibility so that we can override it?
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-406) allow override Engine.createTemplateInterpreter ?
[
https://issues.apache.org/jira/browse/JEXL-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-406:
---
Affects Version/s: 3.3
> allow override Engine.createTemplateInterpreter ?
> -
>
> Key: JEXL-406
> URL: https://issues.apache.org/jira/browse/JEXL-406
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Priority: Major
>
> I defined a Interpreter for JexlEngine but found it does not work while
> evaluating template string, I debugged and found Interpreter of jexl is not
> applied for TemplateEngine by default.
> I found there is a method createTemplateInterpreter in Engine.class
> {code:java}
> /**
> * Creates a template interpreter.
> * @param args the template interpreter arguments
> */
> protected Interpreter createTemplateInterpreter(final
> TemplateInterpreter.Arguments args) {
> return new TemplateInterpreter(args);
> }{code}
> But the parameter TemplateInterpreter.Arguments is not visible outside of the
> package, is it possible to change the visibility so that we can override it?
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-406) allow override Engine.createTemplateInterpreter ?
[
https://issues.apache.org/jira/browse/JEXL-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-406:
---
Assignee: Henri Biestro
> allow override Engine.createTemplateInterpreter ?
> -
>
> Key: JEXL-406
> URL: https://issues.apache.org/jira/browse/JEXL-406
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> I defined a Interpreter for JexlEngine but found it does not work while
> evaluating template string, I debugged and found Interpreter of jexl is not
> applied for TemplateEngine by default.
> I found there is a method createTemplateInterpreter in Engine.class
> {code:java}
> /**
> * Creates a template interpreter.
> * @param args the template interpreter arguments
> */
> protected Interpreter createTemplateInterpreter(final
> TemplateInterpreter.Arguments args) {
> return new TemplateInterpreter(args);
> }{code}
> But the parameter TemplateInterpreter.Arguments is not visible outside of the
> package, is it possible to change the visibility so that we can override it?
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-405) Recursive functions corrupt evaluation frame if reassigned
[ https://issues.apache.org/jira/browse/JEXL-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761055#comment-17761055 ] Henri Biestro edited comment on JEXL-405 at 9/1/23 3:16 PM: The fix ensures that the lambda frame is only updated during its creation/assignment by checking that the caller's scope is indeed the lambda's scope parent. Many thanks to VincentB for reporting and analyzing this. Commit [53eb3db|https://github.com/apache/commons-jexl/commit/53eb3dbd42d27ba5411197f024ce9ddf2c1bcca] was (Author: henrib): The fix ensures that the lambda frame is only updated during its creation/assignment by checking that the caller's scope is indeed the lambda's scope parent. Commit [53eb3db|https://github.com/apache/commons-jexl/commit/53eb3dbd42d27ba5411197f024ce9ddf2c1bcca] > Recursive functions corrupt evaluation frame if reassigned > -- > > Key: JEXL-405 > URL: https://issues.apache.org/jira/browse/JEXL-405 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > This issue stems from the special handling recursive functions. A recursive > function is detected when a lambda is created and assigned to a variable and > that variable is captured by the lambda. During the assignment, the lambda > frame - the captured value for the lambda symbol in that frame - is updated > with a reference to the lambda itself. This can only occur after the lambda > is created (obviously). > The code that handles the special case during assignment does not verify that > the caller is indeed its creator frame. Thus, if the lambda is assigned to a > different variable later on in a different scope, that same code will trash > the frame with a reference to the lambda... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-405) Recursive functions corrupt evaluation frame if reassigned
[ https://issues.apache.org/jira/browse/JEXL-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761055#comment-17761055 ] Henri Biestro edited comment on JEXL-405 at 8/31/23 6:10 PM: - The fix ensures that the lambda frame is only updated during its creation/assignment by checking that the caller's scope is indeed the lambda's scope parent. Commit [53eb3db|https://github.com/apache/commons-jexl/commit/53eb3dbd42d27ba5411197f024ce9ddf2c1bcca] was (Author: henrib): The fix ensures that the lambda frame is only updated during its creation/assignment by checking that the caller's scope is indeed the lambda's scope parent. > Recursive functions corrupt evaluation frame if reassigned > -- > > Key: JEXL-405 > URL: https://issues.apache.org/jira/browse/JEXL-405 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > This issue stems from the special handling recursive functions. A recursive > function is detected when a lambda is created and assigned to a variable and > that variable is captured by the lambda. During the assignment, the lambda > frame - the captured value for the lambda symbol in that frame - is updated > with a reference to the lambda itself. This can only occur after the lambda > is created (obviously). > The code that handles the special case during assignment does not verify that > the caller is indeed its creator frame. Thus, if the lambda is assigned to a > different variable later on in a different scope, that same code will trash > the frame with a reference to the lambda... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-405) Recursive functions corrupt evaluation frame if reassigned
[ https://issues.apache.org/jira/browse/JEXL-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-405: --- Description: This issue stems from the special handling recursive functions. A recursive function is detected when a lambda is created and assigned to a variable and that variable is captured by the lambda. During the assignment, the lambda frame - the captured value for the lambda symbol in that frame - is updated with a reference to the lambda itself. This can only occur after the lambda is created (obviously). The code that handles the special case during assignment does not verify that the caller is indeed its creator frame. Thus, if the lambda is assigned to a different variable later on in a different scope, that same code will trash the frame with a reference to the lambda... > Recursive functions corrupt evaluation frame if reassigned > -- > > Key: JEXL-405 > URL: https://issues.apache.org/jira/browse/JEXL-405 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > This issue stems from the special handling recursive functions. A recursive > function is detected when a lambda is created and assigned to a variable and > that variable is captured by the lambda. During the assignment, the lambda > frame - the captured value for the lambda symbol in that frame - is updated > with a reference to the lambda itself. This can only occur after the lambda > is created (obviously). > The code that handles the special case during assignment does not verify that > the caller is indeed its creator frame. Thus, if the lambda is assigned to a > different variable later on in a different scope, that same code will trash > the frame with a reference to the lambda... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-405) Recursive functions corrupt evaluation frame if reassigned
[ https://issues.apache.org/jira/browse/JEXL-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-405. Resolution: Fixed The fix ensures that the lambda frame is only updated during its creation/assignment by checking that the caller's scope is indeed the lambda's scope parent. > Recursive functions corrupt evaluation frame if reassigned > -- > > Key: JEXL-405 > URL: https://issues.apache.org/jira/browse/JEXL-405 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > This issue stems from the special handling recursive functions. A recursive > function is detected when a lambda is created and assigned to a variable and > that variable is captured by the lambda. During the assignment, the lambda > frame - the captured value for the lambda symbol in that frame - is updated > with a reference to the lambda itself. This can only occur after the lambda > is created (obviously). > The code that handles the special case during assignment does not verify that > the caller is indeed its creator frame. Thus, if the lambda is assigned to a > different variable later on in a different scope, that same code will trash > the frame with a reference to the lambda... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JEXL-405) Recursive functions corrupt evaluation frame if reassigned
Henri Biestro created JEXL-405: -- Summary: Recursive functions corrupt evaluation frame if reassigned Key: JEXL-405 URL: https://issues.apache.org/jira/browse/JEXL-405 Project: Commons JEXL Issue Type: Bug Affects Versions: 3.3 Reporter: Henri Biestro Assignee: Henri Biestro Fix For: 3.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
