commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Date Sat, 01 Aug 2009 01:42:03 GMT
On 31/07/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> On Thu, Jul 30, 2009 at 10:54 PM, sebb<sebbaz@gmail.com> wrote:
>  > I've finished the implementation of a basic Jexl ScriptEngine for JSR-223.
>  >
>
> <snip/>
>
>  Cool, thanks.
>
>  mvn package failed for me (w/ Sun 1.6), committed fix in r799750.

Ah.

However, I think the fix may be wrong, it should probably be a
(String) cast instead, and should probably ignore the put if it's not
a String.

>  I'll take a look at the code itself in a few minutes.
>
>
>
>  > Several items remain to be resolved:
>  >
>  > The current implementation only has direct access to the ENGINE_SCOPE bindings.
>  >
>  > If we wish to give direct access to GLOBAL_SCOPE, how should this be managed?
>  > Perhaps use a name prefix to indicate that the variable is intended to
>  > be global?
>  >
>
> <snap/>
>
>  No. The engine scope is nearest, so on read or update, check engine
>  first and global second. No prefixes.
>

That's fine, but how does one create an entry in the global table?
Or is that not allowed?

>
>  > Thread-safety: is the interpreter thread-safe?
>  > If so, the getParameter() method in the factory needs to be updated.
>  >
>
> <snip/>
>
>  null return is good. If conclusive evidence shows up otherwise, we can update.
>
>
>
>  > Is there an easy way to get the current Jexl version?
>  > If so, this needs to be added to the factory.
>  >
>
> <snap/>
>
>  Not IIRC. Perhaps this should be added to JexlEngine (and the factory
>  would then use it).
>

That would be good.
In JMeter I use the version plus the SVN revision, which is
automatically derived when building the release.

>
>  > As far as I can tell, Jexl does not have built-in output statements.
>  > It might be useful to pre-define some variables to make this easier;
>  > e.g. we could define OUT as System.out, which would allow the use of
>  > OUT.println()
>  >
>
> <snip/>
>
>  Sounds reasonable. But make the name obscure, OUT would be easily trampled IMO.
>

Yes, OUT is a bit short.
How about System_OUT ?
Or we could reserve a Jexl-specific prefix; this would be useful when
using multiple languages with the same ScriptEngineManager.

>
>  > N.B. This implementation is deliberately different from the one which
>  > is currently included in BSF 3.0 binary distributions.
>  >
>  > That implementation (from https://scripting.dev.java.net/) does not
>  > allow multi-statement scripts, and it's handling of variable scopes is
>  > a bit odd, as one can read/write/delete global variables, but not
>  > create them.
>  >
>
> <snap/>
>
>  So, should be fun when services discovery finds both :-) Have you tried that?

I've not tried yet. One can use BSF 3.0 without the 3rd party engine
definitions, which would avoid the problem, but of course someone
might want to use Jexl + one of the other scripting languages.

One way to guarantee access to the new Jexl version would be to add an
alias for the language, e.g. ApacheJexl.

>  -Rahul
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message