[
https://issues.apache.org/jira/browse/JEXL-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15293504#comment-15293504
]
Dmitri Blinov edited comment on JEXL-194 at 5/23/16 1:13 PM:
-------------------------------------------------------------
Another train of thoughts...
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.
was (Author: dmitri_blinov):
Another train of thoughts...
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) ...}
@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 onStart(JexlStatement block, String annotation, Object.. args);
public void onCatch(JexlStatement block, Exception ex);
public void onFinally(JexlStatement block);
}
{code}
JexlEngine could be given a method to register annotation interceptor based on
annotation name, and the one for default interceptor. The engine should call
each Interceptor.onStart() method in the order the annotations are applied to
the statement in the script, finishing with the default interceptor if
registered. The Interceptor.onCatch() method should be called only if execution
had thrown any exception. Interceptor.onFinally() method should be called after
the statement execution regardless of any exceptions, to provide guaranteed
resource unlocking/cleaning if necessary. The Interceptor.onCatch() and
Interceptor.onFinally() methods should be called in backward order respectively.
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.
The annotation syntax should allow for zero, one or more parameters. Those
parameters should be evaluated before interceptor execution and submitted to
the Interceptor.onStart() method.
In the absence of any matching interceptors 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.
> synchronize on iterableValue in foreach statement
> -------------------------------------------------
>
> Key: JEXL-194
> URL: https://issues.apache.org/jira/browse/JEXL-194
> Project: Commons JEXL
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Dmitri Blinov
> Assignee: Henri Biestro
> Priority: Minor
>
> Since it is a requirement to synchronize on simple Collections and
> synchronized Collections while iterating over them and since jexl has no
> instrument to control synchronization in script, I think its reasonable to
> implement synchronization in jexl itself on iterableValue. In case of
> concurrent collections it will possibly block other threads only if they are
> synchronizing on those collections themselves, which will be complementary to
> required synchronization in jexl.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
