[jira] [Created] (JEXL-210) The way to cancel script execution with an error
Dmitri Blinov created JEXL-210:
--
Summary: The way to cancel script execution with an error
Key: JEXL-210
URL: https://issues.apache.org/jira/browse/JEXL-210
Project: Commons JEXL
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dmitri Blinov
Priority: Minor
I don't see a way now to cancel script execution with some kind of error.
Unfortunately it's not possible to just throw an exception from some method as
this will rely on current settings of context/engine *strictness* and
*verboseness*. Using InterruptedException for this purpose is not an option
because I think it has special meaning of cancelling the current thread
execution. Yet the task I beleive is quite common - to inform the executing
environment that the script has encountered some unavoidable situation and can
not continue. Just like *return* statement but returning not a value but an
error.
For this purpose we can simply introduce some new type of exception, for
example
{code}
public static class Error extends JexlException {
...
{code}
and by throwing it from any method the JexlEngine will terminate the current
script execution regardless of strictness/verboseness. May be this task even
deserves to have a special operator, for example
{code}
raise 'Something has happended';
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-207) Inconsistent error handling
[
https://issues.apache.org/jira/browse/JEXL-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407198#comment-15407198
]
Dmitri Blinov commented on JEXL-207:
Replied at JEXL-210
> Inconsistent error handling
> ---
>
> Key: JEXL-207
> URL: https://issues.apache.org/jira/browse/JEXL-207
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.0.1
>
>
> I can't figure out what is the logic behind current implementation of script
> interruptablity/error handling.
> For example the following script will execute up to the end and return 42 in
> any mode (strict/silent)
> {code}
> x = null.1; return 42
> {code}
> whereas the following script will break with exception "bean is null" also in
> any mode (strict/silent)
> {code}
> null.1 = 2; return 42
> {code}
> and the following script will throw an exception in strict mode regardless of
> being silent/non-silent
> {code}
> z = [1,2]; x = z[3]; return 42
> {code}
> The documentation states that
> {quote}
> The strict flag tells the engine when and if null as operand is considered an
> error, the silent flag tells the engine what to do with the error (log as
> warning or throw exception)
> {quote}
> From the first example we see that null is not considered as error when we
> resolve bean property value, even does not log a message, while it might be
> expected in strict mode. From the second example we see that null is always
> considered as an error when we set bean property value, but is never ignored
> (always breaks script execution), even in silent mode. From the third example
> we see that AIOOBE is also considered as an error that breaks script
> execution in strict mode, regardless of silent/non-silent mode.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-210) The way to cancel script execution with an error
[
https://issues.apache.org/jira/browse/JEXL-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407166#comment-15407166
]
Dmitri Blinov commented on JEXL-210:
I think JEXL-210 and JEXL-207 are separate issues. For me JEXL-207 works fine.
Of course it would be great to have more fine-tuned switches regarding vars,
properties, indexes, methods etc, but at the moment, thanks to JEXL-201, I have
managed to implement annotations like @strict, @leninent so I can separately
fine-control each statement, for example if I know that there could not be an
array item with index == 2, I can protect that statement with
{code}
@leninent optionalVar = args[2];
{code}
JEXL-210 is more of statement flow control operators, like *return* or *break*.
Under the hood they are implemented by using exceptions, but theese statements
work no matter what mode (strict/silent) we initialized JexlEngine in. Their
purpose is to break script/block execution and so should be with lets name it
*raise*. In fact *raise* can be implemented like a statement similar to
*return*
{code}
raise 'Error';
{code}
or like a builtin function similar to *empty()*
{code}
raise('Error');
{code}
or even may be left unimplemented by default, provided that it could be as
easily implemented, under some other name the developer sees fit, as just
throwing the exception of special class, for example JexlException.Error.
> The way to cancel script execution with an error
>
>
> Key: JEXL-210
> URL: https://issues.apache.org/jira/browse/JEXL-210
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
>
> I don't see a way now to cancel script execution with some kind of error.
> Unfortunately it's not possible to just throw an exception from some method
> as this will rely on current settings of context/engine *strictness* and
> *verboseness*. Using InterruptedException for this purpose is not an option
> because I think it has special meaning of cancelling the current thread
> execution. Yet the task I beleive is quite common - to inform the executing
> environment that the script has encountered some unavoidable situation and
> can not continue. Just like *return* statement but returning not a value but
> an error.
> For this purpose we can simply introduce some new type of exception, for
> example
> {code}
> public static class Error extends JexlException {
> ...
> {code}
> and by throwing it from any method the JexlEngine will terminate the current
> script execution regardless of strictness/verboseness. May be this task even
> deserves to have a special operator, for example
> {code}
> raise 'Something has happended';
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JEXL-210) The way to cancel script execution with an error
[
https://issues.apache.org/jira/browse/JEXL-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407907#comment-15407907
]
Dmitri Blinov edited comment on JEXL-210 at 8/4/16 3:05 PM:
Well, this may not nessesery be a bug, since we have no *catch* statement in
jexl. In some cases it's preferrable to fail, in others - to continue even in
case of exception. Consider someone wants to call InputStream.close() which can
raise an IOException but interrupting script execution may be meaningless in
that case.
was (Author: dmitri_blinov):
Well, this may not nessesery be a bug, since we have no *catch* statement in
jexl. In some cases it's preferrable to fail, in others - to continue even in
case of exception. Consider someone wants to call InputStream.close() which can
raise an IOException but interrupting script execution may meaningless.
> The way to cancel script execution with an error
>
>
> Key: JEXL-210
> URL: https://issues.apache.org/jira/browse/JEXL-210
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.0.1
>
>
> I don't see a way now to cancel script execution with some kind of error.
> Unfortunately it's not possible to just throw an exception from some method
> as this will rely on current settings of context/engine *strictness* and
> *verboseness*. Using InterruptedException for this purpose is not an option
> because I think it has special meaning of cancelling the current thread
> execution. Yet the task I beleive is quite common - to inform the executing
> environment that the script has encountered some unavoidable situation and
> can not continue. Just like *return* statement but returning not a value but
> an error.
> For this purpose we can simply introduce some new type of exception, for
> example
> {code}
> public static class Error extends JexlException {
> ...
> {code}
> and by throwing it from any method the JexlEngine will terminate the current
> script execution regardless of strictness/verboseness. May be this task even
> deserves to have a special operator, for example
> {code}
> raise 'Something has happended';
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-210) The way to cancel script execution with an error
[
https://issues.apache.org/jira/browse/JEXL-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407907#comment-15407907
]
Dmitri Blinov commented on JEXL-210:
Well, this may not nessesery be a bug, since we have no *catch* statement in
jexl. In some cases it's preferrable to fail, in others - to continue even in
case of exception. Consider someone wants to call InputStream.close() which can
raise an IOException but interrupting script execution may meaningless.
> The way to cancel script execution with an error
>
>
> Key: JEXL-210
> URL: https://issues.apache.org/jira/browse/JEXL-210
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.0.1
>
>
> I don't see a way now to cancel script execution with some kind of error.
> Unfortunately it's not possible to just throw an exception from some method
> as this will rely on current settings of context/engine *strictness* and
> *verboseness*. Using InterruptedException for this purpose is not an option
> because I think it has special meaning of cancelling the current thread
> execution. Yet the task I beleive is quite common - to inform the executing
> environment that the script has encountered some unavoidable situation and
> can not continue. Just like *return* statement but returning not a value but
> an error.
> For this purpose we can simply introduce some new type of exception, for
> example
> {code}
> public static class Error extends JexlException {
> ...
> {code}
> and by throwing it from any method the JexlEngine will terminate the current
> script execution regardless of strictness/verboseness. May be this task even
> deserves to have a special operator, for example
> {code}
> raise 'Something has happended';
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-210) The way to cancel script execution with an error
[
https://issues.apache.org/jira/browse/JEXL-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15408043#comment-15408043
]
Dmitri Blinov commented on JEXL-210:
Is there any way to preserve inital exception message, for example I have
implemented method raise() as follows
{code}
public void raise(String message) throws Exception {
throw new Exception(message);
}
{code}
but the script like this
{code}raise("Error"){code}
returns exception with the message
{quote}
org.apache.commons.jexl3.JexlException: EvaluationContext.evalScript@1:6 raise
{quote}
> The way to cancel script execution with an error
>
>
> Key: JEXL-210
> URL: https://issues.apache.org/jira/browse/JEXL-210
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.0.1
>
>
> I don't see a way now to cancel script execution with some kind of error.
> Unfortunately it's not possible to just throw an exception from some method
> as this will rely on current settings of context/engine *strictness* and
> *verboseness*. Using InterruptedException for this purpose is not an option
> because I think it has special meaning of cancelling the current thread
> execution. Yet the task I beleive is quite common - to inform the executing
> environment that the script has encountered some unavoidable situation and
> can not continue. Just like *return* statement but returning not a value but
> an error.
> For this purpose we can simply introduce some new type of exception, for
> example
> {code}
> public static class Error extends JexlException {
> ...
> {code}
> and by throwing it from any method the JexlEngine will terminate the current
> script execution regardless of strictness/verboseness. May be this task even
> deserves to have a special operator, for example
> {code}
> raise 'Something has happended';
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JEXL-206) testCancelLoopWait() test hangs sporadically?
[
https://issues.apache.org/jira/browse/JEXL-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov updated JEXL-206:
---
Description:
I'm struggling with strange behaviour of the building process, it seems that
time after time the process hangs somewhere in the middle of the tests stage.
First I thought it was somehow related to memory problems so I changed fork
mode of the test plugin by adding
pertest to maven-surefire-plugin configuration. But that
helped for a couple of times to cleanly build jexl and run all tests
successfully. The other times it simply hanged on test stage. I have managed to
detect that it is the testCancelLoopWait() test that hangs. It writes to the
console the message
{panel}
WARNING: org.apache.commons.jexl3.ScriptCallableTest.testCancelLoopWait@1:20
execution cancelled
{panel}
and hangs with its stack trace as follows:
{code}
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:893)
org.apache.commons.jexl3.parser.ASTWhileStatement.jjtAccept(ASTWhileStatement.java:18)
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1119)
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:55)
org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:210)
org.apache.commons.jexl3.internal.Script$Callable.interpret(Script.java:364)
org.apache.commons.jexl3.internal.Script$Callable.call(Script.java:372)
- locked org.apache.commons.jexl3.internal.Script$Callable@18399f62
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:745)
{code}
The problem started manifesting itself right after I had added
ScriptInterruptableTest.java (see JEXL-204) but as I understand this test
script is completely unrelated to ScriptCallableTest.java so I think it's
merely a conicidence. I could not write anything in ScriptInterruptableTest and
screw up ScriptCallableTest, right?
PS. I have managed to catch this exactly behavior after removing
ScriptInterruptableTest.java completely and making clean build, so I'm 100%
sure there is something wrong with the original code, may be race condition or
something.
If the test runs as normal and does not hang it prints the following:
{panel}
WARNING: org.apache.commons.jexl3.ScriptCallableTest.testCancelLoopWait@1:20
execution cancelled
...12, 2016 3:31:50 PM org.apache.commons.jexl3.JexlEngine invocationFailed
{panel}
was:
I'm struggling with strange behaviour of the building process, it seems that
time after time the process hangs somewhere in the middle of the tests stage.
First I thought it was somehow related to memory problems so I changed fork
mode of the test plugin by adding
pertest to maven-surefire-plugin configuration. But that
helped for a couple of times to cleanly build jexl and run all tests
successfully. The other times it simply hanged on test stage. I have managed to
detect that it is the testCancelLoopWait() test that hangs. It writes to the
console the message
{panel}
WARNING: org.apache.commons.jexl3.ScriptCallableTest.testCancelLoopWait@1:20
execution cancelled
{panel}
and hangs with its stack trace as follows:
{code}
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:893)
org.apache.commons.jexl3.parser.ASTWhileStatement.jjtAccept(ASTWhileStatement.java:18)
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1119)
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:55)
org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:210)
org.apache.commons.jexl3.internal.Script$Callable.interpret(Script.java:364)
org.apache.commons.jexl3.internal.Script$Callable.call(Script.java:372)
- locked org.apache.commons.jexl3.internal.Script$Callable@18399f62
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:745)
{code}
The problem started manifesting itself right after I had added
ScriptInterruptableTest.java (see JEXL-204) but as I understand this test
script is completely unrelated to ScriptCallableTest.java so I think it's
merely a conicidence. I could not write anything in ScriptInterruptableTest and
screw up ScriptCallableTest, right?
PS. I have managed to catch this exactly behavior after removing
ScriptInterruptableTest.java completely and making clean build, so I'm 100%
sure there is something wrong with the original code, may be race condition or
something.
> testCancelLoopWait() test hangs sporadically?
> -
>
>
[jira] [Updated] (JEXL-206) testCallableCancel() test hangs sporadically
[
https://issues.apache.org/jira/browse/JEXL-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov updated JEXL-206:
---
Description:
I'm struggling with strange behaviour of the building process, it seems that
time after time the process hangs somewhere in the middle of the tests stage.
First I thought it was somehow related to memory problems so I changed fork
mode of the test plugin by adding
pertest to maven-surefire-plugin configuration. But that
helped for a couple of times to cleanly build jexl and run all tests
successfully. The other times it simply hanged on test stage. I have managed to
detect that it is the testCallableCancel() test that hangs. One of its worker
threads has a stack trace as follows:
{code}
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:893)
org.apache.commons.jexl3.parser.ASTWhileStatement.jjtAccept(ASTWhileStatement.java:18)
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1119)
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:55)
org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:210)
org.apache.commons.jexl3.internal.Script$Callable.interpret(Script.java:364)
org.apache.commons.jexl3.internal.Script$Callable.call(Script.java:372)
- locked org.apache.commons.jexl3.internal.Script$Callable@18399f62
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:745)
{code}
I have adjusted the test code with prinln() to dig further what is going on:
{code}
@Test
public void testCallableCancel() throws Exception {
System.out.println("testCallableCancel(): started");
JexlScript e = JEXL.createScript("while(true);");
final Script.Callable c = (Script.Callable) e.callable(null);
Object t = 42;
Callable kc = new Callable() {
@Override
public Object call() throws Exception {
System.out.println("testCallableCancel(): cancel() is called");
return c.cancel();
}
};
Callable xkc = new Callable() {
@Override
public Object call() throws Exception {
System.out.println("testCallableCancel(): run() is called");
return c.call();
}
};
ExecutorService executor = Executors.newFixedThreadPool(2);
Future future = executor.submit(xkc);
Future kfc = executor.submit(kc);
try {
Assert.assertTrue((Boolean) kfc.get());
System.out.println("testCallableCancel(): canceled()");
t = future.get();
Assert.fail("should have been cancelled");
} catch (ExecutionException xexec) {
// ok, ignore
Assert.assertTrue(xexec.getCause() instanceof JexlException.Cancel);
} finally {
executor.shutdown();
}
Assert.assertTrue(c.isCancelled());
System.out.println("testCallableCancel(): finished");
}
{code}
If the test hangs it prints the following:
{panel}
testCallableCancel(): started
testCallableCancel(): run() is called
testCallableCancel(): cancel() is called
testCallableCancel(): canceled()
{panel}
If the test runs as normal and does not hang it prints the following:
{panel}
testCallableCancel(): started
testCallableCancel(): run() is called
testCallableCancel(): cancel() is called
testCallableCancel(): canceled()
testCallableCancel(): finished
{panel}
was:
I'm struggling with strange behaviour of the building process, it seems that
time after time the process hangs somewhere in the middle of the tests stage.
First I thought it was somehow related to memory problems so I changed fork
mode of the test plugin by adding
pertest to maven-surefire-plugin configuration. But that
helped for a couple of times to cleanly build jexl and run all tests
successfully. The other times it simply hanged on test stage. I have managed to
detect that it is the testCancelLoopWait() test that hangs. It writes to the
console the message
{panel}
WARNING: org.apache.commons.jexl3.ScriptCallableTest.testCancelLoopWait@1:20
execution cancelled
{panel}
and hangs with its stack trace as follows:
{code}
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:893)
org.apache.commons.jexl3.parser.ASTWhileStatement.jjtAccept(ASTWhileStatement.java:18)
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1119)
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:55)
org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:210)
org.apache.commons.jexl3.internal.Script$Callable.interpret(Script.java:364)
[jira] [Commented] (JEXL-206) testCallableCancel() test hangs sporadically
[
https://issues.apache.org/jira/browse/JEXL-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374593#comment-15374593
]
Dmitri Blinov commented on JEXL-206:
After two hours of continious testing I can tell the problem seems to go away
> testCallableCancel() test hangs sporadically
>
>
> Key: JEXL-206
> URL: https://issues.apache.org/jira/browse/JEXL-206
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>
> I'm struggling with strange behaviour of the building process, it seems that
> time after time the process hangs somewhere in the middle of the tests stage.
> First I thought it was somehow related to memory problems so I changed fork
> mode of the test plugin by adding
> pertest to maven-surefire-plugin configuration. But that
> helped for a couple of times to cleanly build jexl and run all tests
> successfully. The other times it simply hanged on test stage. I have managed
> to detect that it is the testCallableCancel() test that hangs. One of its
> worker threads has a stack trace as follows:
> {code}
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:893)
> org.apache.commons.jexl3.parser.ASTWhileStatement.jjtAccept(ASTWhileStatement.java:18)
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1119)
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:55)
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:210)
> org.apache.commons.jexl3.internal.Script$Callable.interpret(Script.java:364)
> org.apache.commons.jexl3.internal.Script$Callable.call(Script.java:372)
>- locked org.apache.commons.jexl3.internal.Script$Callable@18399f62
> java.util.concurrent.FutureTask.run(FutureTask.java:262)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:745)
> {code}
> I have adjusted the test code with prinln() to dig further what is going on:
> {code}
> @Test
> public void testCallableCancel() throws Exception {
> System.out.println("testCallableCancel(): started");
> JexlScript e = JEXL.createScript("while(true);");
> final Script.Callable c = (Script.Callable) e.callable(null);
> Object t = 42;
> Callable kc = new Callable() {
> @Override
> public Object call() throws Exception {
> System.out.println("testCallableCancel(): cancel() is
> called");
> return c.cancel();
> }
> };
> Callable xkc = new Callable() {
> @Override
> public Object call() throws Exception {
> System.out.println("testCallableCancel(): run() is called");
> return c.call();
> }
> };
> ExecutorService executor = Executors.newFixedThreadPool(2);
> Future future = executor.submit(xkc);
> Future kfc = executor.submit(kc);
> try {
> Assert.assertTrue((Boolean) kfc.get());
> System.out.println("testCallableCancel(): canceled()");
> t = future.get();
> Assert.fail("should have been cancelled");
> } catch (ExecutionException xexec) {
> // ok, ignore
> Assert.assertTrue(xexec.getCause() instanceof
> JexlException.Cancel);
> } finally {
> executor.shutdown();
> }
> Assert.assertTrue(c.isCancelled());
> System.out.println("testCallableCancel(): finished");
> }
> {code}
> If the test hangs it prints the following:
> {panel}
> testCallableCancel(): started
> testCallableCancel(): run() is called
> testCallableCancel(): cancel() is called
> testCallableCancel(): canceled()
> {panel}
> If the test runs as normal and does not hang it prints the following:
> {panel}
> testCallableCancel(): started
> testCallableCancel(): run() is called
> testCallableCancel(): cancel() is called
> testCallableCancel(): canceled()
> testCallableCancel(): finished
> {panel}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-205) testCancelForever() is not terminated properly
[
https://issues.apache.org/jira/browse/JEXL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15376351#comment-15376351
]
Dmitri Blinov commented on JEXL-205:
I'm afraid this won't help eigher, it's the midlle of the
TestContext.runForever() while loop that the thread is stuck in.
{code}
public int runForever() {
boolean x = false;
while (true) {
// This is where we are stuck eating up CPU cycles for the rest
of all tests
if (x) {
break;
}
}
...
}
{code}
No way out unitl 'x' becomes true, but it won't, sincle it's local var nobody
can change from outside.
> testCancelForever() is not terminated properly
> --
>
> Key: JEXL-205
> URL: https://issues.apache.org/jira/browse/JEXL-205
> Project: Commons JEXL
> Issue Type: Task
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>
> After runnning Jexl tests I have noticed that the thread from
> testCancelForever() test is still executing, and its stack trace is as
> follows:
> {code}
> org.apache.commons.jexl3.ScriptCallableTest$TestContext.runForever(ScriptCallableTest.java:159)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:606)
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.invoke(MethodExecutor.java:93)
> org.apache.commons.jexl3.internal.Interpreter.call(Interpreter.java:1816)
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1535)
> org.apache.commons.jexl3.parser.ASTFunctionNode.jjtAccept(ASTFunctionNode.java:18)
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1119)
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:55)
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:210)
> org.apache.commons.jexl3.internal.Script$Callable.interpret(Script.java:364)
> org.apache.commons.jexl3.internal.Script$Callable.call(Script.java:372)
>- locked org.apache.commons.jexl3.internal.Script$Callable@35595365
> java.util.concurrent.FutureTask.run(FutureTask.java:262)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:745)
> {code}
> may be its worth rewriting the test to something like this
> {code}
> public static class TestContext extends MapContext implements
> JexlContext.NamespaceResolver {
> protected volatile boolean x = false;
> public int runForever() {
> while (true) {
> if (x) {
> break;
> }
> }
> return 1;
> }
> ...
> @Test
> public void testCancelForever() throws Exception {
> JexlScript e = JEXL.createScript("runForever()");
> TestContext tctx = new TestContext();
> Callable c = e.callable(tctx);
> ExecutorService executor = Executors.newFixedThreadPool(1);
> Future future = executor.submit(c);
> Object t = 42;
> try {
> t = future.get(100, TimeUnit.MILLISECONDS);
> Assert.fail("should have timed out");
> } catch (TimeoutException xtimeout) {
> // ok, ignore
> future.cancel(true);
> tctx.x = true;
> } finally {
> executor.shutdown();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-205) testCancelForever() is not terminated properly
[
https://issues.apache.org/jira/browse/JEXL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15376502#comment-15376502
]
Dmitri Blinov commented on JEXL-205:
That looks reasonable. Sorry I didn't sync before writing comment
> testCancelForever() is not terminated properly
> --
>
> Key: JEXL-205
> URL: https://issues.apache.org/jira/browse/JEXL-205
> Project: Commons JEXL
> Issue Type: Task
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>
> After runnning Jexl tests I have noticed that the thread from
> testCancelForever() test is still executing, and its stack trace is as
> follows:
> {code}
> org.apache.commons.jexl3.ScriptCallableTest$TestContext.runForever(ScriptCallableTest.java:159)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:606)
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.invoke(MethodExecutor.java:93)
> org.apache.commons.jexl3.internal.Interpreter.call(Interpreter.java:1816)
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1535)
> org.apache.commons.jexl3.parser.ASTFunctionNode.jjtAccept(ASTFunctionNode.java:18)
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1119)
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:55)
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:210)
> org.apache.commons.jexl3.internal.Script$Callable.interpret(Script.java:364)
> org.apache.commons.jexl3.internal.Script$Callable.call(Script.java:372)
>- locked org.apache.commons.jexl3.internal.Script$Callable@35595365
> java.util.concurrent.FutureTask.run(FutureTask.java:262)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:745)
> {code}
> may be its worth rewriting the test to something like this
> {code}
> public static class TestContext extends MapContext implements
> JexlContext.NamespaceResolver {
> protected volatile boolean x = false;
> public int runForever() {
> while (true) {
> if (x) {
> break;
> }
> }
> return 1;
> }
> ...
> @Test
> public void testCancelForever() throws Exception {
> JexlScript e = JEXL.createScript("runForever()");
> TestContext tctx = new TestContext();
> Callable c = e.callable(tctx);
> ExecutorService executor = Executors.newFixedThreadPool(1);
> Future future = executor.submit(c);
> Object t = 42;
> try {
> t = future.get(100, TimeUnit.MILLISECONDS);
> Assert.fail("should have timed out");
> } catch (TimeoutException xtimeout) {
> // ok, ignore
> future.cancel(true);
> tctx.x = true;
> } finally {
> executor.shutdown();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-197) Add annotations
[
https://issues.apache.org/jira/browse/JEXL-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381151#comment-15381151
]
Dmitri Blinov commented on JEXL-197:
I'm reflecting on the possible ways to debug script execution. For example to
use annotation in a way like
{code}
@breakpoint {x = faulycode();}
{code}
To debug a script I believe two things are important - first is to know where
we have stopped, some information about current statement, for what I thought
JexlNode would be informative, and the other - to know what is the current
state we are in. We have already had JexlContext to examine, but there is
curent stack frame we know nothing about, - and for what I thought the access
to Interpreter would be useful.
I agree exposing internal classes is not the best idea. For the one hand, we
can wrap Interpreter to some interface, for example, JexlInterpreter, leaving
access to only relevant methods, for the other hand we can still use a Callable
instead of JexlNode, say JexlCallable, and provide some method to it, may be
overload toString(), to get info about the statement itself.
What do you think of it?
> Add annotations
> ---
>
> Key: JEXL-197
> URL: https://issues.apache.org/jira/browse/JEXL-197
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.1
>
>
> Follow up from JEXL-194...
> As an implementation to the extension of statement executions in JEXL we
> could introduce the use of annotations to each statement or block in the
> script, i.e.
> {code}
> @synchronized(items) {for (x : items) ...}
> {code}
> Each statement block should be allowed to have only one annotation but it
> would be convenient to allow the syntax
> {code}
> @silent @lenient {null.tryMe()}
> {code}
> which should be syntaxically equivalent to:
> {code}
> @silent {@lenient {null.tryMe()}}
> {code}
> From the JexlEngine point of view, each annotation could be implemented in
> the form of Interceptor interface, for example
> {code}
> public interface Interceptor {
>public Object onExecute(JexlStatement block, String annotation, Object..
> args);
> }
> {code}
> The annotation syntax should allow for zero, one or more parameters. Those
> parameters should be evaluated before interceptor execution and submitted to
> the Interceptor.onExecute() method via args parameter.
> JexlEngine should be given a method to register annotation interceptor based
> on annotation name, and the one for default interceptor, which should be
> called before each statement execution as if @default annotation is declared
> in each statement in script.
> {code}
> @silent {@default {...}}
> {code}
> The JexlStatement is the proposed new interface to somehow identify the
> statement or block of code which may also provide some info about it's stack
> frame.
> {code}
> public interface JexlStatement {
>public Object interpret();
>// ..
> }
> {code}
> The JexlStatement.interpret() method should trigger the execution of the
> statement block, returning statement's result as its return value.
> In the absence of a matching interceptor corresponding to the annotation
> name, JexlEngine should simply ignore that, or write some diagnostic message
> in the log file.
> Such implementation could provide developers with excellent tool to add
> various checks and enhancements to scripting without pushing for new features
> that eventually would mess up the basic code. The JEXL-185 issue could also
> be dropped since tracing could be added easily via interceptors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-197) Add annotations
[
https://issues.apache.org/jira/browse/JEXL-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15380003#comment-15380003
]
Dmitri Blinov commented on JEXL-197:
I wonder if it's possible to chage signature of
JexlContext.AnnotationProcessor.processAnnotation method from
{code}
Object processAnnotation(String name, Object[] args, Callable
statement) throws Exception
{code}
To
{code}
Object processAnnotation(String name, Object[] args, Interpreter interpreter,
JexlNode node) throws Exception
{code}
Would it be then possible to call interpreter.interpret(node) during annotation
processing?
> Add annotations
> ---
>
> Key: JEXL-197
> URL: https://issues.apache.org/jira/browse/JEXL-197
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.1
>
>
> Follow up from JEXL-194...
> As an implementation to the extension of statement executions in JEXL we
> could introduce the use of annotations to each statement or block in the
> script, i.e.
> {code}
> @synchronized(items) {for (x : items) ...}
> {code}
> Each statement block should be allowed to have only one annotation but it
> would be convenient to allow the syntax
> {code}
> @silent @lenient {null.tryMe()}
> {code}
> which should be syntaxically equivalent to:
> {code}
> @silent {@lenient {null.tryMe()}}
> {code}
> From the JexlEngine point of view, each annotation could be implemented in
> the form of Interceptor interface, for example
> {code}
> public interface Interceptor {
>public Object onExecute(JexlStatement block, String annotation, Object..
> args);
> }
> {code}
> The annotation syntax should allow for zero, one or more parameters. Those
> parameters should be evaluated before interceptor execution and submitted to
> the Interceptor.onExecute() method via args parameter.
> JexlEngine should be given a method to register annotation interceptor based
> on annotation name, and the one for default interceptor, which should be
> called before each statement execution as if @default annotation is declared
> in each statement in script.
> {code}
> @silent {@default {...}}
> {code}
> The JexlStatement is the proposed new interface to somehow identify the
> statement or block of code which may also provide some info about it's stack
> frame.
> {code}
> public interface JexlStatement {
>public Object interpret();
>// ..
> }
> {code}
> The JexlStatement.interpret() method should trigger the execution of the
> statement block, returning statement's result as its return value.
> In the absence of a matching interceptor corresponding to the annotation
> name, JexlEngine should simply ignore that, or write some diagnostic message
> in the log file.
> Such implementation could provide developers with excellent tool to add
> various checks and enhancements to scripting without pushing for new features
> that eventually would mess up the basic code. The JEXL-185 issue could also
> be dropped since tracing could be added easily via interceptors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JEXL-197) Add annotations
[
https://issues.apache.org/jira/browse/JEXL-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15380003#comment-15380003
]
Dmitri Blinov edited comment on JEXL-197 at 7/15/16 7:53 PM:
-
I wonder if it's possible to change signature of
JexlContext.AnnotationProcessor.processAnnotation method from
{code}
Object processAnnotation(String name, Object[] args, Callable
statement) throws Exception
{code}
To
{code}
Object processAnnotation(String name, Object[] args, Interpreter interpreter,
JexlNode node) throws Exception
{code}
Would it be then possible to call interpreter.interpret(node) during annotation
processing?
was (Author: dmitri_blinov):
I wonder if it's possible to chage signature of
JexlContext.AnnotationProcessor.processAnnotation method from
{code}
Object processAnnotation(String name, Object[] args, Callable
statement) throws Exception
{code}
To
{code}
Object processAnnotation(String name, Object[] args, Interpreter interpreter,
JexlNode node) throws Exception
{code}
Would it be then possible to call interpreter.interpret(node) during annotation
processing?
> Add annotations
> ---
>
> Key: JEXL-197
> URL: https://issues.apache.org/jira/browse/JEXL-197
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.1
>
>
> Follow up from JEXL-194...
> As an implementation to the extension of statement executions in JEXL we
> could introduce the use of annotations to each statement or block in the
> script, i.e.
> {code}
> @synchronized(items) {for (x : items) ...}
> {code}
> Each statement block should be allowed to have only one annotation but it
> would be convenient to allow the syntax
> {code}
> @silent @lenient {null.tryMe()}
> {code}
> which should be syntaxically equivalent to:
> {code}
> @silent {@lenient {null.tryMe()}}
> {code}
> From the JexlEngine point of view, each annotation could be implemented in
> the form of Interceptor interface, for example
> {code}
> public interface Interceptor {
>public Object onExecute(JexlStatement block, String annotation, Object..
> args);
> }
> {code}
> The annotation syntax should allow for zero, one or more parameters. Those
> parameters should be evaluated before interceptor execution and submitted to
> the Interceptor.onExecute() method via args parameter.
> JexlEngine should be given a method to register annotation interceptor based
> on annotation name, and the one for default interceptor, which should be
> called before each statement execution as if @default annotation is declared
> in each statement in script.
> {code}
> @silent {@default {...}}
> {code}
> The JexlStatement is the proposed new interface to somehow identify the
> statement or block of code which may also provide some info about it's stack
> frame.
> {code}
> public interface JexlStatement {
>public Object interpret();
>// ..
> }
> {code}
> The JexlStatement.interpret() method should trigger the execution of the
> statement block, returning statement's result as its return value.
> In the absence of a matching interceptor corresponding to the annotation
> name, JexlEngine should simply ignore that, or write some diagnostic message
> in the log file.
> Such implementation could provide developers with excellent tool to add
> various checks and enhancements to scripting without pushing for new features
> that eventually would mess up the basic code. The JEXL-185 issue could also
> be dropped since tracing could be added easily via interceptors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-205) testCancelForever() is not terminated properly
[
https://issues.apache.org/jira/browse/JEXL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374600#comment-15374600
]
Dmitri Blinov commented on JEXL-205:
No, the thread has not stopped correctly, but sorry, I don't understand how a
latch in this case could help to stop the endless loop in runForever() method.
To break away we need to somehow change value of 'x' variable, and for that
purpose I offered to refactor it to a property of the TestContext class, see
the description.
> testCancelForever() is not terminated properly
> --
>
> Key: JEXL-205
> URL: https://issues.apache.org/jira/browse/JEXL-205
> Project: Commons JEXL
> Issue Type: Task
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>
> After runnning Jexl tests I have noticed that the thread from
> testCancelForever() test is still executing, and its stack trace is as
> follows:
> {code}
> org.apache.commons.jexl3.ScriptCallableTest$TestContext.runForever(ScriptCallableTest.java:159)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:606)
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.invoke(MethodExecutor.java:93)
> org.apache.commons.jexl3.internal.Interpreter.call(Interpreter.java:1816)
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1535)
> org.apache.commons.jexl3.parser.ASTFunctionNode.jjtAccept(ASTFunctionNode.java:18)
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1119)
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:55)
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:210)
> org.apache.commons.jexl3.internal.Script$Callable.interpret(Script.java:364)
> org.apache.commons.jexl3.internal.Script$Callable.call(Script.java:372)
>- locked org.apache.commons.jexl3.internal.Script$Callable@35595365
> java.util.concurrent.FutureTask.run(FutureTask.java:262)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:745)
> {code}
> may be its worth rewriting the test to something like this
> {code}
> public static class TestContext extends MapContext implements
> JexlContext.NamespaceResolver {
> protected volatile boolean x = false;
> public int runForever() {
> while (true) {
> if (x) {
> break;
> }
> }
> return 1;
> }
> ...
> @Test
> public void testCancelForever() throws Exception {
> JexlScript e = JEXL.createScript("runForever()");
> TestContext tctx = new TestContext();
> Callable c = e.callable(tctx);
> ExecutorService executor = Executors.newFixedThreadPool(1);
> Future future = executor.submit(c);
> Object t = 42;
> try {
> t = future.get(100, TimeUnit.MILLISECONDS);
> Assert.fail("should have timed out");
> } catch (TimeoutException xtimeout) {
> // ok, ignore
> future.cancel(true);
> tctx.x = true;
> } finally {
> executor.shutdown();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-197) Add annotations
[
https://issues.apache.org/jira/browse/JEXL-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362134#comment-15362134
]
Dmitri Blinov commented on JEXL-197:
Well, the thing basically works. Out of curiocity, what is the point to
delegate annotation processing to JexlContext?
> Add annotations
> ---
>
> Key: JEXL-197
> URL: https://issues.apache.org/jira/browse/JEXL-197
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.1
>
>
> Follow up from JEXL-194...
> As an implementation to the extension of statement executions in JEXL we
> could introduce the use of annotations to each statement or block in the
> script, i.e.
> {code}
> @synchronized(items) {for (x : items) ...}
> {code}
> Each statement block should be allowed to have only one annotation but it
> would be convenient to allow the syntax
> {code}
> @silent @lenient {null.tryMe()}
> {code}
> which should be syntaxically equivalent to:
> {code}
> @silent {@lenient {null.tryMe()}}
> {code}
> From the JexlEngine point of view, each annotation could be implemented in
> the form of Interceptor interface, for example
> {code}
> public interface Interceptor {
>public Object onExecute(JexlStatement block, String annotation, Object..
> args);
> }
> {code}
> The annotation syntax should allow for zero, one or more parameters. Those
> parameters should be evaluated before interceptor execution and submitted to
> the Interceptor.onExecute() method via args parameter.
> JexlEngine should be given a method to register annotation interceptor based
> on annotation name, and the one for default interceptor, which should be
> called before each statement execution as if @default annotation is declared
> in each statement in script.
> {code}
> @silent {@default {...}}
> {code}
> The JexlStatement is the proposed new interface to somehow identify the
> statement or block of code which may also provide some info about it's stack
> frame.
> {code}
> public interface JexlStatement {
>public Object interpret();
>// ..
> }
> {code}
> The JexlStatement.interpret() method should trigger the execution of the
> statement block, returning statement's result as its return value.
> In the absence of a matching interceptor corresponding to the annotation
> name, JexlEngine should simply ignore that, or write some diagnostic message
> in the log file.
> Such implementation could provide developers with excellent tool to add
> various checks and enhancements to scripting without pushing for new features
> that eventually would mess up the basic code. The JEXL-185 issue could also
> be dropped since tracing could be added easily via interceptors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JEXL-201) Allow Interpreter to use live values from JexlEngine.Option interface implmented by JexlContext
Dmitri Blinov created JEXL-201: -- Summary: Allow Interpreter to use live values from JexlEngine.Option interface implmented by JexlContext Key: JEXL-201 URL: https://issues.apache.org/jira/browse/JEXL-201 Project: Commons JEXL Issue Type: Improvement Affects Versions: 3.0 Reporter: Dmitri Blinov Interpreter caches the current values of JexlEngine.Option in constructor if JexlEngine.Option interface is implemented by the provided JexlContext. This prevents JexlContext from dynamically influencing Interpreter behaviour by adjusting its values during script evaluation. The intention is to implement for example @silent/@verbose @strict/lenient annotations so that selected parts of the script could be evaluated with the desired mode. I think good point is to allow values from other methods of JexlEngine.Option interface such as isCancellable() and getArithmeticMathScale() not to be cached in Interpreter and JexlArithmetic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JEXL-197) Add annotations
[
https://issues.apache.org/jira/browse/JEXL-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362455#comment-15362455
]
Dmitri Blinov commented on JEXL-197:
Putting the JEXL-185 aside, the first impression is yes, that is what I need.
Now as I'm in the process of adopting this, I think some other issues may
arise, likes JEXL-201, but again - in principle yes, great extensibility point
and great job, many thanks. As for JexlContext, first I was a little puzzled
why it was put in JexlContext but not in JexlArithmetic for example, where
major part of customization code is to be placed, but now I'm starting to think
it's even better that way, since annotations may have access to JexlContext
internal structures.
> Add annotations
> ---
>
> Key: JEXL-197
> URL: https://issues.apache.org/jira/browse/JEXL-197
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.1
>
>
> Follow up from JEXL-194...
> As an implementation to the extension of statement executions in JEXL we
> could introduce the use of annotations to each statement or block in the
> script, i.e.
> {code}
> @synchronized(items) {for (x : items) ...}
> {code}
> Each statement block should be allowed to have only one annotation but it
> would be convenient to allow the syntax
> {code}
> @silent @lenient {null.tryMe()}
> {code}
> which should be syntaxically equivalent to:
> {code}
> @silent {@lenient {null.tryMe()}}
> {code}
> From the JexlEngine point of view, each annotation could be implemented in
> the form of Interceptor interface, for example
> {code}
> public interface Interceptor {
>public Object onExecute(JexlStatement block, String annotation, Object..
> args);
> }
> {code}
> The annotation syntax should allow for zero, one or more parameters. Those
> parameters should be evaluated before interceptor execution and submitted to
> the Interceptor.onExecute() method via args parameter.
> JexlEngine should be given a method to register annotation interceptor based
> on annotation name, and the one for default interceptor, which should be
> called before each statement execution as if @default annotation is declared
> in each statement in script.
> {code}
> @silent {@default {...}}
> {code}
> The JexlStatement is the proposed new interface to somehow identify the
> statement or block of code which may also provide some info about it's stack
> frame.
> {code}
> public interface JexlStatement {
>public Object interpret();
>// ..
> }
> {code}
> The JexlStatement.interpret() method should trigger the execution of the
> statement block, returning statement's result as its return value.
> In the absence of a matching interceptor corresponding to the annotation
> name, JexlEngine should simply ignore that, or write some diagnostic message
> in the log file.
> Such implementation could provide developers with excellent tool to add
> various checks and enhancements to scripting without pushing for new features
> that eventually would mess up the basic code. The JEXL-185 issue could also
> be dropped since tracing could be added easily via interceptors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-202) Detect invalid (addition/subtraction/etc)-assignment operator usage with non-assignable l-value during script parsing
[
https://issues.apache.org/jira/browse/JEXL-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364104#comment-15364104
]
Dmitri Blinov commented on JEXL-202:
Could you please also fix typo in message 'assignement error in..'. should be
'assignment ...
> Detect invalid (addition/subtraction/etc)-assignment operator usage with
> non-assignable l-value during script parsing
> -
>
> Key: JEXL-202
> URL: https://issues.apache.org/jira/browse/JEXL-202
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.0.1
>
>
> While the code like
> {code}
> 2 = 3
> {code} throws exception "assignment error in .." during parsing, the code
> like
> {code}
> 2 += 3
> {code} is parsed successfully and only throws exception "illegal assignment
> form 0" in runtime which makes it harder for debug.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-202) Detect invalid (addition/subtraction/etc)-assignment operator usage with non-assignable l-value during script parsing
[
https://issues.apache.org/jira/browse/JEXL-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15365644#comment-15365644
]
Dmitri Blinov commented on JEXL-202:
Sorry, I meant to remove the 'e' letter from the word assign*e*ment. The phrase
is ok.
> Detect invalid (addition/subtraction/etc)-assignment operator usage with
> non-assignable l-value during script parsing
> -
>
> Key: JEXL-202
> URL: https://issues.apache.org/jira/browse/JEXL-202
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.0.1
>
>
> While the code like
> {code}
> 2 = 3
> {code} throws exception "assignment error in .." during parsing, the code
> like
> {code}
> 2 += 3
> {code} is parsed successfully and only throws exception "illegal assignment
> form 0" in runtime which makes it harder for debug.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-203) JexlArithmetic.options() diverts Interpreter to use default implementation of JexlArithmetic instead of custom one
[
https://issues.apache.org/jira/browse/JEXL-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369613#comment-15369613
]
Dmitri Blinov commented on JEXL-203:
I think more appropriate solution to this would be following the factory
pattern although at the cost of breaking up existing API and binary
compatibility.
For example there would be an interface
{code}
public interface ArithmeticFactory {
// default
public JexlArithmetic createArithmetic();
// with options
public JexlArithmetic createArithmetic(JexlEngine.Options options);
}
{code}
JexlEngine then should be changed to be iniitialized not with the instance of
JexlArithmetic class but instead with an implementation of ArithmeticFactory
where one can choose between the default JexlArithmeticFactory which would
instantiate instances of existing JexlArithmetic class or provide an extended
ArithmeticFactory that would instantiate instances of desired type.
Thus the developer will be given clear understanding of what is required from
him/her to extend JexlArithmetic behaviour.
> JexlArithmetic.options() diverts Interpreter to use default implementation of
> JexlArithmetic instead of custom one
> --
>
> Key: JEXL-203
> URL: https://issues.apache.org/jira/browse/JEXL-203
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Dmitri Blinov
>
> If JexlContext implements JexlEngine.Options and it provides values for
> strictness, scale and MathContext that are different from what was specified
> during creation of JexlArithmetics, then instance of wrong JexlArithmetic
> class is created instead of custom class previously used. Apparently the
> JexlArithmetic.options() method could then be overloaded in custom class, but
> I don't like the idea of copying all that code from version to version, so
> may be more robust solution could be found to this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JEXL-204) Script is not interrupted by a method call throwing Exception
Dmitri Blinov created JEXL-204:
--
Summary: Script is not interrupted by a method call throwing
Exception
Key: JEXL-204
URL: https://issues.apache.org/jira/browse/JEXL-204
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.0
Reporter: Dmitri Blinov
The following test case fails with the message
{quote}
java.lang.AssertionError: should have thrown a Cancel
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.commons.jexl3.ScriptInterruptableTest.testExceptionCancellable(ScriptInterruptableTest.java:73)
{quote}
{code}
@SuppressWarnings({"UnnecessaryBoxing",
"AssertEqualsBetweenInconvertibleTypes"})
public class ScriptInterruptableTest extends JexlTestCase {
//Logger LOGGER = Logger.getLogger(VarTest.class.getName());
public ScriptInterruptableTest() {
super("ScriptInterruptableTest");
}
public static class DummyInterrupt {
public int except() throws Exception {
throw new Exception("Cancelled by purpose");
}
}
public static class TestContext extends MapContext implements
JexlContext.NamespaceResolver {
@Override
public Object resolveNamespace(String name) {
return name == null ? this : null;
}
}
@Test
public void testExceptionCancellable() throws Exception {
JexlEngine jexl = new
JexlBuilder().silent(true).strict(false).cancellable(true).create();
JexlContext ctxt = new TestContext();
ctxt.set("x", new DummyInterrupt());
// run an interrupt
JexlScript sint = jexl.createScript("x.except(); return 42");
Object t = null;
Script.Callable c = (Script.Callable) sint.callable(ctxt);
try {
t = c.call();
if (c.isCancellable()) {
Assert.fail("should have thrown a Cancel");
}
} catch (JexlException.Cancel xjexl) {
if (!c.isCancellable()) {
Assert.fail("should not have thrown " + xjexl);
}
}
Assert.assertTrue(c.isCancelled());
Assert.assertNotEquals(42, t);
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JEXL-203) JexlArithmetic.options() diverts Interpreter to use default implementation of JexlArithmetic instead of custom one
Dmitri Blinov created JEXL-203: -- Summary: JexlArithmetic.options() diverts Interpreter to use default implementation of JexlArithmetic instead of custom one Key: JEXL-203 URL: https://issues.apache.org/jira/browse/JEXL-203 Project: Commons JEXL Issue Type: Bug Reporter: Dmitri Blinov If JexlContext implements JexlEngine.Options and it provides values for strictness, scale and MathContext that are different from what was specified during creation of JexlArithmetics, then instance of wrong JexlArithmetic class is created instead of custom class previously used. Apparently the JexlArithmetic.options() method could then be overloaded in custom class, but I don't like the idea of copying all that code from version to version, so may be more robust solution could be found to this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JEXL-202) Detect invalid (addition/subtraction/etc)-assignment operator usage with non-assignable l-value during script parsing
Dmitri Blinov created JEXL-202:
--
Summary: Detect invalid (addition/subtraction/etc)-assignment
operator usage with non-assignable l-value during script parsing
Key: JEXL-202
URL: https://issues.apache.org/jira/browse/JEXL-202
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.0
Reporter: Dmitri Blinov
Priority: Minor
While the code like
{code}
2 = 3
{code} throws exception "assignment error in .." during parsing, the code like
{code}
2 += 3
{code} is parsed successfully and only throws exception "illegal assignment
form 0" in runtime which makes it harder for debug.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-208) Documentation typos/inconsistencies
[ https://issues.apache.org/jira/browse/JEXL-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422538#comment-15422538 ] Dmitri Blinov commented on JEXL-208: I also have prepared a PR #3 regarding some typos in documentation, can it be applied? > Documentation typos/inconsistencies > --- > > Key: JEXL-208 > URL: https://issues.apache.org/jira/browse/JEXL-208 > Project: Commons JEXL > Issue Type: Bug > Environment: (Chrome MacOSX) >Reporter: Joe Tom >Priority: Trivial > Fix For: 3.1 > > > Noticed on > https://commons.apache.org/proper/commons-jexl/reference/syntax.html that > there are two operands that are defined then in the examples reversed. > Starts With=^ > The syntactically ... "abcdef" ^= "abc" returns true. Note that through > duck-typing, user classes exposing a public 'startsWith' method will allow > their instances to behave has left-hand-size operands of this operator. > AND > Not Starts With!^ > This is the negation of the 'starts with' operator. a ^! "abc" is ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JEXL-220) Release 3.1 to Maven Repository
[ https://issues.apache.org/jira/browse/JEXL-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15832877#comment-15832877 ] Dmitri Blinov commented on JEXL-220: I can confirm that on my site the current build works without any known issues so I think it is ready for release. Though it would be nice before to fix JEXL-211 since its only one line of the code and does not break any interfaces. My 2p. > Release 3.1 to Maven Repository > --- > > Key: JEXL-220 > URL: https://issues.apache.org/jira/browse/JEXL-220 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.1 >Reporter: Doug Whitehead >Priority: Minor > > Any chance version 3.1 is scheduled for a release to the Maven Repository any > time soon? Seems like there are plenty of improvements and bug fixes to > warrant a release, and also -- last release was a year go at this point :) > https://mvnrepository.com/artifact/org.apache.commons/commons-jexl3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JEXL-212) Restrict usage of assignment statements in JexlExpression
Dmitri Blinov created JEXL-212: -- Summary: Restrict usage of assignment statements in JexlExpression Key: JEXL-212 URL: https://issues.apache.org/jira/browse/JEXL-212 Project: Commons JEXL Issue Type: Improvement Affects Versions: 3.0 Reporter: Dmitri Blinov Priority: Minor There is no possibility now to create a form of expression that can not modify the context it is evaluated against, i.e. use only property references or method calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JEXL-211) Add callable method to JexlExpression interface
Dmitri Blinov created JEXL-211:
--
Summary: Add callable method to JexlExpression interface
Key: JEXL-211
URL: https://issues.apache.org/jira/browse/JEXL-211
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Dmitri Blinov
It would be convenient to have the following method
{code}
Callable callable(JexlContext context);
{code}
in both JexlExpression and JexlScript interfaces.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JEXL-211) Add callable method to JexlExpression interface
[
https://issues.apache.org/jira/browse/JEXL-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov updated JEXL-211:
---
Priority: Minor (was: Major)
> Add callable method to JexlExpression interface
> ---
>
> Key: JEXL-211
> URL: https://issues.apache.org/jira/browse/JEXL-211
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Priority: Minor
>
> It would be convenient to have the following method
> {code}
>Callable callable(JexlContext context);
> {code}
> in both JexlExpression and JexlScript interfaces.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JEXL-218) Overloaded JexlArithmetic.empty() method is not called for a class implementing Map interface
[
https://issues.apache.org/jira/browse/JEXL-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-218.
--
Resolution: Not A Problem
Fix Version/s: 3.0
This issue was resolved as bug in client code, has nothing to do with jexl,
sorry.
> Overloaded JexlArithmetic.empty() method is not called for a class
> implementing Map interface
> -
>
> Key: JEXL-218
> URL: https://issues.apache.org/jira/browse/JEXL-218
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
> Fix For: 3.0
>
>
> Sorry for not providing a test case but this is a rare problem I haven't
> managed to catch. I have a class which implements a {{Map}} interface and I
> have an overloaded {{JexlArithmetic.empty()}} and {{JexlArithmetic.size()}}
> methods for this class, and these methods are *not* related to correspondent
> {{Map.isEmpty()}} and {{Map.size()}} methods, they provide separate semantics
> in my case. Apart from the point that this design is questionable, most of
> the time everything works as expected in jexl, i.e. when {code}empty(x){code}
> or {code}size(x){code} operators are used in scripting, the overloaded
> {{JexlArithmetic.empty()}} and {{JexlArithmetic.size()}} are called. But
> sometimes in rare circumstances these operators are not called and
> {{Map.isEmpty()}} and {{Map.size()}} methods respectively are called instead.
> I suspect this has something to do with operators caching, may be you'll be
> able to check the code?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JEXL-218) Overloaded JexlArithmetic.empty() method is not called for a class implementing Map interface
Dmitri Blinov created JEXL-218:
--
Summary: Overloaded JexlArithmetic.empty() method is not called
for a class implementing Map interface
Key: JEXL-218
URL: https://issues.apache.org/jira/browse/JEXL-218
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.0
Reporter: Dmitri Blinov
Sorry for not providing a test case but this is a rare problem I haven't
managed to catch. I have a class which implements a {{Map}} interface and I
have an overloaded {{JexlArithmetic.empty()}} and {{JexlArithmetic.size()}}
methods for this class, and these methods are *not* related to correspondent
{{Map.isEmpty()}} and {{Map.size()}} methods, they provide separate semantics
in my case. Apart from the point that this design is questionable, most of the
time everything works as expected in jexl, i.e. when {code}empty(x){code} or
{code}size(x){code} operators are used in scripting, the overloaded
{{JexlArithmetic.empty()}} and {{JexlArithmetic.size()}} are called. But
sometimes in rare circumstances these operators are not called and
{{Map.isEmpty()}} and {{Map.size()}} methods respectively are called instead. I
suspect this has something to do with operators caching, may be you'll be able
to check the code?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JEXL-213) rename JexlBuilder.loader(Charset arg) to JexlBuilder.charset(Charset arg)
Dmitri Blinov created JEXL-213:
--
Summary: rename JexlBuilder.loader(Charset arg) to
JexlBuilder.charset(Charset arg)
Key: JEXL-213
URL: https://issues.apache.org/jira/browse/JEXL-213
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.0
Reporter: Dmitri Blinov
Priority: Minor
There seems to be a copy-paste bug in method in {{JexlBuilder}} class
{code}
public JexlBuilder loader(Charset arg) {
this.charset = arg;
return this;
}
{code}
obviously the method should be named {{charset}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JEXL-217) Interpreter.getAttribute() raises exception in non-strict mode when cached property resolver is used
Dmitri Blinov created JEXL-217:
--
Summary: Interpreter.getAttribute() raises exception in non-strict
mode when cached property resolver is used
Key: JEXL-217
URL: https://issues.apache.org/jira/browse/JEXL-217
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.0
Reporter: Dmitri Blinov
I'm chasing strange bug where regardless of the {{JexlContext}} operating in
non-strict mode the {{ArrayIndexOutOfBoundsException}} is thrown in the script
like this
{code}
entity = args[0]; @lenient {copy = args[1]; xwsp = args[2]}
{code}
here is the stack trace
{quote}
Caused by: java.lang.ArrayIndexOutOfBoundsException
at java.lang.reflect.Array.get(Native Method)
at
org.apache.commons.jexl3.internal.introspection.ListGetExecutor.tryInvoke(ListGetExecutor.java:88)
at
org.apache.commons.jexl3.internal.Interpreter.getAttribute(Interpreter.java:1700)
at
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:945)
at
org.apache.commons.jexl3.parser.ASTArrayAccess.jjtAccept(ASTArrayAccess.java:18)
at
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1013)
at
org.apache.commons.jexl3.parser.ASTReference.jjtAccept(ASTReference.java:18)
at
org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1119)
at
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1062)
at
org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18)
at
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:578)
at org.apache.commons.jexl3.parser.ASTBlock.jjtAccept(ASTBlock.java:18)
at
org.apache.commons.jexl3.internal.Interpreter.processAnnotation(Interpreter.java:1848)
at
org.apache.commons.jexl3.internal.Interpreter$1.call(Interpreter.java:1856)
{quote}
Unfortunately I haven't managed to create and provide reproducible test case,
but from looking into the code I think the problem fires when the Interpreter
tries to call cached method {{ListGetExecutor.tryInvoke()}} but does not catch
subsequent exception.
I rewrote the code as follows and the problem seemed to go away
{code:title=Interpreter.java}
...
Exception xcause = null;
// attempt to reuse last executor cached in volatile JexlNode.value
if (node != null && cache) {
Object cached = node.jjtGetValue();
if (cached instanceof JexlPropertyGet) {
JexlPropertyGet vg = (JexlPropertyGet) cached;
try {
Object value = vg.tryInvoke(object, attribute);
if (!vg.tryFailed(value)) {
return value;
}
} catch (Exception xany) {
xcause = xany;
}
}
}
if (xcause == null) {
// resolve that property
List resolvers = uberspect.getResolvers(operator,
object);
JexlPropertyGet vg = uberspect.getPropertyGet(resolvers, object,
attribute);
if (vg != null) {
try {
Object value = vg.invoke(object);
// cache executor in volatile JexlNode.value
if (node != null && cache && vg.isCacheable()) {
node.jjtSetValue(vg);
}
return value;
} catch (Exception xany) {
xcause = xany;
}
}
}
...
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-208) Documentation typos/inconsistencies
[
https://issues.apache.org/jira/browse/JEXL-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15441147#comment-15441147
]
Dmitri Blinov commented on JEXL-208:
Sorry I don't know which diff format to use, this is the one I got from github
{code}
diff --git a/src/site/xdoc/reference/syntax.xml
b/src/site/xdoc/reference/syntax.xml
index c6a85b2..cc034b8 100644
--- a/src/site/xdoc/reference/syntax.xml
+++ b/src/site/xdoc/reference/syntax.xml
@@ -538,7 +538,7 @@
It also checks whether any collection, set or map (on
keys) contains a value or not; in that case, it behaves
as an "in" operator.
Note that arrays and user classes exposing a public
'contains' method will allow their instances
-to behave has right-hand side operands of this
operator.
+to behave as right-hand side operands of this operator.
"a" =~ ["a","b","c","d","e",f"] returns
true.
@@ -552,7 +552,7 @@
It also checks whether any collection, set or map (on
keys) does not contain a value; in that case, it behaves
as "not in" operator.
Note that arrays and user classes exposing a public
'contains' method will allow their instances
-to behave has right-hand side operands of this
operator.
+to behave as right-hand side operands of this operator.
"a" !~ ["a","b","c","d","e",f"] returns
true.
@@ -562,7 +562,7 @@
The =^ operator is a short-hand for the
'startsWith' method.
For example, "abcdef" =^ "abc" returns
true.
Note that through duck-typing, user classes exposing a
public 'startsWith' method will allow their instances
-to behave has left-hand side operands of this operator.
+to behave as left-hand side operands of this operator.
@@ -577,7 +577,7 @@
The =$ operator is a short-hand for the
'endsWith' method.
For example, "abcdef" =$ "def" returns
true.
Note that through duck-typing, user classes exposing
an 'endsWith' method will allow their instances
-to behave has left-hand side operands of this operator.
+to behave as left-hand side operands of this operator.
{code}
> Documentation typos/inconsistencies
> ---
>
> Key: JEXL-208
> URL: https://issues.apache.org/jira/browse/JEXL-208
> Project: Commons JEXL
> Issue Type: Bug
> Environment: (Chrome MacOSX)
>Reporter: Joe Tom
>Priority: Trivial
> Fix For: 3.1
>
>
> Noticed on
> https://commons.apache.org/proper/commons-jexl/reference/syntax.html that
> there are two operands that are defined then in the examples reversed.
> Starts With=^
> The syntactically ... "abcdef" ^= "abc" returns true. Note that through
> duck-typing, user classes exposing a public 'startsWith' method will allow
> their instances to behave has left-hand-size operands of this operator.
> AND
> Not Starts With!^
> This is the negation of the 'starts with' operator. a ^! "abc" is ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-215) JexlEngine.createInfo() is redundantly called when debug and caching is enabled leading to sub-optimal performance
[
https://issues.apache.org/jira/browse/JEXL-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15441364#comment-15441364
]
Dmitri Blinov commented on JEXL-215:
The same applies to methods {{Engine.getProperty()}} and
{{Engine.setProperty()}} also
> JexlEngine.createInfo() is redundantly called when debug and caching is
> enabled leading to sub-optimal performance
> --
>
> Key: JEXL-215
> URL: https://issues.apache.org/jira/browse/JEXL-215
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>
> The following two methods {{Engine.createScript()}} and
> {{Engine.createExpression()}} are calling {{JexlEngine.createInfo()}} when
> debug mode is enabled and JexlInfo is not provided. But if caching is enabled
> the method {{Engine.parse()}} will not use provided JexlInfo if the requested
> statement is already in the cache. This leads to sub-optimal performance, in
> my measurements up to 100 times slower. The suggestion is to refactor by
> removing the following code
> {code}
> if (info == null && debug) {
> info = createInfo();
> }
> {code}
> from methods {{Engine.createScript()}} and {{Engine.createExpression()}} and
> adding to the method {{Engine.parse()}} after the cache check, like this
> {code}
> protected ASTJexlScript parse(JexlInfo info, String src, Scope scope,
> boolean registers, boolean expression) {
> final boolean cached = src.length() < cacheThreshold && cache != null;
> ASTJexlScript script;
> synchronized (parser) {
> if (cached) {
> script = cache.get(src);
> if (script != null) {
> Scope f = script.getScope();
> if ((f == null && scope == null) || (f != null &&
> f.equals(scope))) {
> return script;
> }
> }
> }
> if (info == null && debug) {
> info = createInfo();
> }
> script = parser.parse(info, src, scope, registers, expression);
> if (cached) {
> cache.put(src, script);
> }
> }
> return script;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JEXL-216) Improve parsing concurrency in multithreaded environment
[
https://issues.apache.org/jira/browse/JEXL-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov updated JEXL-216:
---
Description: At the moment the {{Engine.parse()}} method synchronizes on
{{parser}} member even if the caching is enabled and the actual parsing is not
required, in case of cache hit. This effectively serializes processing of
scripts and expressions in multithreaded scenario. The suggestion is to
separate synchronization on cache from synchronization on parser, with the
latter only being performed if actual parsing is required. (was: At the moment
the {{Engine.parse()}} method synchronizes on parser member even if the caching
is enabled and the actual parsing is not required, in case of cache hit. This
effectively serializes processing of scripts and expressions in multithreaded
scenario. The suggestion is to separate synchronization on cache from
synchronization on parser, with the latter only being performed if actual
parsing is required.)
> Improve parsing concurrency in multithreaded environment
>
>
> Key: JEXL-216
> URL: https://issues.apache.org/jira/browse/JEXL-216
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Priority: Minor
>
> At the moment the {{Engine.parse()}} method synchronizes on {{parser}} member
> even if the caching is enabled and the actual parsing is not required, in
> case of cache hit. This effectively serializes processing of scripts and
> expressions in multithreaded scenario. The suggestion is to separate
> synchronization on cache from synchronization on parser, with the latter only
> being performed if actual parsing is required.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JEXL-216) Improve parsing concurrency in multithreaded environment
Dmitri Blinov created JEXL-216:
--
Summary: Improve parsing concurrency in multithreaded environment
Key: JEXL-216
URL: https://issues.apache.org/jira/browse/JEXL-216
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Dmitri Blinov
Priority: Minor
At the moment the {{Engine.parse()}} method synchronizes on parser member even
if the caching is enabled and the actual parsing is not required, in case of
cache hit. This effectively serializes processing of scripts and expressions in
multithreaded scenario. The suggestion is to separate synchronization on cache
from synchronization on parser, with the latter only being performed if actual
parsing is required.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JEXL-214) Redundant call of fillInStackTrace() in JexlEngine.createInfo() ?
Dmitri Blinov created JEXL-214:
--
Summary: Redundant call of fillInStackTrace() in
JexlEngine.createInfo() ?
Key: JEXL-214
URL: https://issues.apache.org/jira/browse/JEXL-214
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.0
Reporter: Dmitri Blinov
I wonder what is the call of {{fillInStackTrace()}} for ?
{code}
public JexlInfo createInfo() {
JexlInfo info = null;
Throwable xinfo = new Throwable();
xinfo.fillInStackTrace();
...
{code}
As far as I know the constructor of Throwable is implemented already calling
this method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JEXL-215) JexlEngine.createInfo() is redundantly called when debug and caching is enabled leading to sub-optimal performance
Dmitri Blinov created JEXL-215:
--
Summary: JexlEngine.createInfo() is redundantly called when debug
and caching is enabled leading to sub-optimal performance
Key: JEXL-215
URL: https://issues.apache.org/jira/browse/JEXL-215
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Dmitri Blinov
The following two methods {{Engine.createScript()}} and
{{Engine.createExpression()}} are calling {{JexlEngine.createInfo()}} when
debug mode is enabled and JexlInfo is not provided. But if caching is enabled
the method {{Engine.parse()}} will not use provided JexlInfo if the requested
statement is already in the cache. This leads to sub-optimal performance, in my
measurements up to 100 times slower. The suggestion is to refactor by removing
the following code
{code}
if (info == null && debug) {
info = createInfo();
}
{code}
from methods {{Engine.createScript()}} and {{Engine.createExpression()}} and
adding to the method {{Engine.parse()}} after the cache check, like this
{code}
protected ASTJexlScript parse(JexlInfo info, String src, Scope scope,
boolean registers, boolean expression) {
final boolean cached = src.length() < cacheThreshold && cache != null;
ASTJexlScript script;
synchronized (parser) {
if (cached) {
script = cache.get(src);
if (script != null) {
Scope f = script.getScope();
if ((f == null && scope == null) || (f != null &&
f.equals(scope))) {
return script;
}
}
}
if (info == null && debug) {
info = createInfo();
}
script = parser.parse(info, src, scope, registers, expression);
if (cached) {
cache.put(src, script);
}
}
return script;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-211) Add callable method to JexlExpression interface
[
https://issues.apache.org/jira/browse/JEXL-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15432701#comment-15432701
]
Dmitri Blinov commented on JEXL-211:
Yes It's what I think the method {{callable}} should be exposed by
JexlExpression also.
> Add callable method to JexlExpression interface
> ---
>
> Key: JEXL-211
> URL: https://issues.apache.org/jira/browse/JEXL-211
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Priority: Minor
>
> It would be convenient to have the following method
> {code}
>Callable callable(JexlContext context);
> {code}
> in both JexlExpression and JexlScript interfaces.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-222) The ability to declare indexed property getter/setter in customised JexlArithmetic implementation
[
https://issues.apache.org/jira/browse/JEXL-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925764#comment-15925764
]
Dmitri Blinov commented on JEXL-222:
It has worked for me with the following code:
{code}
...public Object propertySet(IndexedType.IndexedContainer map, String
key, Integer value) {
if
(PropertyContainer.class.isAssignableFrom(map.getContainerClass())
&& map.getContainerName().equals("property")) {
try {
map.set(key, value.toString());
} catch (Exception xany) {
throw new JexlException.Operator(null,
map.getContainerClass() + "." + key, xany);
}
return null;
}
return JexlEngine.TRY_FAILED;
}
...
{code}
Great work, thanks!
> The ability to declare indexed property getter/setter in customised
> JexlArithmetic implementation
> -
>
> Key: JEXL-222
> URL: https://issues.apache.org/jira/browse/JEXL-222
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.1
>
>
> At the moment we have the ability to declare a specific getter/setter method
> in customized JexlArithmetic class that will be used by Jexl engine when
> engine tries to get access to a property of some object. This is great
> extension point of the Jexl but I have come to a situation where I need the
> same technics to be applied to indexed properties. For example I'm scripting
> org.w3c.dom.Element object by setting its attributes via its
> {code}Element.setAttribute(java.lang.String name, java.lang.String value)
> {code} method. In Jexl I use standard indexed property access syntax like the
> following: {code} node.attribute.id = "12345"; {code} The problem lies with
> the last argument of the setAttribute method which is of String class. And
> for Jexl standard indexed property setter to work I should always remember
> that in script I need to cast specified property value to a string, which is
> error-prone and lacks, in my understanding, scripting easiness. I see the
> solution as to introduce custom indexed property setter in more generalized
> form, accepting Object type as a value so it could cast a value to String
> before calling {{Element.setAttribute}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (JEXL-221) Sporadic undefined property error caused by NPE at MapGetExecutor.tryInvoke()
[
https://issues.apache.org/jira/browse/JEXL-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15902603#comment-15902603
]
Dmitri Blinov commented on JEXL-221:
Do you think we could also cross-check other Get|SetExecutors for similar bugs?
> Sporadic undefined property error caused by NPE at MapGetExecutor.tryInvoke()
> -
>
> Key: JEXL-221
> URL: https://issues.apache.org/jira/browse/JEXL-221
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>
> I'm getting sporadic undefined property error when accessing hashmap by a
> key. The stack trace tells the cause is NPE in MapGetExecutor.tryInvoke() at
> the following line:
> {code}
> if (obj != null && method != null
> && objectClass.equals(obj.getClass())
> && (key == null ||
> property.getClass().equals(key.getClass( {
> {code}
> I have managed to overcome this issue by adding the following null check:
> {code}
> if (obj != null && method != null
> && objectClass.equals(obj.getClass())
> && (key == null || property != null &&
> property.getClass().equals(key.getClass( {
> {code}
> I have only vague understanding of how things work inside jexl with
> tryInvoke() and unfortunately can not provide any test case for this, but it
> has worked in my case, so if nobody have any objections please include the
> fix in source tree.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (JEXL-222) The ability to declare indexed property getter/setter in customised JexlArithmetic implementation
Dmitri Blinov created JEXL-222:
--
Summary: The ability to declare indexed property getter/setter in
customised JexlArithmetic implementation
Key: JEXL-222
URL: https://issues.apache.org/jira/browse/JEXL-222
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Dmitri Blinov
Priority: Minor
At the moment we have the ability to declare a specific getter/setter method in
customized JexlArithmetic class that will be used by Jexl engine when engine
tries to get access to a property of some object. This is great extension point
of the Jexl but I have come to a situation where I need the same technics to be
applied to indexed properties. For example I'm scripting org.w3c.dom.Element
object by setting its attributes via its
{code}Element.setAttribute(java.lang.String name, java.lang.String value)
{code} method. In Jexl I use standard indexed property access syntax like the
following: {code} node.attribute.id = "12345"; {code} The problem lies with the
last argument of the setAttribute method which is of String class. And for Jexl
standard indexed property setter to work I should always remember that in
script I need to cast specified property value to a string, which is
error-prone and lacks, in my understanding, scripting easiness. I see the
solution as to introduce custom indexed property setter in more generalized
form, accepting Object type as a value so it could cast a value to String
before calling {{Element.setAttribute}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (JEXL-221) Sporadic undefined property error caused by NPE at MapGetExecutor.tryInvoke()
Dmitri Blinov created JEXL-221:
--
Summary: Sporadic undefined property error caused by NPE at
MapGetExecutor.tryInvoke()
Key: JEXL-221
URL: https://issues.apache.org/jira/browse/JEXL-221
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.0
Reporter: Dmitri Blinov
I'm getting sporadic undefined property error when accessing hashmap by a key.
The stack trace tells the cause is NPE in MapGetExecutor.tryInvoke() at the
following line:
{code}
if (obj != null && method != null
&& objectClass.equals(obj.getClass())
&& (key == null || property.getClass().equals(key.getClass(
{
{code}
I have managed to overcome this issue by adding the following null check:
{code}
if (obj != null && method != null
&& objectClass.equals(obj.getClass())
&& (key == null || property != null &&
property.getClass().equals(key.getClass( {
{code}
I have only vague understanding of how things work inside jexl with tryInvoke()
and unfortunately can not provide any test case for this, but it has worked in
my case, so if nobody have any objections please include the fix in source tree.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (JEXL-237) Ability to restrict usage of certain names when declaring local variables
Dmitri Blinov created JEXL-237: -- Summary: Ability to restrict usage of certain names when declaring local variables Key: JEXL-237 URL: https://issues.apache.org/jira/browse/JEXL-237 Project: Commons JEXL Issue Type: Wish Affects Versions: 3.1 Reporter: Dmitri Blinov Priority: Minor One of the errors the scriptwriter usually makes is an accidental override of certain context variables with his own local variables, which leads to nasty bugs detected only when script is executed. As of now there is only a small list of reserved words that can not be used as a valid variable name, and it is restricted to basic Jexl syntax keywords. When Jexl syntax is extended with custom functions and predefined context variables, its much easier for a local variable name to clash with predefined name, thus altering script execution further on. To exclude those errors it is needed that a custom name verification would exist, prohibiting the scripts from be successfully parsed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JEXL-232) Use Class types as functors to create object instances
Dmitri Blinov created JEXL-232:
--
Summary: Use Class types as functors to create object instances
Key: JEXL-232
URL: https://issues.apache.org/jira/browse/JEXL-232
Project: Commons JEXL
Issue Type: Wish
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Minor
It would allow to write more compact and java-like scripts if it would be
possible to use the Class types as functors to call appropriate constructor to
create object instances, e.g.
{code}
x = HashMap(10, 0.75);
{code}
where {{HashMap}} is the variable of the {{java.lang.Class}} type.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JEXL-234) Extend application of operators startsWith and endsWith from String to CharSequence types
Dmitri Blinov created JEXL-234:
--
Summary: Extend application of operators startsWith and endsWith
from String to CharSequence types
Key: JEXL-234
URL: https://issues.apache.org/jira/browse/JEXL-234
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Minor
It would be more useful to have operators {{=$}} and {{=^}} to work with
objects that support {{CharSequence}} interface, like {{StringBuilder}}, which
would have more broad usage then just with {{String}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JEXL-234) Extend application of operators startsWith and endsWith from String to CharSequence types
[
https://issues.apache.org/jira/browse/JEXL-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov updated JEXL-234:
---
Attachment: patch0.patch
> Extend application of operators startsWith and endsWith from String to
> CharSequence types
> -
>
> Key: JEXL-234
> URL: https://issues.apache.org/jira/browse/JEXL-234
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
> Attachments: patch0.patch
>
>
> It would be more useful to have operators {{=$}} and {{=^}} to work with
> objects that support {{CharSequence}} interface, like {{StringBuilder}},
> which would have more broad usage then just with {{String}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-234) Extend application of operators startsWith and endsWith from String to CharSequence types
[
https://issues.apache.org/jira/browse/JEXL-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070283#comment-16070283
]
Dmitri Blinov commented on JEXL-234:
I usually try to propose an improvement if I think the use case is generic and
regards basic java classes so that the community may benefit from it. Here is
the patch.
> Extend application of operators startsWith and endsWith from String to
> CharSequence types
> -
>
> Key: JEXL-234
> URL: https://issues.apache.org/jira/browse/JEXL-234
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
> Attachments: patch0.patch
>
>
> It would be more useful to have operators {{=$}} and {{=^}} to work with
> objects that support {{CharSequence}} interface, like {{StringBuilder}},
> which would have more broad usage then just with {{String}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-233) Documentation rewrite
[ https://issues.apache.org/jira/browse/JEXL-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071052#comment-16071052 ] Dmitri Blinov commented on JEXL-233: There are so many ways to tell a strory, indeed. So, first we need to agree what kind of documentation we need, or how it should be organized. From similar scripting language projects I see that every language comes with either a language reference or language specification. The documentation usualy contains a brief introduction, syntax overview, and then continues with more deep dive about operator behaviour, property resolution order, type casting, integration, customization etc. Examples are usually placed inside the sections they are to illustrate. I think we need the same language reference, with syntax overview for end-users being a chapter at the beginning. So we need to stop thinking about syntax.xml and start thinking about reference.xml to put everything in order > Documentation rewrite > - > > Key: JEXL-233 > URL: https://issues.apache.org/jira/browse/JEXL-233 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Minor > Attachments: syntax.xml > > > I have reorganized the JEXL syntax doc, basically adjusted the document > structure to be more logical in my view, and brushed up some descriptions. > Comments are welcome! If it is ok, please promote the attachment to the > source tree. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JEXL-236) Support CharSequence in size(), empty() and contains() operators
[
https://issues.apache.org/jira/browse/JEXL-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov updated JEXL-236:
---
Attachment: patch0.patch
> Support CharSequence in size(), empty() and contains() operators
>
>
> Key: JEXL-236
> URL: https://issues.apache.org/jira/browse/JEXL-236
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
> Attachments: patch0.patch
>
>
> I would be convenient if JEXL would support out of the box the broader
> {{CharSequence}} interface instead of {{String}} for operators like
> {{size()}}, {{empty()}} and {{=~}}. I have prepared a patch for this. If
> nobody has any objections, please promote it to the source tree. Thanks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JEXL-236) Support CharSequence in size(), empty() and contains() operators
Dmitri Blinov created JEXL-236:
--
Summary: Support CharSequence in size(), empty() and contains()
operators
Key: JEXL-236
URL: https://issues.apache.org/jira/browse/JEXL-236
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Minor
Attachments: patch0.patch
I would be convenient if JEXL would support out of the box the broader
{{CharSequence}} interface instead of {{String}} for operators like {{size()}},
{{empty()}} and {{=~}}. I have prepared a patch for this. If nobody has any
objections, please promote it to the source tree. Thanks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JEXL-233) Documentation rewrite
Dmitri Blinov created JEXL-233: -- Summary: Documentation rewrite Key: JEXL-233 URL: https://issues.apache.org/jira/browse/JEXL-233 Project: Commons JEXL Issue Type: Improvement Affects Versions: 3.1 Reporter: Dmitri Blinov Priority: Minor I have reorganized the JEXL syntax doc, basically adjusted the document structure to be more logical in my view, and brushed up some descriptions. Comments are welcome! If it is ok, please promote the attachment to the source tree. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JEXL-233) Documentation rewrite
[ https://issues.apache.org/jira/browse/JEXL-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitri Blinov updated JEXL-233: --- Attachment: syntax.xml > Documentation rewrite > - > > Key: JEXL-233 > URL: https://issues.apache.org/jira/browse/JEXL-233 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Minor > Attachments: syntax.xml > > > I have reorganized the JEXL syntax doc, basically adjusted the document > structure to be more logical in my view, and brushed up some descriptions. > Comments are welcome! If it is ok, please promote the attachment to the > source tree. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JEXL-224) The ability to overload call() operator in customized JexlArithmetic implementation
Dmitri Blinov created JEXL-224:
--
Summary: The ability to overload call() operator in customized
JexlArithmetic implementation
Key: JEXL-224
URL: https://issues.apache.org/jira/browse/JEXL-224
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Minor
As of now there is a possibility to overload some operators and property
accessors in JexlArithmetic, such as {{[]}}, {{.}} and {{~=}}, which is great
extension point of Jexl. Suppose I want to implement index-based access to a
{{j.u.Collection}} instance in a manner that {{a(0)}} would return the first
element of collection, {{a(1)}} would return the second and so forth. This is
different from using common access operator {{[]}} in a way that I specify not
the index key of for example ArrayList, but an ordered index of the element. Of
course, the is a possibility to introduce some function to this, but for the
sake of the scripting simplicity I'm looking for the short version, like the
call operator {{()}}. As of now I can only implement this behavior for the
classes that are written by me, via adding a call() method to class
declaration.But in the case of java.util.Collection this is not possible. So it
would be great if Jexl could allow to overload a call() method in
JexlArithmetic class in a way the propertyGet/arrayGet methods are now can be
overloaded.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (JEXL-227) JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 3.1 as of reporting
Dmitri Blinov created JEXL-227:
--
Summary: JexlScriptEngineFactory.getEngineVersion() should return
actual version, ie 3.1 as of reporting
Key: JEXL-227
URL: https://issues.apache.org/jira/browse/JEXL-227
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Minor
JexlScriptEngineFactory.getEngineVersion() reports "3.0" as a script engine
version in 3.1
{code}
public String getEngineVersion() {
return "3.0"; // ensure this is updated if function changes are made to
this class
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-224) The ability to overload call() operator in customized JexlArithmetic implementation
[
https://issues.apache.org/jira/browse/JEXL-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059241#comment-16059241
]
Dmitri Blinov commented on JEXL-224:
I have managed to achieve what I whanted by overriding
{{Uberspect.getMethod()}} and implementing custom JexlMethod class
{code}
protected class CollectionJexlMethod implements JexlMethod {
public CollectionJexlMethod() {
}
@Override
public Object invoke(Object obj, Object... params) throws Exception {
if (obj instanceof Collection && params != null && params.length == 1)
{
Collection c = (Collection) obj;
int i = TypeCast.getInt(params[0]);
for (Object o : c) {
if (i-- == 0)
return o;
}
}
return null;
}
@Override
public Object tryInvoke(String name, Object obj, Object... params) {
if (obj instanceof Collection && "call".equals(name) && params != null
&& params.length == 1) {
Collection c = (Collection) obj;
int i = TypeCast.getInt(params[0]);
for (Object o : c) {
if (i-- == 0)
return o;
}
}
return JexlEngine.TRY_FAILED;
}
@Override
public boolean tryFailed(Object rval) {
return rval == JexlEngine.TRY_FAILED;
}
@Override
public boolean isCacheable() {
return true;
}
@Override
public Class getReturnType() {
return Object.class;
}
}
@Override
public JexlMethod getMethod(Object obj, String method, Object... args) {
JexlMethod result = super.getMethod(obj, method, args);
if (result == null) {
if (obj instanceof Collection && "call".equals(method) && args != null
&& args.length == 1) {
result = new CollectionJexlMethod();
}
}
return result;
}
{code}
The code is not as eloquent as it would be with JEXL-224 implemented, but it
seems to work and I don't know if the issue is still worth fixing
> The ability to overload call() operator in customized JexlArithmetic
> implementation
> ---
>
> Key: JEXL-224
> URL: https://issues.apache.org/jira/browse/JEXL-224
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> As of now there is a possibility to overload some operators and property
> accessors in JexlArithmetic, such as {{[]}}, {{.}} and {{~=}}, which is great
> extension point of Jexl. Suppose I want to implement index-based access to a
> {{j.u.Collection}} instance in a manner that {{a(0)}} would return the first
> element of collection, {{a(1)}} would return the second and so forth. This is
> different from using common access operator {{[]}} in a way that I specify
> not the index key of for example ArrayList, but an ordered index of the
> element. Of course, the is a possibility to introduce some function to this,
> but for the sake of the scripting simplicity I'm looking for the short
> version, like the call operator {{()}}. As of now I can only implement this
> behavior for the classes that are written by me, via adding a call() method
> to class declaration.But in the case of java.util.Collection this is not
> possible. So it would be great if Jexl could allow to overload a call()
> method in JexlArithmetic class in a way the propertyGet/arrayGet methods are
> now can be overloaded.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-227) JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 3.1 as of reporting
[
https://issues.apache.org/jira/browse/JEXL-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16061793#comment-16061793
]
Dmitri Blinov commented on JEXL-227:
Shouldn't we simply go away from precompiled values and take values of engine
version and language version from jexl jar's manifest properties, like
Implementation_Version and Specification_version?
> JexlScriptEngineFactory.getEngineVersion() should return actual version, ie
> 3.1 as of reporting
> ---
>
> Key: JEXL-227
> URL: https://issues.apache.org/jira/browse/JEXL-227
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> JexlScriptEngineFactory.getEngineVersion() reports "3.0" as a script engine
> version in 3.1
> {code}
> public String getEngineVersion() {
> return "3.0"; // ensure this is updated if function changes are made
> to this class
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-230) List literal is not mentioned in docs
[
https://issues.apache.org/jira/browse/JEXL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062998#comment-16062998
]
Dmitri Blinov commented on JEXL-230:
As far as I know we have two different syntaxes here, the one which creates
arrays, like the follows
{code}
[1,2,3]
{code}
and the other one which creates an ArrayList, like the follows
{code}
[1,2,3,...]
{code}
Syntax is similar, but since it allows for creation of different objects I
think this should be mentioned somewhere in documentation, I suggest a separate
topic in Section Literals, List Literal
> List literal is not mentioned in docs
> -
>
> Key: JEXL-230
> URL: https://issues.apache.org/jira/browse/JEXL-230
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Trivial
> Labels: documentation, help-wanted
> Fix For: 3.1
>
>
> The syntax for [1,2,3,...] literal which creates List objects is not
> mentioned in documentation
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JEXL-228) Ability to read j.u.Collection elements other than instanceof j.u.List by using [] and . operator
Dmitri Blinov created JEXL-228:
--
Summary: Ability to read j.u.Collection elements other than
instanceof j.u.List by using [] and . operator
Key: JEXL-228
URL: https://issues.apache.org/jira/browse/JEXL-228
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Minor
In the current implementation of Jexl there is a possibility to address in a
script the specific elements of {{List}} and {{Array}} by using operators
{{[]}} or {{.}}, whereas its not that simple for descendants of {{Set}} or any
other {{Collection}} descendant, as there is no such an operator for them out
of the box. But in practice this is not so uncommon task for a script writer to
get, for example, the first element of the LinkedHashSet, which is supposed to
maintain the logical order of its elements, but unfortunately does not
implement {{List}} interface for us to be able to address its elements in that
order. I believe such a basic functionality - deserves to be available for
script witers from the start.
I have been experimenting with overloading access operators in customized
JexlArithmetic for a while and have managed to overload operators {{[]}} and
{{.}} so that they could be used not only for {{List}} interfaces but for other
{{Collection}} types as well:
{code}
protected Object nth(Collection c, int i) {
if (c instanceof List) {
List list = (List) c;
return list.get(i);
} else {
for (Object o : c) {
if (i-- == 0)
return o;
}
}
return null;
}
public Object propertyGet(Collection c, Number n) {
return nth(c, n.intValue());
}
public Object arrayGet(Collection c, Number n) {
return nth(c, n.intValue());
}
{code}
But I'm not satisfied with the fact that I have disabled alltogether the
initial Jexl implementation of access operators for {{LIst}} types.
The suggestion is to add the ability for Jexl scripts to read, not manipulate,
elements of any {{Collection}} type.
BTW, I have found that for {{List}} elements this solution is roughly 50%
faster compared with that of built-in Jexl List access implementation, so may
be there should be a place for a performance improvement in a way Jexl itself
accesses list elements.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JEXL-229) Introduce new syntax for class literals: Class and Type
Dmitri Blinov created JEXL-229: -- Summary: Introduce new syntax for class literals: Class and Type Key: JEXL-229 URL: https://issues.apache.org/jira/browse/JEXL-229 Project: Commons JEXL Issue Type: New Feature Affects Versions: 3.1 Reporter: Dmitri Blinov Priority: Minor For the purpose of type checking in jexl, It whould be convenient to have some simple syntax for referring to class types, like Class or Type. Literal Class should refer to general classes, and literal Type should refer to primitive type classes. For literals Class it could be possible to specify partal class name, which should resolve to classes in basic packages like java.lang and java.util, for example. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JEXL-230) List literal is not mentioned in docs
Dmitri Blinov created JEXL-230: -- Summary: List literal is not mentioned in docs Key: JEXL-230 URL: https://issues.apache.org/jira/browse/JEXL-230 Project: Commons JEXL Issue Type: Improvement Affects Versions: 3.1 Reporter: Dmitri Blinov Priority: Trivial The syntax for [1,2,3,...] literal which creates List objects is not mentioned in documentation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JEXL-231) Syntax for accessing List elements is not mentioned in docs
Dmitri Blinov created JEXL-231:
--
Summary: Syntax for accessing List elements is not mentioned in
docs
Key: JEXL-231
URL: https://issues.apache.org/jira/browse/JEXL-231
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Trivial
While it is explicitly specified in docs that Jexl allows to use {{[]}} and
{{.}} operators for accessing array elements, nothing is said that the same
syntax could be used for accessing List elements
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-230) List literal is not mentioned in docs
[ https://issues.apache.org/jira/browse/JEXL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062928#comment-16062928 ] Dmitri Blinov commented on JEXL-230: I thought the main source tree for jexl is maintained on the other site, it is only mirrored at github, isn't it? > List literal is not mentioned in docs > - > > Key: JEXL-230 > URL: https://issues.apache.org/jira/browse/JEXL-230 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Trivial > Labels: documentation, help-wanted > > The syntax for [1,2,3,...] literal which creates List objects is not > mentioned in documentation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-226) add ?? operator support
[
https://issues.apache.org/jira/browse/JEXL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16064497#comment-16064497
]
Dmitri Blinov commented on JEXL-226:
Just to mention that we have aliases for relational operators like {{eq}} for
{{==}} etc. And I personally would find it more convenient and easy to read to
use {{in}} instead of {{=~}} :-)
> add ?? operator support
>
>
> Key: JEXL-226
> URL: https://issues.apache.org/jira/browse/JEXL-226
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: Later
>Reporter: Min Wei
> Labels: features
> Fix For: Later
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Jexl already supports null-coalescing semantics with the operator "?:". So it
> should be a simple matter to extend it with a different syntax.
> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator
> https://github.com/apache/commons-jexl/pull/4
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JEXL-230) List literal is not mentioned in docs
[ https://issues.apache.org/jira/browse/JEXL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitri Blinov updated JEXL-230: --- Attachment: syntax.xml Please commit my changes to syntax.xml, thanks! > List literal is not mentioned in docs > - > > Key: JEXL-230 > URL: https://issues.apache.org/jira/browse/JEXL-230 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Assignee: Henri Biestro >Priority: Trivial > Labels: documentation, help-wanted > Fix For: 3.1 > > Attachments: syntax.xml > > > The syntax for [1,2,3,...] literal which creates List objects is not > mentioned in documentation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-229) Introduce new syntax for class literals: Class and Type
[
https://issues.apache.org/jira/browse/JEXL-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16064557#comment-16064557
]
Dmitri Blinov commented on JEXL-229:
The difference between a dedicated literal, like Class, and a functor
classp("String") in my view is as the difference between literal
{code}
1234.33B
{code}
and its functional equivalent
{code}
new ("java.math.BigDecimal", "1234.33")
{code}
the readability, compactness and parse-time checks, which is good for Q
The use case I'm after is to get away from now existing functors like
{{isMap()}}, {{isCollection()}} {{isSet()}} and to come to more generic type
checking. I have overloaded the {{=~}} operator to be used with right-hand
{{Class}} instances by calling either Class.isInstance() for objects or
Class.isAssignableFrom() for other Classes, for example
{code}
if (obj =~ klass)
{code}
so I think we can get along without introducing {{instanceof}} operator, but
for the types, as they are very basic Java elements for scripting, like
primitives, IMHO, it would be desirable to have a special language construct.
> Introduce new syntax for class literals: Class and Type
> -
>
> Key: JEXL-229
> URL: https://issues.apache.org/jira/browse/JEXL-229
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> For the purpose of type checking in jexl, It whould be convenient to have
> some simple syntax for referring to class types, like Class or
> Type. Literal Class should refer to general classes, and literal
> Type should refer to primitive type classes. For literals Class it
> could be possible to specify partal class name, which should resolve to
> classes in basic packages like java.lang and java.util, for example.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-226) add ?? operator support
[
https://issues.apache.org/jira/browse/JEXL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16066116#comment-16066116
]
Dmitri Blinov commented on JEXL-226:
I'm unable to use this operator in scripts. The following construct
{code}
x??true
{code}
throws org.apache.commons.jexl3.JexlException$Parsing: evalScript@1:3 parsing
error in '?'
> add ?? operator support
>
>
> Key: JEXL-226
> URL: https://issues.apache.org/jira/browse/JEXL-226
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: Later
>Reporter: Min Wei
>Assignee: Henri Biestro
> Labels: features
> Fix For: 3.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Jexl already supports null-coalescing semantics with the operator "?:". So it
> should be a simple matter to extend it with a different syntax.
> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator
> https://github.com/apache/commons-jexl/pull/4
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-226) add ?? operator support
[ https://issues.apache.org/jira/browse/JEXL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16066131#comment-16066131 ] Dmitri Blinov commented on JEXL-226: Sorry, false alarm, this is the artifact from old build :-( > add ?? operator support > > > Key: JEXL-226 > URL: https://issues.apache.org/jira/browse/JEXL-226 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: Later >Reporter: Min Wei >Assignee: Henri Biestro > Labels: features > Fix For: 3.2 > > Original Estimate: 1h > Remaining Estimate: 1h > > Jexl already supports null-coalescing semantics with the operator "?:". So it > should be a simple matter to extend it with a different syntax. > https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator > https://github.com/apache/commons-jexl/pull/4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-229) Introduce new syntax for class literals: Class and Type
[
https://issues.apache.org/jira/browse/JEXL-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16182695#comment-16182695
]
Dmitri Blinov commented on JEXL-229:
I have found another solution to this problem. I have adjusted the
{{JexlContext}} class to resolve ant-ish style context properties like for
example {{java.lang.Integer}} to the instances of corresponding
{{Class}} so it is now as easy to address {{Class}}
objects as to write
{code}if (obj =~ java.util.Map){code}
Furthermore, I have added a property resolver for {{Class}} objects to
return static class members, like for example {code}var one =
java.math.BigInteger.ONE{code} This also allowed me to access {{Class}}
objects for primitive types, since they are referenced via {{TYPE}} static
member of corresponding boxed type, like the following
{code}java.lang.Integer.TYPE{code} I think I have achieved what I was aiming
at, a clean solution without functors and need to use type names as strings. So
I think it is better now to close this issue.
> Introduce new syntax for class literals: Class and Type
> -
>
> Key: JEXL-229
> URL: https://issues.apache.org/jira/browse/JEXL-229
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> For the purpose of type checking in jexl, It whould be convenient to have
> some simple syntax for referring to class types, like Class or
> Type. Literal Class should refer to general classes, and literal
> Type should refer to primitive type classes. For literals Class it
> could be possible to specify partal class name, which should resolve to
> classes in basic packages like java.lang and java.util, for example.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (JEXL-229) Introduce new syntax for class literals: Class and Type
[ https://issues.apache.org/jira/browse/JEXL-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitri Blinov closed JEXL-229. -- Resolution: Workaround Fix Version/s: 3.1 > Introduce new syntax for class literals: Class and Type > - > > Key: JEXL-229 > URL: https://issues.apache.org/jira/browse/JEXL-229 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Minor > Fix For: 3.1 > > > For the purpose of type checking in jexl, It whould be convenient to have > some simple syntax for referring to class types, like Class or > Type. Literal Class should refer to general classes, and literal > Type should refer to primitive type classes. For literals Class it > could be possible to specify partal class name, which should resolve to > classes in basic packages like java.lang and java.util, for example. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JEXL-240) Unable to invoke a call operator using antish style variable resoltion
Dmitri Blinov created JEXL-240:
--
Summary: Unable to invoke a call operator using antish style
variable resoltion
Key: JEXL-240
URL: https://issues.apache.org/jira/browse/JEXL-240
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.1
Reporter: Dmitri Blinov
Suppose I have declared an antish style context variable under the name
{{java.math.BigDecimal}} of the {{Class}} type.
To test that it works correctly I use the following script
{code}var x = java.math.BigDecimal; x("1234"){code} which returns correct value.
Now I want to invoke an overloaded call operator directly for this variable
using {code}java.math.BigDecimal("1234"){code}
which returns an error
{panel}
undefined variable java.math
{panel}
The expected behaviour is to return the same value as in the first script.
I have created a test case for this, please have a look.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JEXL-240) Unable to invoke a call operator using antish style variable resoltion
[
https://issues.apache.org/jira/browse/JEXL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov updated JEXL-240:
---
Attachment: AntishCallTest.java
> Unable to invoke a call operator using antish style variable resoltion
> --
>
> Key: JEXL-240
> URL: https://issues.apache.org/jira/browse/JEXL-240
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
> Attachments: AntishCallTest.java
>
>
> Suppose I have declared an antish style context variable under the name
> {{java.math.BigDecimal}} of the {{Class}} type.
> To test that it works correctly I use the following script
> {code}var x = java.math.BigDecimal; x("1234"){code} which returns correct
> value.
> Now I want to invoke an overloaded call operator directly for this variable
> using {code}java.math.BigDecimal("1234"){code}
> which returns an error
> {panel}
> undefined variable java.math
> {panel}
> The expected behaviour is to return the same value as in the first script.
> I have created a test case for this, please have a look.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-244) Webapp classloader memory leaks
[
https://issues.apache.org/jira/browse/JEXL-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255010#comment-16255010
]
Dmitri Blinov commented on JEXL-244:
Although it's not easy to admit ones mistakes :-), but I have a sin of
premature reporing, sorry. I must aknowledge that you are right in your
suggestion and the leak seems to stem from another source. I haven't finished
with the research but I think we can close this issue, either rolling back
changes or keeping it as it is now. Thanks for your efforts BTW, I appreciate
your involvement!
> Webapp classloader memory leaks
> ---
>
> Key: JEXL-244
> URL: https://issues.apache.org/jira/browse/JEXL-244
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
> Environment: Inside J2EE container when Jexl library is included in
> the deployed .war file
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.2
>
>
> I have spotted that the following constructions, like for example in
> JexlEngine.java
> {code}
> public static final Object TRY_FAILED = new Object() {
> @Override
> public String toString() {
> return "tryExecute failed";
> }
> };
> {code}
> are not garbage collected when web-app is reloaded and its classloader is
> released. This is because circular references are created when static class
> members are initialized with non-static inner/anonymous classes, which are
> holding implicit references to its enclosing class and thus to its static
> class type. There are other such examples in JexlEngine.java like
> {code}
> protected static final java.lang.ThreadLocal
> CONTEXT = new java.lang.ThreadLocal() {..
> protected static final java.lang.ThreadLocal ENGINE =
> new java.lang.ThreadLocal() {...
> {code}
> The issue is easily resolved if for example the following pattern is followed
> {code}
> public static class FailObject extends Object {
> @Override
> public String toString() {
> return "tryExecute failed";
> }
> }
> public static final Object TRY_FAILED = new FailObject();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-243) Allow restricting available features in Script/Expressions
[ https://issues.apache.org/jira/browse/JEXL-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16274307#comment-16274307 ] Dmitri Blinov commented on JEXL-243: May be this is not the appropriate place to complain about git access, but for some reason I can not see your latest commit neither on github or via apache git repository at git://git.apache.org/commons-jexl.git, with two days have already passed... > Allow restricting available features in Script/Expressions > -- > > Key: JEXL-243 > URL: https://issues.apache.org/jira/browse/JEXL-243 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Henri Biestro >Assignee: Henri Biestro > Fix For: 3.2 > > > Restrict features related to potential dangers/difficulties one may encounter > whilst scripting; > Reserved Names: a set of reserved variable names that can not be used as > local variable (or parameter) names > Registers: boolean property allowing parsing of register syntax (#number) > Global Side Effect : boolean property controlling assigning/modifying values > on global variables > Side Effect: boolean property controlling side effects assigning/modifying > values on any variable > New Instance: boolean property controlling creating new instances through > new(...) or using class as functor > Loops: boolean property controlling usage of loop constructs (while(true), > for(...)) > Lambda: boolean property controlling usage of script function declarations > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-243) Allow restricting available features in Script/Expressions
[ https://issues.apache.org/jira/browse/JEXL-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226276#comment-16226276 ] Dmitri Blinov commented on JEXL-243: Well, this is basically works, the only thing is what if I have in one framework two different types of scripts, say scripts with side effects and scripts without side effects (or better to name them getters and setters). Those types of scripts are supposed to use a single Jexl engine instance. It would be more practical to be able to specify desired features right to JexlEngine.createScript() method. Maybe JexlEngine.createExpression() should get such an overload too, but maybe it's even better, not to speak of backward compatibility now, to have the only one JexlEngine.createScript() which could create both "scripts" and "expressions" by simply specifying "right" feature sets in each case. > Allow restricting available features in Script/Expressions > -- > > Key: JEXL-243 > URL: https://issues.apache.org/jira/browse/JEXL-243 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Henri Biestro >Assignee: Henri Biestro > Fix For: 3.2 > > > Restrict features related to potential dangers/difficulties one may encounter > whilst scripting; > Reserved Names: a set of reserved variable names that can not be used as > local variable (or parameter) names > Registers: boolean property allowing parsing of register syntax (#number) > Global Side Effect : boolean property controlling assigning/modifying values > on global variables > Side Effect: boolean property controlling side effects assigning/modifying > values on any variable > New Instance: boolean property controlling creating new instances through > new(...) or using class as functor > Loops: boolean property controlling usage of loop constructs (while(true), > for(...)) > Lambda: boolean property controlling usage of script function declarations > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (JEXL-243) Allow restricting available features in Script/Expressions
[ https://issues.apache.org/jira/browse/JEXL-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226276#comment-16226276 ] Dmitri Blinov edited comment on JEXL-243 at 10/31/17 5:56 AM: -- Well, this basically works, the only thing is what if I have in one framework two different types of scripts, say scripts with side effects and scripts without side effects (or better to name them getters and setters). Those types of scripts are supposed to use a single Jexl engine instance. It would be more practical to be able to specify desired features right to JexlEngine.createScript() method. Maybe JexlEngine.createExpression() should get such an overload too, but maybe it's even better, not to speak of backward compatibility now, to have the only one JexlEngine.createScript() which could create both "scripts" and "expressions" by simply specifying "right" feature sets in each case. was (Author: dmitri_blinov): Well, this is basically works, the only thing is what if I have in one framework two different types of scripts, say scripts with side effects and scripts without side effects (or better to name them getters and setters). Those types of scripts are supposed to use a single Jexl engine instance. It would be more practical to be able to specify desired features right to JexlEngine.createScript() method. Maybe JexlEngine.createExpression() should get such an overload too, but maybe it's even better, not to speak of backward compatibility now, to have the only one JexlEngine.createScript() which could create both "scripts" and "expressions" by simply specifying "right" feature sets in each case. > Allow restricting available features in Script/Expressions > -- > > Key: JEXL-243 > URL: https://issues.apache.org/jira/browse/JEXL-243 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Henri Biestro >Assignee: Henri Biestro > Fix For: 3.2 > > > Restrict features related to potential dangers/difficulties one may encounter > whilst scripting; > Reserved Names: a set of reserved variable names that can not be used as > local variable (or parameter) names > Registers: boolean property allowing parsing of register syntax (#number) > Global Side Effect : boolean property controlling assigning/modifying values > on global variables > Side Effect: boolean property controlling side effects assigning/modifying > values on any variable > New Instance: boolean property controlling creating new instances through > new(...) or using class as functor > Loops: boolean property controlling usage of loop constructs (while(true), > for(...)) > Lambda: boolean property controlling usage of script function declarations > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JEXL-244) Webapp classloader memory leaks
Dmitri Blinov created JEXL-244:
--
Summary: Webapp classloader memory leaks
Key: JEXL-244
URL: https://issues.apache.org/jira/browse/JEXL-244
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.1
Environment: Inside J2EE container when Jexl library is included in
the deployed .war file
Reporter: Dmitri Blinov
I have spotted that the following constructions, like for example in
JexlEngine.java
{code}
public static final Object TRY_FAILED = new Object() {
@Override
public String toString() {
return "tryExecute failed";
}
};
{code}
are not garbage collected when web-app is reloaded and its classloader is
released. This is because circular references are created when static class
members are initialized with non-static inner/anonymous classes, which are
holding implicit references to its enclosing class and thus to its static class
type. There are other such examples in JexlEngine.java like
{code}
protected static final java.lang.ThreadLocal
CONTEXT = new java.lang.ThreadLocal() {..
protected static final java.lang.ThreadLocal ENGINE =
new java.lang.ThreadLocal() {...
{code}
The issue is easily resolved if for example the following pattern is followed
{code}
public static class FailObject extends Object {
@Override
public String toString() {
return "tryExecute failed";
}
}
public static final Object TRY_FAILED = new FailObject();
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JEXL-262) Inline object property initialization construct
Dmitri Blinov created JEXL-262:
--
Summary: Inline object property initialization construct
Key: JEXL-262
URL: https://issues.apache.org/jira/browse/JEXL-262
Project: Commons JEXL
Issue Type: New Feature
Affects Versions: 3.1
Reporter: Dmitri Blinov
I wonder is it possible (not difficult) to implement in Jexl a construct that
would allow us to initialize object properties in one statement, so that it
would be possible to replace the code like
{code}
var i = Address
i.City = 'NY';
i.Street = '1st Avenue';
i.House = '22';
{code}
with something like
{code}
Address {City : 'NY', Street : '1st Avenue', House : '22'}
{code}
I think this is somewhat similar to inline map initialization syntax, which is
proved to be very useful and productive, so it would be nice to have such a
feature for common objects too
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JEXL-262) Inline object property initialization construct
[
https://issues.apache.org/jira/browse/JEXL-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov updated JEXL-262:
---
Description:
I wonder is it possible (not difficult) to implement in Jexl a construct that
would allow us to initialize object properties in one statement, so that it
would be possible to replace the code like
{code}
var i = Address;
i.City = 'NY';
i.Street = '1st Avenue';
i.House = '22';
return i;
{code}
with something like
{code}
Address {City : 'NY', Street : '1st Avenue', House : '22'}
{code}
May be we could also consider a variant for array-style accessors, like
{code}
var i = Address;
i["City"] = 'NY';
i["Street"] = '1st Avenue';
i["House"] = '22';
return i
{code}
would be identical to
{code}
Address {"City" : 'NY', "Street" : '1st Avenue', "House" : '22'}
{code}
I think this is somewhat similar to inline map initialization syntax, which is
proved to be very useful and productive, so it would be nice to have such a
feature for common objects too
was:
I wonder is it possible (not difficult) to implement in Jexl a construct that
would allow us to initialize object properties in one statement, so that it
would be possible to replace the code like
{code}
var i = Address
i.City = 'NY';
i.Street = '1st Avenue';
i.House = '22';
{code}
with something like
{code}
Address {City : 'NY', Street : '1st Avenue', House : '22'}
{code}
I think this is somewhat similar to inline map initialization syntax, which is
proved to be very useful and productive, so it would be nice to have such a
feature for common objects too
> Inline object property initialization construct
> ---
>
> Key: JEXL-262
> URL: https://issues.apache.org/jira/browse/JEXL-262
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> I wonder is it possible (not difficult) to implement in Jexl a construct that
> would allow us to initialize object properties in one statement, so that it
> would be possible to replace the code like
> {code}
> var i = Address;
> i.City = 'NY';
> i.Street = '1st Avenue';
> i.House = '22';
> return i;
> {code}
> with something like
> {code}
> Address {City : 'NY', Street : '1st Avenue', House : '22'}
> {code}
> May be we could also consider a variant for array-style accessors, like
> {code}
> var i = Address;
> i["City"] = 'NY';
> i["Street"] = '1st Avenue';
> i["House"] = '22';
> return i
> {code}
> would be identical to
> {code}
> Address {"City" : 'NY', "Street" : '1st Avenue', "House" : '22'}
> {code}
> I think this is somewhat similar to inline map initialization syntax, which
> is proved to be very useful and productive, so it would be nice to have such
> a feature for common objects too
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (JEXL-259) Shorter ant-ish variables prevent longer ant-ish variables from being resolved properly
[
https://issues.apache.org/jira/browse/JEXL-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-259.
--
Resolution: Workaround
Fix Version/s: 3.1
I have worked this out for my case, and I think we can close this issue, as
further improvements to ant-ish variables, if any, could be made under separate
task. For now, may be its worth mentioning somewhere in documentation that such
variables have its limitations in naming
> Shorter ant-ish variables prevent longer ant-ish variables from being
> resolved properly
> ---
>
> Key: JEXL-259
> URL: https://issues.apache.org/jira/browse/JEXL-259
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
> Fix For: 3.1
>
>
> The following script is evaluated successfully
> {code}
> a.b.c = 2; a.b = 1; return a.b
> {code}
> While the following scripts are terminated with error {{unsolvable property
> 'c'}}
> {code}
> a.b = 1; a.b.c = 2; return a.b
> {code}
> {code}
> a.b.c = 2; a.b = 1; return a.b.c
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JEXL-259) Shorter ant-ish variables prevent longer ant-ish variables from being resolved properly
[
https://issues.apache.org/jira/browse/JEXL-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458364#comment-16458364
]
Dmitri Blinov commented on JEXL-259:
I understand the difficulty of the resolving dotted names that can clash with
properties of the objects themselves, since as I think, Jexl is an interpreted
scripting language, and should process access operators one by one, without
peeping over what would come next in chain. But something needs to be done with
that, because to my mind, clashing of the multi-levelled names is natural for
people to put their thoughts in order, I think there are many examples like
system property names {{java.vendor}} and {{java.vendor.url}} to name a few. If
you see a reliable way to improve the ant-ish variable detection, my opinion is
that definitely needs to be done, and I'm ready to jump in and test whatever I
can. Without that I would be left with the only choice of abandoning ant-ish
variables altogether in favour of something like a recursive cascading
resolver, which is like an old dirty hack
> Shorter ant-ish variables prevent longer ant-ish variables from being
> resolved properly
> ---
>
> Key: JEXL-259
> URL: https://issues.apache.org/jira/browse/JEXL-259
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
>
> The following script is evaluated successfully
> {code}
> a.b.c = 2; a.b = 1; return a.b
> {code}
> While the following scripts are terminated with error {{unsolvable property
> 'c'}}
> {code}
> a.b = 1; a.b.c = 2; return a.b
> {code}
> {code}
> a.b.c = 2; a.b = 1; return a.b.c
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JEXL-242) invalid jexl calculation while doing sum for particular value
[
https://issues.apache.org/jira/browse/JEXL-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16221996#comment-16221996
]
Dmitri Blinov commented on JEXL-242:
I believe this is how floating point arithmetic works. Numbers in float or
double format are basically not exact numbers but a close approximations. It
has nothing to do with jexl
> invalid jexl calculation while doing sum for particular value
> -
>
> Key: JEXL-242
> URL: https://issues.apache.org/jira/browse/JEXL-242
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: vikas garg
>Priority: Blocker
>
> For a particular value of 0.05 , jexl is returning value unxepectedly
> I have face an issue with following calcualtion:
> Double a = -40.05;
> Double b = -8.01;
> final JexlContext context = new MapContext();
> context.set("a",a);
> context.set("b",b);
> JexlEngine JEXL_ENGINE = new JexlBuilder().strict(true).silent(true).create();
> JexlExpression jsp = JEXL_ENGINE.createExpression("a+b");
> Double c = jsp.evaluate(context);
> The value returned by evaluation is -48.055 instead of -48.06
> There seems some precision issue in calculation
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-242) invalid jexl calculation while doing sum for particular value
[
https://issues.apache.org/jira/browse/JEXL-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222024#comment-16222024
]
Dmitri Blinov commented on JEXL-242:
You can check if jexl works correctly by evaluating your arithmetic in plain
java.
Double a = -40.05; Double b = -8.01; Double c = a + b
> invalid jexl calculation while doing sum for particular value
> -
>
> Key: JEXL-242
> URL: https://issues.apache.org/jira/browse/JEXL-242
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: vikas garg
>Priority: Blocker
>
> For a particular value of 0.05 , jexl is returning value unxepectedly
> I have face an issue with following calcualtion:
> Double a = -40.05;
> Double b = -8.01;
> final JexlContext context = new MapContext();
> context.set("a",a);
> context.set("b",b);
> JexlEngine JEXL_ENGINE = new JexlBuilder().strict(true).silent(true).create();
> JexlExpression jsp = JEXL_ENGINE.createExpression("a+b");
> Double c = jsp.evaluate(context);
> The value returned by evaluation is -48.055 instead of -48.06
> There seems some precision issue in calculation
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-242) invalid jexl calculation while doing sum for particular value
[
https://issues.apache.org/jira/browse/JEXL-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222139#comment-16222139
]
Dmitri Blinov commented on JEXL-242:
I have no idea how you checked this. Try checking with the following code
{code}
double a = -40.05;
double b = -8.01;
final JexlContext context = new MapContext();
context.set("a",a);
context.set("b",b);
JexlEngine JEXL_ENGINE = new JexlBuilder().strict(true).silent(true).create();
JexlExpression jsp = JEXL_ENGINE.createExpression("a+b");
double c = (Double) jsp.evaluate(context);
if (c != a + b) {
// Add your code to report a problem
}
{code}
> invalid jexl calculation while doing sum for particular value
> -
>
> Key: JEXL-242
> URL: https://issues.apache.org/jira/browse/JEXL-242
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: vikas garg
>Priority: Blocker
>
> For a particular value of 0.05 , jexl is returning value unxepectedly
> I have face an issue with following calcualtion:
> Double a = -40.05;
> Double b = -8.01;
> final JexlContext context = new MapContext();
> context.set("a",a);
> context.set("b",b);
> JexlEngine JEXL_ENGINE = new JexlBuilder().strict(true).silent(true).create();
> JexlExpression jsp = JEXL_ENGINE.createExpression("a+b");
> Double c = jsp.evaluate(context);
> The value returned by evaluation is -48.055 instead of -48.06
> There seems some precision issue in calculation
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JEXL-246) Intermittent ambiguous method invocation when processing assignOverload
Dmitri Blinov created JEXL-246:
--
Summary: Intermittent ambiguous method invocation when processing
assignOverload
Key: JEXL-246
URL: https://issues.apache.org/jira/browse/JEXL-246
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Minor
Sometimes the simple operator like {code}z += 1{code} when {{z}} has not been
defined yet raises an exception
{{org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException}}
with the following stack trace:
{quote}
ambiguous method invocation: MyArithmetic.selfAdd(null, java.lang.Integer)
org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException:
null
at
org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.getMostSpecific(MethodKey.java:540)
at
org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(MethodKey.java:452)
at
org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(MethodKey.java:261)
at
org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(ClassMap.java:178)
at
org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(Introspector.java:146)
at
org.apache.commons.jexl3.internal.introspection.MethodExecutor.discover(MethodExecutor.java:52)
at
org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(Uberspect.java:218)
at MyUberspect.getMethod(MyUberspect.java:168)
at
org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(Uberspect.java:413)
at
org.apache.commons.jexl3.internal.Operators.tryOverload(Operators.java:85)
at
org.apache.commons.jexl3.internal.Operators.tryAssignOverload(Operators.java:118)
at
org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1292)
at
org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1102)
{quote}
The class MyArithmetic contains a couple of overloaded
{{public JexlOperator selfAdd(T x, Object y)}} methods with the first argument
being the desired type {{T}} like {{Appendable}} or {{Collection}} for which
the {{+=}} operator is overloaded.
Obviously in case where the first argument is null and the second argument is
an Integer it is not possible to differentiate between {{public JexlOperator
selfAdd(Collection x, Object y)}} and {{public JexlOperator selfAdd(Appendable
x, Object y)}} but I wonder is there any point in trying to perform {{selfAdd}}
on the null variable? What questions me more is that this error is intermittent
and sometimes there is an exception and sometimes there is not, so at the
moment I have no test case to reproduce. So I think this is a bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-246) Intermittent ambiguous method invocation when processing assignOverload
[
https://issues.apache.org/jira/browse/JEXL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16318098#comment-16318098
]
Dmitri Blinov commented on JEXL-246:
Well, while I can not say JEXL does not do its job here, I hate the idea of
having even once an exception logged for a such simple situation. Obviously we
have a contradiction with overloading. For a JEXL extension writer it would be
not uncommon to try to overload an operator more than once using different
signatures for different types. But that would surely lead to ambiguity with
*null* arguments. The solution I see right now on the developer side is to
replace all overloaded methods with the only most broad definition like
{{public JexlOperator selfAdd(Object x, Object y)}}, and do class checking
inside that method, forwarding further calls to the specific methods from
there, and blocking *null* arguements. But that kills the idea of using JEXL
feature for resolving most specific methods, possibly conflicting with default
JEXL implementation for other types, not speaking of creating messy code.
Otherwise, if we try to fix it on JEXL side, in case where the first argument
is *null*, we should try to resolve this only to the overloaded methods whose
first argument is *Object*, like {{public JexlOperator selfAdd(Object x, T y)}}
of even unary {{public JexlOperator selfAdd(T y)}}
Null arguments are not suited for type checking, and even if we have had the
only one overloaded method in Arithmetic class, for example {{public
JexlOperator selfAdd(Collection x, Object y)}}, it would be pointless to try to
do anything with *null* collection, except for returning JexlEngine.TRY_FAILED
> Intermittent ambiguous method invocation when processing assignOverload
> ---
>
> Key: JEXL-246
> URL: https://issues.apache.org/jira/browse/JEXL-246
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> Sometimes the simple operator like {code}z += 1{code} when {{z}} has not been
> defined yet raises an exception
> {{org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException}}
> with the following stack trace:
> {quote}
> ambiguous method invocation: MyArithmetic.selfAdd(null, java.lang.Integer)
> org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException:
> null
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.getMostSpecific(MethodKey.java:540)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(MethodKey.java:452)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(MethodKey.java:261)
> at
> org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(ClassMap.java:178)
>
> at
> org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(Introspector.java:146)
> at
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.discover(MethodExecutor.java:52)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(Uberspect.java:218)
>
> at MyUberspect.getMethod(MyUberspect.java:168)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(Uberspect.java:413)
> at
> org.apache.commons.jexl3.internal.Operators.tryOverload(Operators.java:85)
> at
> org.apache.commons.jexl3.internal.Operators.tryAssignOverload(Operators.java:118)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1292)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1102)
>
> {quote}
> The class MyArithmetic contains a couple of overloaded
> {{public JexlOperator selfAdd(T x, Object y)}} methods with the first
> argument being the desired type {{T}} like {{Appendable}} or {{Collection}}
> for which the {{+=}} operator is overloaded.
> Obviously in case where the first argument is null and the second argument is
> an Integer it is not possible to differentiate between {{public JexlOperator
> selfAdd(Collection x, Object y)}} and {{public JexlOperator
> selfAdd(Appendable x, Object y)}} but I wonder is there any point in trying
> to perform {{selfAdd}} on the null variable? What questions me more is that
> this error is intermittent and sometimes there is an exception and sometimes
> there is not, so at the moment I have no test case to reproduce. So I think
> this is a bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-246) Intermittent ambiguous method invocation when processing assignOverload
[
https://issues.apache.org/jira/browse/JEXL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334042#comment-16334042
]
Dmitri Blinov commented on JEXL-246:
The following messages have started to appear in the log
{quote}Method public java.lang.Object
MyArithmetic.add(java.lang.Object,java.lang.Object) is already registered, key:
addjava.lang.Objectjava.lang.Object
{quote}
for the overridden methods in MyArithmetic
{code:java}
@Override
public Object add(Object left, Object right) {
{code}
This is expected the behaviour to have the basic JexlArithmetic class methods
overridden, right? So why this message?
> Intermittent ambiguous method invocation when processing assignOverload
> ---
>
> Key: JEXL-246
> URL: https://issues.apache.org/jira/browse/JEXL-246
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> Sometimes the simple operator like {code}z += 1{code} when {{z}} has not been
> defined yet raises an exception
> {{org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException}}
> with the following stack trace:
> {quote}
> ambiguous method invocation: MyArithmetic.selfAdd(null, java.lang.Integer)
> org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException:
> null
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.getMostSpecific(MethodKey.java:540)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(MethodKey.java:452)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(MethodKey.java:261)
> at
> org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(ClassMap.java:178)
>
> at
> org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(Introspector.java:146)
> at
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.discover(MethodExecutor.java:52)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(Uberspect.java:218)
>
> at MyUberspect.getMethod(MyUberspect.java:168)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(Uberspect.java:413)
> at
> org.apache.commons.jexl3.internal.Operators.tryOverload(Operators.java:85)
> at
> org.apache.commons.jexl3.internal.Operators.tryAssignOverload(Operators.java:118)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1292)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1102)
>
> {quote}
> The class MyArithmetic contains a couple of overloaded
> {{public JexlOperator selfAdd(T x, Object y)}} methods with the first
> argument being the desired type {{T}} like {{Appendable}} or {{Collection}}
> for which the {{+=}} operator is overloaded.
> Obviously in case where the first argument is null and the second argument is
> an Integer it is not possible to differentiate between {{public JexlOperator
> selfAdd(Collection x, Object y)}} and {{public JexlOperator
> selfAdd(Appendable x, Object y)}} but I wonder is there any point in trying
> to perform {{selfAdd}} on the null variable? What questions me more is that
> this error is intermittent and sometimes there is an exception and sometimes
> there is not, so at the moment I have no test case to reproduce. So I think
> this is a bug.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JEXL-252) Allow for interpolated strings to be used in property access operators
Dmitri Blinov created JEXL-252:
--
Summary: Allow for interpolated strings to be used in property
access operators
Key: JEXL-252
URL: https://issues.apache.org/jira/browse/JEXL-252
Project: Commons JEXL
Issue Type: New Feature
Affects Versions: 3.1
Reporter: Dmitri Blinov
Now we have a possibility to access an object property by specifying either
{code}object.property{code} or {code}object."property"{code} expression, but
not {code}object.`property`{code} expression. Since interpolated strings can be
used anywhere in scripts as ordinal strings, it would be logical to allow them
to be used in property access operators too. It would allow to have the
property name not necessarily to be a constant, but to be evaluated without
using the array access operator, since property access operator and array
access operator could be implemented (overloaded) differently for the object.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JEXL-251) Safe navigation operator
Dmitri Blinov created JEXL-251:
--
Summary: Safe navigation operator
Key: JEXL-251
URL: https://issues.apache.org/jira/browse/JEXL-251
Project: Commons JEXL
Issue Type: New Feature
Affects Versions: 3.1
Reporter: Dmitri Blinov
It would be more convenient for a script writer to have a kind of safe
navigation operator, in the form of, for example, ({{object?.property),}} for
null pointer dereferences. I think its quite a common feature of many scripting
(and compiled languages) now. The safe operator should work like basic
navigation operator for non null values and should short-circuit the entire
expression evaluation after encountering null value.
I see the difference of new operator from the existing lenient mode evaluation
in ability to explicitly define places in an expression where {{null}}
deference is allowed, for example the expression
{code}Order.Customer?.Name{code} defines that each {{Order}} should have a
{{Customer}} and only the {{Name}} of the {{Customer}} is optional.
The difference of new operator from the existing null coalescing {{??}}
operator is in its ability to short-circuit evaluation.
So, safe navigation operator would be a helpful syntaxic sugar which in my
opinion does not overlap with an existing functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JEXL-250) Safe navigation operator
Dmitri Blinov created JEXL-250:
--
Summary: Safe navigation operator
Key: JEXL-250
URL: https://issues.apache.org/jira/browse/JEXL-250
Project: Commons JEXL
Issue Type: New Feature
Affects Versions: 3.1
Reporter: Dmitri Blinov
It would be more convenient for a script writer to have a kind of safe
navigation operator, in the form of, for example, ({{object?.property),}} for
null pointer dereferences. I think its quite a common feature of many scripting
(and compiled languages) now. The safe operator should work like basic
navigation operator for non null values and should short-circuit the entire
expression evaluation after encountering null value.
I see the difference of new operator from the existing lenient mode evaluation
in ability to explicitly define places in an expression where {{null}}
deference is allowed, for example the expression
{code}Order.Customer?.Name{code} defines that each {{Order}} should have a
{{Customer}} and only the {{Name}} of the {{Customer}} is optional.
The difference of new operator from the existing null coalescing {{??}}
operator is in its ability to short-circuit evaluation.
So, safe navigation operator would be a helpful syntaxic sugar which in my
opinion does not overlap with an existing functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (JEXL-251) Safe navigation operator
[
https://issues.apache.org/jira/browse/JEXL-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-251.
--
Resolution: Duplicate
Seems to be Jira double processing bug
> Safe navigation operator
>
>
> Key: JEXL-251
> URL: https://issues.apache.org/jira/browse/JEXL-251
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> It would be more convenient for a script writer to have a kind of safe
> navigation operator, in the form of, for example, ({{object?.property),}} for
> null pointer dereferences. I think its quite a common feature of many
> scripting (and compiled languages) now. The safe operator should work like
> basic navigation operator for non null values and should short-circuit the
> entire expression evaluation after encountering null value.
> I see the difference of new operator from the existing lenient mode
> evaluation in ability to explicitly define places in an expression where
> {{null}} deference is allowed, for example the expression
> {code}Order.Customer?.Name{code} defines that each {{Order}} should have a
> {{Customer}} and only the {{Name}} of the {{Customer}} is optional.
> The difference of new operator from the existing null coalescing {{??}}
> operator is in its ability to short-circuit evaluation.
> So, safe navigation operator would be a helpful syntaxic sugar which in my
> opinion does not overlap with an existing functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JEXL-246) Intermittent ambiguous method invocation when processing assignOverload
[
https://issues.apache.org/jira/browse/JEXL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324122#comment-16324122
]
Dmitri Blinov edited comment on JEXL-246 at 1/12/18 3:40 PM:
-
As it has turned out for me, Jexl restricts me, for some reason, from
overloading operators in Arithmetic, if the operator signature is of
generalized form, like {{operator(Object)}} or {{operator(Object, Object)}}. So
the idea of having {{public JexlOperator selfAdd(Object x, Object y)}} does not
apply. I don't know if it worth raising an issue about that, or it's better to
find the more appropriate solution to the original problem. Lets not
over-complicate. Suppose, we have an original script for {{z += 1}} and
standard Arithmetic without any {{selfAdd}} overloaded operators. Should this
work for an empty z value? I think it should. So, it should work exactly the
same as with any number of {{selfAdd}} overloaded operators too. It's not an
ambiguity, it's like Jexl couldn't find an appropriate overloaded operator for
this case, and reverted to the default implementation.
was (Author: dmitri_blinov):
As it has turned out for me, Jexl restricts me, for some reason, from
overloading operators in Arithmetic, if the operator signature is of
generalized form, like {{operator(Object)}} or {{operator(Object, Object)}}. So
the idea of having {{public JexlOperator selfAdd(Object x, Object y)}} does not
apply. I don't know if it worth raising an issue about that, or it's better to
find more appropriate the solution to the original problem. Lets not
over-complicate. Suppose, we have an original script for {{z += 1}} and
standard Arithmetic without any {{selfAdd}} overloaded operators. Should this
work for an empty z value? I think it should. So, it should work exactly the
same as with any number of {{selfAdd}} overloaded operators too. It's not an
ambiguity, it's like Jexl couldn't find an appropriate overloaded operator for
this case, and reverted to the default implementation.
> Intermittent ambiguous method invocation when processing assignOverload
> ---
>
> Key: JEXL-246
> URL: https://issues.apache.org/jira/browse/JEXL-246
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> Sometimes the simple operator like {code}z += 1{code} when {{z}} has not been
> defined yet raises an exception
> {{org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException}}
> with the following stack trace:
> {quote}
> ambiguous method invocation: MyArithmetic.selfAdd(null, java.lang.Integer)
> org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException:
> null
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.getMostSpecific(MethodKey.java:540)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(MethodKey.java:452)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(MethodKey.java:261)
> at
> org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(ClassMap.java:178)
>
> at
> org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(Introspector.java:146)
> at
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.discover(MethodExecutor.java:52)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(Uberspect.java:218)
>
> at MyUberspect.getMethod(MyUberspect.java:168)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(Uberspect.java:413)
> at
> org.apache.commons.jexl3.internal.Operators.tryOverload(Operators.java:85)
> at
> org.apache.commons.jexl3.internal.Operators.tryAssignOverload(Operators.java:118)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1292)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1102)
>
> {quote}
> The class MyArithmetic contains a couple of overloaded
> {{public JexlOperator selfAdd(T x, Object y)}} methods with the first
> argument being the desired type {{T}} like {{Appendable}} or {{Collection}}
> for which the {{+=}} operator is overloaded.
> Obviously in case where the first argument is null and the second argument is
> an Integer it is not possible to differentiate between {{public JexlOperator
> selfAdd(Collection x, Object y)}} and {{public JexlOperator
> selfAdd(Appendable x, Object y)}} but I wonder is there any point in trying
> to perform {{selfAdd}} on the null variable? What questions me more is that
> this error is
[jira] [Commented] (JEXL-246) Intermittent ambiguous method invocation when processing assignOverload
[
https://issues.apache.org/jira/browse/JEXL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324122#comment-16324122
]
Dmitri Blinov commented on JEXL-246:
As it has turned out for me, Jexl restricts me, for some reason, from
overloading operators in Arithmetic, if the operator signature is of
generalized form, like {{operator(Object)}} or {{operator(Object, Object)}}. So
the idea of having {{public JexlOperator selfAdd(Object x, Object y)}} does not
apply. I don't know if it worth raising an issue about that, or it's better to
find more appropriate the solution to the original problem. Lets not
over-complicate. Suppose, we have an original script for {{z += 1}} and
standard Arithmetic without any {{selfAdd}} overloaded operators. Should this
work for an empty z value? I think it should. So, it should work exactly the
same as with any number of {{selfAdd}} overloaded operators too. It's not an
ambiguity, it's like Jexl couldn't find an appropriate overloaded operator for
this case, and reverted to the default implementation.
> Intermittent ambiguous method invocation when processing assignOverload
> ---
>
> Key: JEXL-246
> URL: https://issues.apache.org/jira/browse/JEXL-246
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> Sometimes the simple operator like {code}z += 1{code} when {{z}} has not been
> defined yet raises an exception
> {{org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException}}
> with the following stack trace:
> {quote}
> ambiguous method invocation: MyArithmetic.selfAdd(null, java.lang.Integer)
> org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException:
> null
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.getMostSpecific(MethodKey.java:540)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(MethodKey.java:452)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(MethodKey.java:261)
> at
> org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(ClassMap.java:178)
>
> at
> org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(Introspector.java:146)
> at
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.discover(MethodExecutor.java:52)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(Uberspect.java:218)
>
> at MyUberspect.getMethod(MyUberspect.java:168)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(Uberspect.java:413)
> at
> org.apache.commons.jexl3.internal.Operators.tryOverload(Operators.java:85)
> at
> org.apache.commons.jexl3.internal.Operators.tryAssignOverload(Operators.java:118)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1292)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1102)
>
> {quote}
> The class MyArithmetic contains a couple of overloaded
> {{public JexlOperator selfAdd(T x, Object y)}} methods with the first
> argument being the desired type {{T}} like {{Appendable}} or {{Collection}}
> for which the {{+=}} operator is overloaded.
> Obviously in case where the first argument is null and the second argument is
> an Integer it is not possible to differentiate between {{public JexlOperator
> selfAdd(Collection x, Object y)}} and {{public JexlOperator
> selfAdd(Appendable x, Object y)}} but I wonder is there any point in trying
> to perform {{selfAdd}} on the null variable? What questions me more is that
> this error is intermittent and sometimes there is an exception and sometimes
> there is not, so at the moment I have no test case to reproduce. So I think
> this is a bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (JEXL-247) Possible value loss in case of coersion of BigInteger to BigDecimal
[
https://issues.apache.org/jira/browse/JEXL-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-247.
--
Resolution: Not A Problem
Sorry, the code transforms BigInteger using toString(), so the problem should
not happen.
> Possible value loss in case of coersion of BigInteger to BigDecimal
> ---
>
> Key: JEXL-247
> URL: https://issues.apache.org/jira/browse/JEXL-247
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>
> It seems that {{JexlArithmetic.toBigDecimal}} method does not have a special
> treatment for {{BigInteger}} type, only for {{Number}}, which can lead to
> value loss in arithmetic operations for values greater than
> {{Long.MAX_VALUE}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JEXL-247) Possible value loss in case of coersion of BigInteger to BigDecimal
Dmitri Blinov created JEXL-247:
--
Summary: Possible value loss in case of coersion of BigInteger to
BigDecimal
Key: JEXL-247
URL: https://issues.apache.org/jira/browse/JEXL-247
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.1
Reporter: Dmitri Blinov
It seems that {{JexlArithmetic.toBigDecimal}} method does not have a special
treatment for {{BigInteger}} type, only for {{Number}}, which can lead to value
loss in arithmetic operations for values greater than {{Long.MAX_VALUE}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-252) Allow for interpolated strings to be used in property access operators
[
https://issues.apache.org/jira/browse/JEXL-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342507#comment-16342507
]
Dmitri Blinov commented on JEXL-252:
The {{object.`property`}} syntax alone, without interpolation, allow for more
special characters to be used. To me the idea of a property name being a
constant, seems not so important as the ability to use operators {{.}} and
{{[]}} differently semantically. For example I want to reserve operator {{[]}}
for accessing object by numbered indexes, like 1 or 1..3, lets call it array
semantics, and reserve operator {{.}} for accessing object properties, lets
call it property semantics. For a property semantics to have more flexibility
it would be great to have ability to specify not only constants, but to use
variables as well
> Allow for interpolated strings to be used in property access operators
> --
>
> Key: JEXL-252
> URL: https://issues.apache.org/jira/browse/JEXL-252
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> Now we have a possibility to access an object property by specifying either
> {code}object.property{code} or {code}object."property"{code} expression, but
> not {code}object.`property`{code} expression. Since interpolated strings can
> be used anywhere in scripts as ordinal strings, it would be logical to allow
> them to be used in property access operators too. It would allow to have the
> property name not necessarily to be a constant, but to be evaluated without
> using the array access operator, since property access operator and array
> access operator could be implemented (overloaded) differently for the object.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JEXL-250) Safe navigation operator
[
https://issues.apache.org/jira/browse/JEXL-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16342494#comment-16342494
]
Dmitri Blinov commented on JEXL-250:
To me the idea of safe navigation is chaining of navigation operators, where
one could write the one-line expression like
{{Order?.Customer?.Address?.ZipCode}}, instead of cumbersome {code}var Customer
= Order.Customer; if (Customer != null) {var Address = Customer.Address; ...}
{code}The one-line expression should nevertheless be correctly evaluated even
if some part of expression is missing. Neither null coalescing operator, nor
elvis operator help me with this, but may be I just haven't figured out how to
use them for this purpose. Furhermore, null coalescing operator seems not to
work with undefined properties, only undefines variables, the following example
{code}x = "qwerty"; (x.class1) ?? 'No such property'{code} raises {{Unsolvable
property 'class1'}}
> Safe navigation operator
>
>
> Key: JEXL-250
> URL: https://issues.apache.org/jira/browse/JEXL-250
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> It would be more convenient for a script writer to have a kind of safe
> navigation operator, in the form of, for example, ({{object?.property),}} for
> null pointer dereferences. I think its quite a common feature of many
> scripting (and compiled languages) now. The safe operator should work like
> basic navigation operator for non null values and should short-circuit the
> entire expression evaluation after encountering null value.
> I see the difference of new operator from the existing lenient mode
> evaluation in ability to explicitly define places in an expression where
> {{null}} deference is allowed, for example the expression
> {code}Order.Customer?.Name{code} defines that each {{Order}} should have a
> {{Customer}} and only the {{Name}} of the {{Customer}} is optional.
> The difference of new operator from the existing null coalescing {{??}}
> operator is in its ability to short-circuit evaluation.
> So, safe navigation operator would be a helpful syntaxic sugar which in my
> opinion does not overlap with an existing functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JEXL-254) Tests from IssuesTest100.java and IssuesTest200.java don't fire
Dmitri Blinov created JEXL-254: -- Summary: Tests from IssuesTest100.java and IssuesTest200.java don't fire Key: JEXL-254 URL: https://issues.apache.org/jira/browse/JEXL-254 Project: Commons JEXL Issue Type: Test Affects Versions: 3.1 Reporter: Dmitri Blinov It seems that Jexl build process does not honor tests with class names not ending with 'Test'. As an experiment I was trying to add another check to the issue and it was ignored until I renamed IssuesTest100.java to Issues100Test.java and IssuesTest200.java to Issues200Test.java. Luckiliy all the tests were passed from those files after name change :) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JEXL-250) Safe navigation operator
[
https://issues.apache.org/jira/browse/JEXL-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353749#comment-16353749
]
Dmitri Blinov commented on JEXL-250:
The following test does not pass for me
{code}
@Test
public void test250() throws Exception {
MapContext ctx = new MapContext();
HashMap x = new HashMap ();
x.put(2, "123456789");
ctx.set("x", x);
JexlEngine engine = new
JexlBuilder().strict(true).silent(false).create();
String stmt = "x.2.class.name";
JexlScript script = engine.createScript(stmt);
Object result = script.execute(ctx);
Assert.assertEquals("java.lang.String", result);
try {
stmt = "x?.3.class.name";
script = engine.createScript(stmt);
result = script.execute(ctx);
Assert.assertNull(result);
} catch(JexlException xany) {
Assert.fail("Should have evaluated to null");
}
}
{code}
The test breaks with {{Should have evaluated to null}}
> Safe navigation operator
>
>
> Key: JEXL-250
> URL: https://issues.apache.org/jira/browse/JEXL-250
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> It would be more convenient for a script writer to have a kind of safe
> navigation operator, in the form of, for example, ({{object?.property),}} for
> null pointer dereferences. I think its quite a common feature of many
> scripting (and compiled languages) now. The safe operator should work like
> basic navigation operator for non null values and should short-circuit the
> entire expression evaluation after encountering null value.
> I see the difference of new operator from the existing lenient mode
> evaluation in ability to explicitly define places in an expression where
> {{null}} deference is allowed, for example the expression
> {code}Order.Customer?.Name{code} defines that each {{Order}} should have a
> {{Customer}} and only the {{Name}} of the {{Customer}} is optional.
> The difference of new operator from the existing null coalescing {{??}}
> operator is in its ability to short-circuit evaluation.
> So, safe navigation operator would be a helpful syntaxic sugar which in my
> opinion does not overlap with an existing functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
