I must says I only cursorily reviewed the code Jacopo committed and did not 
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?

Like in
+        if ("groovy".equals(language)) {
+            if (scriptClass == null) {
+                scriptClass = ScriptUtil.parseScript(language, script);
+            }
+            if (scriptClass != null) {
+                result = InvokerHelper.createScript(scriptClass, 
GroovyUtil.getBinding(inputMap)).run();
+            }
+        } else if ("bsh".equals(language)) {
+            result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
+        }

In other words from Jacopo's code here, it seems you have to differentiate how 
scritps are parsed?

Jacques

From: "Adrian Crum" <adrian.c...@sandglass-software.com>
Groovy supports JSR-223, so there is no reason to treat it differently. My 
question has nothing to do with which scripting engine
is supplied with OFBiz.

-Adrian

On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because Groovy 
will be implemented OOTB. The others could be but
Groovy is already part of the framework (the inital subject from Erwan was to 
completely remove BeanShell OOTB usage), I mean
it's the idea and what Jacopo said already.

I second this idea. Everybody can use her/his preferred scripting language in 
custom projects. But using only one language OOTB
seems to be common sense. We chose groovy...

Jacques

From: "Adrian Crum" <adrian.c...@sandglass-software.com>
The code changes tested fine.

I noticed in your code comments that Groovy should be handled independently 
from other scripting languages. Why do you think
that?

-Adrian


On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762

Help with reviews and tests will be very much appreciated.

Jacopo

On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:

On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:

As far as I know, most scripting engines have some sort of embedded cache. The 
problem will be that we can't clear the
embedded
cache like we can with our own cache implementation. I don't see that as a show 
stopper - it's mostly inconvenient.

I can help out with the conversion. I don't think the task will be that hard.
Adrian, FYI I am enhancing some of the existing framework code that uses the 
GroovyUtil class to simplify this task.
I will commit my code changes today.

Regards,

Jacopo



Reply via email to