You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2009/07/31 04:54:30 UTC
[JEXL] 2.0 JSR-223 initial implementation added - what next?
I've finished the implementation of a basic Jexl ScriptEngine for JSR-223.
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?
Thread-safety: is the interpreter thread-safe?
If so, the getParameter() method in the factory needs to be updated.
Is there an easy way to get the current Jexl version?
If so, this needs to be added to the factory.
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()
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Rahul Akolkar <ra...@gmail.com>.
Just noticed -- it'd be great if you could add a package.html to the
new scripting package you added.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Fri, Jul 31, 2009 at 9:47 PM, sebb<se...@gmail.com> wrote:
> On 01/08/2009, sebb <se...@gmail.com> wrote:
>> On 31/07/2009, Rahul Akolkar <ra...@gmail.com> wrote:
>> > On Thu, Jul 30, 2009 at 10:54 PM, sebb<se...@gmail.com> wrote:
<snip/>
>> >
>> > > 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.
>
<snap/>
Yeah, but its a little more than that, I suspect theres similar issues
with extension names, mime types as well. So I suggest testing all of
those cases having both jars available for discovery.
If we can make things be mutually exclusive (through casing etc.),
thats probably best.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by sebb <se...@gmail.com>.
On 01/08/2009, sebb <se...@gmail.com> wrote:
> On 31/07/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> > On Thu, Jul 30, 2009 at 10:54 PM, sebb<se...@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-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
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Sat, Aug 1, 2009 at 2:24 PM, sebb<se...@gmail.com> wrote:
> On 01/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
>> On Sat, Aug 1, 2009 at 10:10 AM, sebb<se...@gmail.com> wrote:
>> > On 01/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
>> >> On Sat, Aug 1, 2009 at 12:21 AM, sebb<se...@gmail.com> wrote:
<snip/>
>> >>
>> >> > The ScriptEngine implementation could even make certain classes of
>> >> > global variables read-only, for example System_OUT etc. by disallowing
>> >> > changes to them.
>> >> >
>> >>
>> >> <snip/>
>> >>
>> >> Yeah, making any built-in variables read-only sounds good.
>> >
>> > For which I think we need a naming convention...
>> >
>>
>> <snip/>
>>
>> Built-in variables are a bit of a pain (we use them more extensively
>> in Commons SCXML as they are required by the spec) so if there is any
>> way to avoid having more of them, that'd be good. How about one JEXL
>> object that any built-in stuff hangs off? So, JEXL.out would be
>> System.out, for example. Extensible in the sense that JEXL.foo and
>> JEXL.bar could come along as needed without polluting the vars map
>> with more built-in names.
>
> Nice!
>
> Sounds good, I'll create an initial implementation.
>
> Probably OK to use global scope to store it in?
>
<snap/>
Engine is much safer, IMO.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by sebb <se...@gmail.com>.
On 01/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> On Sat, Aug 1, 2009 at 10:10 AM, sebb<se...@gmail.com> wrote:
> > On 01/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> >> On Sat, Aug 1, 2009 at 12:21 AM, sebb<se...@gmail.com> wrote:
> >> > On 01/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> >> >> On Fri, Jul 31, 2009 at 9:42 PM, sebb<se...@gmail.com> wrote:
> >> >> > On 31/07/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> >> >> >> On Thu, Jul 30, 2009 at 10:54 PM, sebb<se...@gmail.com> wrote:
> >>
> >> <snip/>
> >>
> >> >> >> > 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?
> >> >> >
> >> >>
> >> >> <snap/>
> >> >>
> >> >> Thats the job of the javax.script environment. More specifically, the
> >> >> ScriptEngineManager will inject the global scope bindings into the
> >> >> ScriptEngine. We just have to heed those -- IOW, anything other than
> >> >> put(), putAll() and remove() in the JexlContextWrapper class you have
> >> >> should refer to the union of the engine and global scopes. For methods
> >> >> where orders matters i.e. containsKey/Value() and get(), engine scope
> >> >> beats global. Finally, IMO the clear() implementation should remain
> >> >> as-is and not touch the global scope.
> >> >>
> >> >
> >> > Yes, one can now set up the global scope with some key-value pairs;
> >> > these are now readable/writable by a JEXL script. However, it's not
> >> > currently possible to create a global key. If put() uses a key that is
> >> > not currently present, it will generate an engine-scope variable.
> >> >
> >>
> >> <snap/>
> >>
> >> Yup, as it should.
> >>
> >>
> >>
> >> > Seems to me if we allow read/write/delete of global variables by a
> >> > JEXL script, then we should also allow creation of global variables.
> >>
> >> <snip/>
> >>
> >> Except there is no real delete.
> >>
> >
> > Ah, I was wondering about that.
> > So presumably JEXL never invokes remove() on the Jexl context?
> > I checked in Eclipse and it could not find a reference.
> >
>
> <snip/>
>
> Not unless the user manipulates the JexlContext vars map directly.
>
>
>
> >>
> >> > This would allow different scripts (possibly different languages) to
> >> > communicate via the global area.
> >> >
> >> > How to allow this? One method would be to use a naming convention.
> >> > Another might be to have a global-shift key - if the key is set, then
> >> > apply changes to the global scope only, for example:
> >> >
> >> > localvar=123;
> >> > set_scope="global"
> >> > globalval=456;
> >> > set_scope="local"
> >> >
> >> > A bit of a hack, but do-able.
> >> >
> >>
> >> <snap/>
> >>
> >> No need to hack the EL itself.
> >
> > That would not need a change to the EL.
> > The script engine would just need to check the value of the
> > "set_scope" variable.
> >
>
> <snap/>
>
> Its another difference between a standalone JEXL script and one
> executed in a 223 environment. So it needs to be added, maintained,
> documented, understood (by users) and used correctly. As you already
> point out below, this is all doable right now via the 'context'
>
> variable.
>
>
> >> Folks needing to create global variables can always inject into the
> >> engine scope an object with a method that creates a global variable
> >> (and invoke it in jexl script as needed).
> >
> > Or use
> >
> > context.getBindings(200).put(key,value);
> >
> > Given that read/write access to global variables is now handled the
> > same as for engine variables, I thought it would be convenient to do
> > the same for global variable creation.
> >
> >>
> >> > The ScriptEngine implementation could even make certain classes of
> >> > global variables read-only, for example System_OUT etc. by disallowing
> >> > changes to them.
> >> >
> >>
> >> <snip/>
> >>
> >> Yeah, making any built-in variables read-only sounds good.
> >
> > For which I think we need a naming convention...
> >
>
> <snip/>
>
> Built-in variables are a bit of a pain (we use them more extensively
> in Commons SCXML as they are required by the spec) so if there is any
> way to avoid having more of them, that'd be good. How about one JEXL
> object that any built-in stuff hangs off? So, JEXL.out would be
> System.out, for example. Extensible in the sense that JEXL.foo and
> JEXL.bar could come along as needed without polluting the vars map
> with more built-in names.
Nice!
Sounds good, I'll create an initial implementation.
Probably OK to use global scope to store it in?
>
> -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
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Sat, Aug 1, 2009 at 10:10 AM, sebb<se...@gmail.com> wrote:
> On 01/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
>> On Sat, Aug 1, 2009 at 12:21 AM, sebb<se...@gmail.com> wrote:
>> > On 01/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
>> >> On Fri, Jul 31, 2009 at 9:42 PM, sebb<se...@gmail.com> wrote:
>> >> > On 31/07/2009, Rahul Akolkar <ra...@gmail.com> wrote:
>> >> >> On Thu, Jul 30, 2009 at 10:54 PM, sebb<se...@gmail.com> wrote:
>>
>> <snip/>
>>
>> >> >> > 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?
>> >> >
>> >>
>> >> <snap/>
>> >>
>> >> Thats the job of the javax.script environment. More specifically, the
>> >> ScriptEngineManager will inject the global scope bindings into the
>> >> ScriptEngine. We just have to heed those -- IOW, anything other than
>> >> put(), putAll() and remove() in the JexlContextWrapper class you have
>> >> should refer to the union of the engine and global scopes. For methods
>> >> where orders matters i.e. containsKey/Value() and get(), engine scope
>> >> beats global. Finally, IMO the clear() implementation should remain
>> >> as-is and not touch the global scope.
>> >>
>> >
>> > Yes, one can now set up the global scope with some key-value pairs;
>> > these are now readable/writable by a JEXL script. However, it's not
>> > currently possible to create a global key. If put() uses a key that is
>> > not currently present, it will generate an engine-scope variable.
>> >
>>
>> <snap/>
>>
>> Yup, as it should.
>>
>>
>>
>> > Seems to me if we allow read/write/delete of global variables by a
>> > JEXL script, then we should also allow creation of global variables.
>>
>> <snip/>
>>
>> Except there is no real delete.
>>
>
> Ah, I was wondering about that.
> So presumably JEXL never invokes remove() on the Jexl context?
> I checked in Eclipse and it could not find a reference.
>
<snip/>
Not unless the user manipulates the JexlContext vars map directly.
>>
>> > This would allow different scripts (possibly different languages) to
>> > communicate via the global area.
>> >
>> > How to allow this? One method would be to use a naming convention.
>> > Another might be to have a global-shift key - if the key is set, then
>> > apply changes to the global scope only, for example:
>> >
>> > localvar=123;
>> > set_scope="global"
>> > globalval=456;
>> > set_scope="local"
>> >
>> > A bit of a hack, but do-able.
>> >
>>
>> <snap/>
>>
>> No need to hack the EL itself.
>
> That would not need a change to the EL.
> The script engine would just need to check the value of the
> "set_scope" variable.
>
<snap/>
Its another difference between a standalone JEXL script and one
executed in a 223 environment. So it needs to be added, maintained,
documented, understood (by users) and used correctly. As you already
point out below, this is all doable right now via the 'context'
variable.
>> Folks needing to create global variables can always inject into the
>> engine scope an object with a method that creates a global variable
>> (and invoke it in jexl script as needed).
>
> Or use
>
> context.getBindings(200).put(key,value);
>
> Given that read/write access to global variables is now handled the
> same as for engine variables, I thought it would be convenient to do
> the same for global variable creation.
>
>>
>> > The ScriptEngine implementation could even make certain classes of
>> > global variables read-only, for example System_OUT etc. by disallowing
>> > changes to them.
>> >
>>
>> <snip/>
>>
>> Yeah, making any built-in variables read-only sounds good.
>
> For which I think we need a naming convention...
>
<snip/>
Built-in variables are a bit of a pain (we use them more extensively
in Commons SCXML as they are required by the spec) so if there is any
way to avoid having more of them, that'd be good. How about one JEXL
object that any built-in stuff hangs off? So, JEXL.out would be
System.out, for example. Extensible in the sense that JEXL.foo and
JEXL.bar could come along as needed without polluting the vars map
with more built-in names.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by sebb <se...@gmail.com>.
On 01/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> On Sat, Aug 1, 2009 at 12:21 AM, sebb<se...@gmail.com> wrote:
> > On 01/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> >> On Fri, Jul 31, 2009 at 9:42 PM, sebb<se...@gmail.com> wrote:
> >> > On 31/07/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> >> >> On Thu, Jul 30, 2009 at 10:54 PM, sebb<se...@gmail.com> wrote:
>
> <snip/>
>
> >> >> > 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?
> >> >
> >>
> >> <snap/>
> >>
> >> Thats the job of the javax.script environment. More specifically, the
> >> ScriptEngineManager will inject the global scope bindings into the
> >> ScriptEngine. We just have to heed those -- IOW, anything other than
> >> put(), putAll() and remove() in the JexlContextWrapper class you have
> >> should refer to the union of the engine and global scopes. For methods
> >> where orders matters i.e. containsKey/Value() and get(), engine scope
> >> beats global. Finally, IMO the clear() implementation should remain
> >> as-is and not touch the global scope.
> >>
> >
> > Yes, one can now set up the global scope with some key-value pairs;
> > these are now readable/writable by a JEXL script. However, it's not
> > currently possible to create a global key. If put() uses a key that is
> > not currently present, it will generate an engine-scope variable.
> >
>
> <snap/>
>
> Yup, as it should.
>
>
>
> > Seems to me if we allow read/write/delete of global variables by a
> > JEXL script, then we should also allow creation of global variables.
>
> <snip/>
>
> Except there is no real delete.
>
Ah, I was wondering about that.
So presumably JEXL never invokes remove() on the Jexl context?
I checked in Eclipse and it could not find a reference.
>
> > This would allow different scripts (possibly different languages) to
> > communicate via the global area.
> >
> > How to allow this? One method would be to use a naming convention.
> > Another might be to have a global-shift key - if the key is set, then
> > apply changes to the global scope only, for example:
> >
> > localvar=123;
> > set_scope="global"
> > globalval=456;
> > set_scope="local"
> >
> > A bit of a hack, but do-able.
> >
>
> <snap/>
>
> No need to hack the EL itself.
That would not need a change to the EL.
The script engine would just need to check the value of the
"set_scope" variable.
> Folks needing to create global variables can always inject into the
> engine scope an object with a method that creates a global variable
> (and invoke it in jexl script as needed).
Or use
context.getBindings(200).put(key,value);
Given that read/write access to global variables is now handled the
same as for engine variables, I thought it would be convenient to do
the same for global variable creation.
>
> > The ScriptEngine implementation could even make certain classes of
> > global variables read-only, for example System_OUT etc. by disallowing
> > changes to them.
> >
>
> <snip/>
>
> Yeah, making any built-in variables read-only sounds good.
For which I think we need a naming convention...
> -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
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Sat, Aug 1, 2009 at 12:21 AM, sebb<se...@gmail.com> wrote:
> On 01/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
>> On Fri, Jul 31, 2009 at 9:42 PM, sebb<se...@gmail.com> wrote:
>> > On 31/07/2009, Rahul Akolkar <ra...@gmail.com> wrote:
>> >> On Thu, Jul 30, 2009 at 10:54 PM, sebb<se...@gmail.com> wrote:
<snip/>
>> >> > 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?
>> >
>>
>> <snap/>
>>
>> Thats the job of the javax.script environment. More specifically, the
>> ScriptEngineManager will inject the global scope bindings into the
>> ScriptEngine. We just have to heed those -- IOW, anything other than
>> put(), putAll() and remove() in the JexlContextWrapper class you have
>> should refer to the union of the engine and global scopes. For methods
>> where orders matters i.e. containsKey/Value() and get(), engine scope
>> beats global. Finally, IMO the clear() implementation should remain
>> as-is and not touch the global scope.
>>
>
> Yes, one can now set up the global scope with some key-value pairs;
> these are now readable/writable by a JEXL script. However, it's not
> currently possible to create a global key. If put() uses a key that is
> not currently present, it will generate an engine-scope variable.
>
<snap/>
Yup, as it should.
> Seems to me if we allow read/write/delete of global variables by a
> JEXL script, then we should also allow creation of global variables.
<snip/>
Except there is no real delete.
> This would allow different scripts (possibly different languages) to
> communicate via the global area.
>
> How to allow this? One method would be to use a naming convention.
> Another might be to have a global-shift key - if the key is set, then
> apply changes to the global scope only, for example:
>
> localvar=123;
> set_scope="global"
> globalval=456;
> set_scope="local"
>
> A bit of a hack, but do-able.
>
<snap/>
No need to hack the EL itself.
Folks needing to create global variables can always inject into the
engine scope an object with a method that creates a global variable
(and invoke it in jexl script as needed).
> The ScriptEngine implementation could even make certain classes of
> global variables read-only, for example System_OUT etc. by disallowing
> changes to them.
>
<snip/>
Yeah, making any built-in variables read-only sounds good.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by sebb <se...@gmail.com>.
On 01/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> On Fri, Jul 31, 2009 at 9:42 PM, sebb<se...@gmail.com> wrote:
> > On 31/07/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> >> On Thu, Jul 30, 2009 at 10:54 PM, sebb<se...@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.
> >
>
> <snip/>
>
> Ah, saw the related BSF bug you logged.
>
>
>
> >> 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?
> >
>
> <snap/>
>
> Thats the job of the javax.script environment. More specifically, the
> ScriptEngineManager will inject the global scope bindings into the
> ScriptEngine. We just have to heed those -- IOW, anything other than
> put(), putAll() and remove() in the JexlContextWrapper class you have
> should refer to the union of the engine and global scopes. For methods
> where orders matters i.e. containsKey/Value() and get(), engine scope
> beats global. Finally, IMO the clear() implementation should remain
> as-is and not touch the global scope.
>
Yes, one can now set up the global scope with some key-value pairs;
these are now readable/writable by a JEXL script. However, it's not
currently possible to create a global key. If put() uses a key that is
not currently present, it will generate an engine-scope variable.
Seems to me if we allow read/write/delete of global variables by a
JEXL script, then we should also allow creation of global variables.
This would allow different scripts (possibly different languages) to
communicate via the global area.
How to allow this? One method would be to use a naming convention.
Another might be to have a global-shift key - if the key is set, then
apply changes to the global scope only, for example:
localvar=123;
set_scope="global"
globalval=456;
set_scope="local"
A bit of a hack, but do-able.
The ScriptEngine implementation could even make certain classes of
global variables read-only, for example System_OUT etc. by disallowing
changes to them.
>
> >>
> >> > 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.
> >
>
> <snip/>
>
> Slight preference towards a JEXL-specific prefix.
>
> -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
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Fri, Jul 31, 2009 at 9:42 PM, sebb<se...@gmail.com> wrote:
> On 31/07/2009, Rahul Akolkar <ra...@gmail.com> wrote:
>> On Thu, Jul 30, 2009 at 10:54 PM, sebb<se...@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.
>
<snip/>
Ah, saw the related BSF bug you logged.
>> 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?
>
<snap/>
Thats the job of the javax.script environment. More specifically, the
ScriptEngineManager will inject the global scope bindings into the
ScriptEngine. We just have to heed those -- IOW, anything other than
put(), putAll() and remove() in the JexlContextWrapper class you have
should refer to the union of the engine and global scopes. For methods
where orders matters i.e. containsKey/Value() and get(), engine scope
beats global. Finally, IMO the clear() implementation should remain
as-is and not touch the global scope.
>>
>> > 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.
>
<snip/>
Slight preference towards a JEXL-specific prefix.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by sebb <se...@gmail.com>.
On 31/07/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> On Thu, Jul 30, 2009 at 10:54 PM, sebb<se...@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
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Thu, Jul 30, 2009 at 10:54 PM, sebb<se...@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.
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.
> 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).
> 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.
> 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?
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Sat, Aug 1, 2009 at 4:28 PM, Henrib<hb...@gmail.com> wrote:
>
> I've been recently through a lot of the code so I'm confident enough about
> its thread-safety to use it in this way (share an instance of a UnifiedJEXL
> engine & its underlying JexlEngine).
>
> However, I dont intend to use it through the jsr-223 interface; if the
> jsr-223 "multi-threaded engine" or "thread isolated engine" properties were
> to be considered an important feature for Jexl, I'd gladly help and
> contribute some cycles on this.
> I guess if this ever comes important enough, someone in the community will
> create a subtask of JEXL-63.
>
> I'll focus for now on JEXL-43 & friends. :-)
>
<snip/>
Yup, good plan :-)
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Henrib <hb...@gmail.com>.
I've been recently through a lot of the code so I'm confident enough about
its thread-safety to use it in this way (share an instance of a UnifiedJEXL
engine & its underlying JexlEngine).
However, I dont intend to use it through the jsr-223 interface; if the
jsr-223 "multi-threaded engine" or "thread isolated engine" properties were
to be considered an important feature for Jexl, I'd gladly help and
contribute some cycles on this.
I guess if this ever comes important enough, someone in the community will
create a subtask of JEXL-63.
I'll focus for now on JEXL-43 & friends. :-)
--
View this message in context: http://www.nabble.com/-JEXL--2.0-JSR-223-initial-implementation-added---what-next--tp24750307p24772433.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Sat, Aug 1, 2009 at 3:40 PM, Henrib<hb...@gmail.com> wrote:
>
>
>
> Rahul Akolkar wrote:
>>
>> ...
>> Correct, some patterns of usage make more sense than others. But to
>> make any claims via the 223 API, we have to do rigorous code
>> inspection and add some tests. Until someone does that, lets return
>> null.
>> ...
>>
>
> Should I create a bug for later then - just as a reminder ?
<snip/>
Sure, if you intend to look into it :-)
> I can add some multi-threaded tests but I'm not sure they'll "prove"
> multi-threading; they could only prove something if they were to fail. :-)
>
<snap/>
Indeed (hence the code inspection I was talking about).
> And about the ScriptContext (at least the engine & global bindings) , I
> guess we'd need to alter those to be synchronized & thread safe.
>
> Aren't there any guidelines in the spec (or even tests via the TCK) or
> something that could serve as a base ?
>
<snip/>
Perhaps, I don't have the TCK (and ATM don't intend to ask for it either).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Henrib <hb...@gmail.com>.
Rahul Akolkar wrote:
>
> ...
> Correct, some patterns of usage make more sense than others. But to
> make any claims via the 223 API, we have to do rigorous code
> inspection and add some tests. Until someone does that, lets return
> null.
> ...
>
Should I create a bug for later then - just as a reminder ?
I can add some multi-threaded tests but I'm not sure they'll "prove"
multi-threading; they could only prove something if they were to fail. :-)
And about the ScriptContext (at least the engine & global bindings) , I
guess we'd need to alter those to be synchronized & thread safe.
Aren't there any guidelines in the spec (or even tests via the TCK) or
something that could serve as a base ?
--
View this message in context: http://www.nabble.com/-JEXL--2.0-JSR-223-initial-implementation-added---what-next--tp24750307p24772036.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Sat, Aug 1, 2009 at 12:21 PM, Henrib<hb...@gmail.com> wrote:
>
>
>
> sebb-2-2 wrote:
>>
>> Thread-safety: is the interpreter thread-safe?
>>
>
> Both the JexlEngine & UnifiedJEXL are intended to be thread-safe & shared.
> Besides usage of final fields in any applicable case, the (Expression,
> UnifiedJEXL.Expression, MethodMap & al) shared caches are synchronized for
> get/put and the expression node cache are volatile to ensure atomic
> read/write ops.
> The Interpreter is a "transient" that's never used outside of an eval and
> will not be shared.
> For peace of mind, the methods that manipulate flags for the
> JexlEngine/UnifiedJEXL setLenient, setDebug & al could be made synchronized
> or using volatile fields but it does not make much sense to call those after
> real usage has began.
>
<snip/>
Correct, some patterns of usage make more sense than others. But to
make any claims via the 223 API, we have to do rigorous code
inspection and add some tests. Until someone does that, lets return
null.
> The only edge case is the JexlContext (at least the instance created by
> JexlHelper) which is *not* threadsafe being based on a HashMap.
>
<snap/>
Things like that :-)
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Posted by Henrib <hb...@gmail.com>.
sebb-2-2 wrote:
>
> Thread-safety: is the interpreter thread-safe?
>
Both the JexlEngine & UnifiedJEXL are intended to be thread-safe & shared.
Besides usage of final fields in any applicable case, the (Expression,
UnifiedJEXL.Expression, MethodMap & al) shared caches are synchronized for
get/put and the expression node cache are volatile to ensure atomic
read/write ops.
The Interpreter is a "transient" that's never used outside of an eval and
will not be shared.
For peace of mind, the methods that manipulate flags for the
JexlEngine/UnifiedJEXL setLenient, setDebug & al could be made synchronized
or using volatile fields but it does not make much sense to call those after
real usage has began.
The only edge case is the JexlContext (at least the instance created by
JexlHelper) which is *not* threadsafe being based on a HashMap.
--
View this message in context: http://www.nabble.com/-JEXL--2.0-JSR-223-initial-implementation-added---what-next--tp24750307p24770490.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org