On 01/08/2009, sebb <seb...@gmail.com> wrote: > On 31/07/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > > On Thu, Jul 30, 2009 at 10:54 PM, sebb<seb...@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. >
Just seen your comments regarding JEXL casing. The Sun factory uses only "jexl", so if we don't use that (apart from the extension name) our factory won't get confused with the Sun one. > > -Rahul > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
