commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitri Blinov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JEXL-197) Add annotations
Date Sun, 17 Jul 2016 06:47:20 GMT

    [ https://issues.apache.org/jira/browse/JEXL-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

Mime
View raw message