You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bsf-dev@jakarta.apache.org by Rahul Akolkar <ra...@gmail.com> on 2008/05/14 22:54:46 UTC
JEXL engine
Lets add a JEXL [1] engine [2] here [3].
WDYT?
-Rahul
[1] http://commons.apache.org/jexl/
[2] http://issues.apache.org/jira/browse/JEXL-39
[3] http://svn.apache.org/repos/asf/jakarta/bsf/trunk/src/org/apache/bsf/engines/
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
Re: JEXL engine
Posted by "Rony G. Flatscher (Apache)" <ro...@apache.org>.
Rahul Akolkar wrote:
> On 5/19/08, Rahul Akolkar <ra...@gmail.com> wrote:
>
>> On 5/19/08, Rony G. Flatscher <Ro...@wu-wien.ac.at> wrote:
>> > Hi Rahul,
>> >
>> > > Rahul Akolkar wrote:
>> > >
>>
> <snip/>
>
>> > >
>> > > Some TODOs (see code), hopefully someone will get to those soon.
>> > >
>> >
>> > Yup! Especially a few Javadoc sentences would be great. (For someone in the
>> > know this would take probably no more than 10 minutes to do.)
>> >
>>
>> <snip/>
>>
>> Thanks for the feedback. I intend to do this by the end of the week.
>>
>>
>
>
> Done.
>
Great, thank you very much!
---rony
P.S.: Have been working on a local copy of BSF 2.4, but still need time
to do all what needs to be done besides my current workload. But with
your initiative and sebb's help things definitely move ...
Re: JEXL engine
Posted by Rahul Akolkar <ra...@gmail.com>.
On 5/19/08, Rahul Akolkar <ra...@gmail.com> wrote:
> On 5/19/08, Rony G. Flatscher <Ro...@wu-wien.ac.at> wrote:
> > Hi Rahul,
> >
> > > Rahul Akolkar wrote:
> > >
<snip/>
> > >
> > > Some TODOs (see code), hopefully someone will get to those soon.
> > >
> >
> > Yup! Especially a few Javadoc sentences would be great. (For someone in the
> > know this would take probably no more than 10 minutes to do.)
> >
>
> <snip/>
>
> Thanks for the feedback. I intend to do this by the end of the week.
>
Done.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
Re: How about a static "getRegisteredEngines()" ? ( Re: JEXL engine
Posted by sebb <se...@gmail.com>.
On 20/05/2008, Rony G. Flatscher <Ro...@wu-wien.ac.at> wrote:
> Hi Sebb,
>
>
> >
> > > Sebb - Would it help JMeter to have this? If so, can you please add ;-)
> > >
> > >
> >
> > I can't at present think of a reason why JMeter would need the version
> > at run-time, because we bundle a known version.
> >
> > But it might well be useful for other applications, e.g. web applications.
> >
> >
> From experience such metadata is not needed every day (like true
> mutliple-inheritance etc.), but if you run into a need for it then the
> availability appears to be just God sent!
>
>
> > However, it would be nice for JMeter if BSF made it easy to retrieve
> > the list of registered languages ;-)
> >
> >
> That's an interesting suggestion. Currently, BSFManager employs a HashTable
> of registered engines (langName->classNameOfEngine) which could be made
> available via a static "getRegisteredEngines()" accessor method. Would that
> help solve your use case?
>
Yes - at present JMeter has to read the properties file and keep track
of others it may add itself (only Jexl so far) so they can be
displayed in the GUI.
I'll do a JIRA for the enhancement.
> Would anyone object to add that static method to BSFManager?
>
> Any other suggestions/ideas/requests?
> [I would like to work a bit on the code this coming weekend, mainly to
> incorporate the Jira issues/requests, but then it would be also possible to
> add the one or other useful functionality.]
>
> ---rony
>
> P.S.: Personally, I would like to incorporate ant's nice class that
> incorporates all JSR-223/Java6/BSF3 scripting engines into BSF2.4, cf.
> <https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/container.script/src/main/java/org/apache/tuscany/container/script/jsr223/JSR223BSFEngine.java>
> using the org.apache.bsf package name.
>
> P.P.S.: In addition, I have been thinking of another idea which would allow
> JSR-223/Java6/BSF3 to employ BSF2.4 scripting languages, distributed with
> BSF2.4.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
How about a static "getRegisteredEngines()" ? ( Re: JEXL engine
Posted by "Rony G. Flatscher" <Ro...@wu-wien.ac.at>.
Hi Sebb,
>> Sebb - Would it help JMeter to have this? If so, can you please add ;-)
>>
>
> I can't at present think of a reason why JMeter would need the version
> at run-time, because we bundle a known version.
>
> But it might well be useful for other applications, e.g. web applications.
>
From experience such metadata is not needed every day (like true
mutliple-inheritance etc.), but if you run into a need for it then the
availability appears to be just God sent!
> However, it would be nice for JMeter if BSF made it easy to retrieve
> the list of registered languages ;-)
>
That's an interesting suggestion. Currently, BSFManager employs a
HashTable of registered engines (langName->classNameOfEngine) which
could be made available via a static "getRegisteredEngines()" accessor
method. Would that help solve your use case?
Would anyone object to add that static method to BSFManager?
Any other suggestions/ideas/requests?
[I would like to work a bit on the code this coming weekend, mainly to
incorporate the Jira issues/requests, but then it would be also possible
to add the one or other useful functionality.]
---rony
P.S.: Personally, I would like to incorporate ant's nice class that
incorporates all JSR-223/Java6/BSF3 scripting engines into BSF2.4, cf.
<https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/container.script/src/main/java/org/apache/tuscany/container/script/jsr223/JSR223BSFEngine.java>
using the org.apache.bsf package name.
P.P.S.: In addition, I have been thinking of another idea which would
allow JSR-223/Java6/BSF3 to employ BSF2.4 scripting languages,
distributed with BSF2.4.
Re: JEXL engine
Posted by sebb <se...@gmail.com>.
On 19/05/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> On 5/19/08, Rony G. Flatscher <Ro...@wu-wien.ac.at> wrote:
> > Hi Rahul,
> >
>
> > > <snap/>
> > >
> > > Please see the xdocs/ changes in r656487 (link above). I added the
> > > info in the documentation. Should be enough?
> > >
> > >
> > That's fine!
> >
> > Personally, I always like metadata which can be retrieved programmatically
> > at runtime, such that I always propose to define a static version field that
> > can be interrogated. But of course that is not really needed at all times
> > and up to you or the JEXL developers.
> >
>
> <snip/>
>
> I see.
>
> Sebb - Would it help JMeter to have this? If so, can you please add ;-)
>
I can't at present think of a reason why JMeter would need the version
at run-time, because we bundle a known version.
But it might well be useful for other applications, e.g. web applications.
However, it would be nice for JMeter if BSF made it easy to retrieve
the list of registered languages ;-)
>
> > >
> > > I meant mailing list moderation. Are commit notifications sent to dev@?
> > >
> > >
> > Hmm, good point!
> > :)
> >
> > There should be a few moderators who could/should do that (maybe Sanjiva?).
> >
>
> <snap/>
>
> OK, its better to see the messages hit this list (I'll probably wait
> for that to happen before making any more changes).
>
>
> -Rahul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
Re: JEXL engine
Posted by Rahul Akolkar <ra...@gmail.com>.
On 5/19/08, Rony G. Flatscher <Ro...@wu-wien.ac.at> wrote:
<snip/>
> Unfortunately, I am not a list moderator (am way too much "under water"
> w.r.t. e-mails, receiving more than 500 per day, granted, most of it spam,
> but still 40, 50 to process; therefore I have never volunteered as a list
> moderator).
>
> However, I think you can safely go ahead with your changes (everyone can do
> a "svn update" or "svn diff -r HEAD").
>
<snap/>
OK.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
Re: JEXL engine
Posted by "Rony G. Flatscher" <Ro...@wu-wien.ac.at>.
Hi Rahul,
>>> I meant mailing list moderation. Are commit notifications sent to dev@?
>>>
>> Hmm, good point!
>> :)
>>
>> There should be a few moderators who could/should do that (maybe Sanjiva?).
>>
> <snap/>
>
> OK, its better to see the messages hit this list (I'll probably wait
> for that to happen before making any more changes).
>
Unfortunately, I am not a list moderator (am way too much "under water"
w.r.t. e-mails, receiving more than 500 per day, granted, most of it
spam, but still 40, 50 to process; therefore I have never volunteered as
a list moderator).
However, I think you can safely go ahead with your changes (everyone can
do a "svn update" or "svn diff -r HEAD").
Regards,
---rony
Re: JEXL engine
Posted by Rahul Akolkar <ra...@gmail.com>.
On 5/19/08, Rony G. Flatscher <Ro...@wu-wien.ac.at> wrote:
> Hi Rahul,
>
> > <snap/>
> >
> > Please see the xdocs/ changes in r656487 (link above). I added the
> > info in the documentation. Should be enough?
> >
> >
> That's fine!
>
> Personally, I always like metadata which can be retrieved programmatically
> at runtime, such that I always propose to define a static version field that
> can be interrogated. But of course that is not really needed at all times
> and up to you or the JEXL developers.
>
<snip/>
I see.
Sebb - Would it help JMeter to have this? If so, can you please add ;-)
> >
> > I meant mailing list moderation. Are commit notifications sent to dev@?
> >
> >
> Hmm, good point!
> :)
>
> There should be a few moderators who could/should do that (maybe Sanjiva?).
>
<snap/>
OK, its better to see the messages hit this list (I'll probably wait
for that to happen before making any more changes).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
Re: JEXL engine
Posted by "Rony G. Flatscher" <Ro...@wu-wien.ac.at>.
Hi Rahul,
>> Yup! Especially a few Javadoc sentences would be great. (For someone in the
>> know this would take probably no more than 10 minutes to do.)
>>
> <snip/>
>
> Thanks for the feedback. I intend to do this by the end of the week.
>
Great!
>> Also, you may want to add a little info on the version of the JEXL engine
>> (either in the documentation or explicitly in the form of a static field or
>> static getter).
>>
> <snap/>
>
> Please see the xdocs/ changes in r656487 (link above). I added the
> info in the documentation. Should be enough?
>
That's fine!
Personally, I always like metadata which can be retrieved
programmatically at runtime, such that I always propose to define a
static version field that can be interrogated. But of course that is not
really needed at all times and up to you or the JEXL developers.
>>> Please allow my commits through (theres also r656486).
>>>
>> AFAICT your commits went through, could check-out
>>
> <snip/>
>
> I meant mailing list moderation. Are commit notifications sent to dev@?
>
Hmm, good point!
:)
There should be a few moderators who could/should do that (maybe Sanjiva?).
>> One thing though, what should be the entry in the Languages.properties text
>> file?
>>
> <snap/>
>
> I already added it in the same rev (656487). It matches your
> suggestion, or the other way around :-)
>
Oops, stupid me! I even cited your entry in the explicit list of the
currently defined properties. Sorry for that (I looked at the end for a
new entry only)!
Again, thank you very much for your efforts, Rahul!
Regards,
---rony
Re: JEXL engine
Posted by Rahul Akolkar <ra...@gmail.com>.
On 5/19/08, Rony G. Flatscher <Ro...@wu-wien.ac.at> wrote:
> Hi Rahul,
>
>
> >
> > > Rahul Akolkar wrote:
> > >
> > >
> > > > Lets add a JEXL [1] engine [2] here [3].
> > > >
> > > > WDYT?
> > > >
> > > >
> > > Has been sounding really interesting, hence: +1.
> > >
> > >
> > >
> > > > [1] http://commons.apache.org/jexl/
> > > > [2] http://issues.apache.org/jira/browse/JEXL-39
> > > > [3]
> > > >
> > > >
> > >
> http://svn.apache.org/repos/asf/jakarta/bsf/trunk/src/org/apache/bsf/engines/
> > > Thanks for these pointers as well!
> > >
> > > Personally, I have been having a very bad conscious due to not
> excercising
> > > my intentions in the past weeks to work-up all Jira-issues and apply
> them to
> > > BSF. Especially, not having had the time to add the short info to James
> > > Ervin's Groovy Monkey!
> > >
> > > My next possible window to get back to it would be in a week, but would
> not
> > > be insulted, if anyone else would step in and beat me on this (having
> > > *really* a bad conscious!).
> > >
> > >
> > <snip/>
> >
> > OK then :-)
> >
> > http://svn.apache.org/viewvc?view=rev&revision=656487
> >
> > Some TODOs (see code), hopefully someone will get to those soon.
> >
> >
> Yup! Especially a few Javadoc sentences would be great. (For someone in the
> know this would take probably no more than 10 minutes to do.)
>
<snip/>
Thanks for the feedback. I intend to do this by the end of the week.
> Also, you may want to add a little info on the version of the JEXL engine
> (either in the documentation or explicitly in the form of a static field or
> static getter).
>
<snap/>
Please see the xdocs/ changes in r656487 (link above). I added the
info in the documentation. Should be enough?
>
> > Please allow my commits through (theres also r656486).
> >
> >
> AFAICT your commits went through, could check-out
>
<snip/>
I meant mailing list moderation. Are commit notifications sent to dev@?
> One thing though, what should be the entry in the Languages.properties text
> file?
>
<snap/>
I already added it in the same rev (656487). It matches your
suggestion, or the other way around :-)
-Rahul
> Here's the current content:
>
> # List of script types and their associated scripting engines
> #
> # languageDescriptor = engineClass, ext1|ext2|... {, codebaseURL, ...}
> #
> # where exti are extensions for the language. Note that we leave
> # all the engines enabled now and allow them to fail at load time.
> # This way engines can be added by just adding to the classpath
> # without having to edit this file. Cheating, really, but it works.
> #
> javascript =
> org.apache.bsf.engines.javascript.JavaScriptEngine, js
> jacl = org.apache.bsf.engines.jacl.JaclEngine, jacl
> jexl = org.apache.bsf.engines.jexl.JEXLEngine, jexl
> netrexx = org.apache.bsf.engines.netrexx.NetRexxEngine,
> nrx
> java = org.apache.bsf.engines.java.JavaEngine, java
> javaclass =
> org.apache.bsf.engines.javaclass.JavaClassEngine, class
> bml = org.apache.bml.ext.BMLEngine, bml
> vbscript =
> org.apache.bsf.engines.activescript.ActiveScriptEngine, vbs
> jscript =
> org.apache.bsf.engines.activescript.ActiveScriptEngine, jss
> perlscript =
> org.apache.bsf.engines.activescript.ActiveScriptEngine, pls
> perl = org.apache.bsf.engines.perl.PerlEngine, pl
> jpython = org.apache.bsf.engines.jpython.JPythonEngine,
> py
> jython = org.apache.bsf.engines.jython.JythonEngine, py
> lotusscript =
> org.apache.bsf.engines.lotusscript.LsEngine, lss
> xslt = org.apache.bsf.engines.xslt.XSLTEngine, xslt
> pnuts = pnuts.ext.PnutsBSFEngine, pnut
> beanbasic =
> org.apache.bsf.engines.beanbasic.BeanBasicEngine, bb
> beanshell = bsh.util.BeanShellBSFEngine, bsh
> ruby = org.jruby.javasupport.bsf.JRubyEngine, rb
> judoscript = com.judoscript.BSFJudoEngine, judo|jud
> groovy = org.codehaus.groovy.bsf.GroovyEngine, groovy|gy
> objectscript = oscript.bsf.ObjectScriptEngine, os
> prolog = ubc.cs.JLog.Extras.BSF.JLogBSFEngine,
> plog|prolog
> rexx = org.rexxla.bsf.engines.rexx.RexxEngine, rex |
> rexx | cls |
> rxj | rxs | jrexx
>
> Maybe something like:
>
> jexl = org.apache.bsf.engines.jexl.JEXLEngine, jexl
>
>
> Regards,
>
> ---rony
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
Re: JEXL engine
Posted by "Rony G. Flatscher" <Ro...@wu-wien.ac.at>.
Hi Rahul,
>> Rahul Akolkar wrote:
>>
>>> Lets add a JEXL [1] engine [2] here [3].
>>>
>>> WDYT?
>>>
>> Has been sounding really interesting, hence: +1.
>>
>>
>>> [1] http://commons.apache.org/jexl/
>>> [2] http://issues.apache.org/jira/browse/JEXL-39
>>> [3]
>>>
>> http://svn.apache.org/repos/asf/jakarta/bsf/trunk/src/org/apache/bsf/engines/
>>
>> Thanks for these pointers as well!
>>
>> Personally, I have been having a very bad conscious due to not excercising
>> my intentions in the past weeks to work-up all Jira-issues and apply them to
>> BSF. Especially, not having had the time to add the short info to James
>> Ervin's Groovy Monkey!
>>
>> My next possible window to get back to it would be in a week, but would not
>> be insulted, if anyone else would step in and beat me on this (having
>> *really* a bad conscious!).
>>
> <snip/>
>
> OK then :-)
>
> http://svn.apache.org/viewvc?view=rev&revision=656487
>
> Some TODOs (see code), hopefully someone will get to those soon.
>
Yup! Especially a few Javadoc sentences would be great. (For someone in
the know this would take probably no more than 10 minutes to do.)
Also, you may want to add a little info on the version of the JEXL
engine (either in the documentation or explicitly in the form of a
static field or static getter).
> Please allow my commits through (theres also r656486).
>
AFAICT your commits went through, could check-out
One thing though, what should be the entry in the Languages.properties
text file?
Here's the current content:
# List of script types and their associated scripting engines
#
# languageDescriptor = engineClass, ext1|ext2|... {, codebaseURL, ...}
#
# where exti are extensions for the language. Note that we leave
# all the engines enabled now and allow them to fail at load time.
# This way engines can be added by just adding to the classpath
# without having to edit this file. Cheating, really, but it works.
#
javascript = org.apache.bsf.engines.javascript.JavaScriptEngine, js
jacl = org.apache.bsf.engines.jacl.JaclEngine, jacl
jexl = org.apache.bsf.engines.jexl.JEXLEngine, jexl
netrexx = org.apache.bsf.engines.netrexx.NetRexxEngine, nrx
java = org.apache.bsf.engines.java.JavaEngine, java
javaclass = org.apache.bsf.engines.javaclass.JavaClassEngine, class
bml = org.apache.bml.ext.BMLEngine, bml
vbscript = org.apache.bsf.engines.activescript.ActiveScriptEngine, vbs
jscript = org.apache.bsf.engines.activescript.ActiveScriptEngine, jss
perlscript = org.apache.bsf.engines.activescript.ActiveScriptEngine, pls
perl = org.apache.bsf.engines.perl.PerlEngine, pl
jpython = org.apache.bsf.engines.jpython.JPythonEngine, py
jython = org.apache.bsf.engines.jython.JythonEngine, py
lotusscript = org.apache.bsf.engines.lotusscript.LsEngine, lss
xslt = org.apache.bsf.engines.xslt.XSLTEngine, xslt
pnuts = pnuts.ext.PnutsBSFEngine, pnut
beanbasic = org.apache.bsf.engines.beanbasic.BeanBasicEngine, bb
beanshell = bsh.util.BeanShellBSFEngine, bsh
ruby = org.jruby.javasupport.bsf.JRubyEngine, rb
judoscript = com.judoscript.BSFJudoEngine, judo|jud
groovy = org.codehaus.groovy.bsf.GroovyEngine, groovy|gy
objectscript = oscript.bsf.ObjectScriptEngine, os
prolog = ubc.cs.JLog.Extras.BSF.JLogBSFEngine, plog|prolog
rexx = org.rexxla.bsf.engines.rexx.RexxEngine, rex | rexx | cls |
rxj | rxs | jrexx
Maybe something like:
jexl = org.apache.bsf.engines.jexl.JEXLEngine, jexl
Regards,
---rony
Re: JEXL engine
Posted by Rahul Akolkar <ra...@gmail.com>.
On 5/14/08, Rony G. Flatscher <Ro...@wu-wien.ac.at> wrote:
> Hi Rahul,
>
> Rahul Akolkar wrote:
>
> > Lets add a JEXL [1] engine [2] here [3].
> >
> > WDYT?
> >
> >
> Has been sounding really interesting, hence: +1.
>
>
> > [1] http://commons.apache.org/jexl/
> > [2] http://issues.apache.org/jira/browse/JEXL-39
> > [3]
> http://svn.apache.org/repos/asf/jakarta/bsf/trunk/src/org/apache/bsf/engines/
> >
> >
> Thanks for these pointers as well!
>
> Personally, I have been having a very bad conscious due to not excercising
> my intentions in the past weeks to work-up all Jira-issues and apply them to
> BSF. Especially, not having had the time to add the short info to James
> Ervin's Groovy Monkey!
>
> My next possible window to get back to it would be in a week, but would not
> be insulted, if anyone else would step in and beat me on this (having
> *really* a bad conscious!).
>
<snip/>
OK then :-)
http://svn.apache.org/viewvc?view=rev&revision=656487
Some TODOs (see code), hopefully someone will get to those soon.
Please allow my commits through (theres also r656486).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
Re: JEXL engine
Posted by "Rony G. Flatscher" <Ro...@wu-wien.ac.at>.
Hi Rahul,
Rahul Akolkar wrote:
> Lets add a JEXL [1] engine [2] here [3].
>
> WDYT?
>
Has been sounding really interesting, hence: +1.
> [1] http://commons.apache.org/jexl/
> [2] http://issues.apache.org/jira/browse/JEXL-39
> [3] http://svn.apache.org/repos/asf/jakarta/bsf/trunk/src/org/apache/bsf/engines/
>
Thanks for these pointers as well!
Personally, I have been having a very bad conscious due to not
excercising my intentions in the past weeks to work-up all Jira-issues
and apply them to BSF. Especially, not having had the time to add the
short info to James Ervin's Groovy Monkey!
My next possible window to get back to it would be in a week, but would
not be insulted, if anyone else would step in and beat me on this
(having *really* a bad conscious!).
Regards,
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org