Definitively remove beanshell from OFBiz

[Adrian Crum-3]

If you don't mind, I would like to get all of the issues resolved during
the design phase.

I will wait for the private email to understand what you mean by a
"secure" scripting package.

What I was suggesting is a script utility object that can be put in the
context so that all scripting languages can use it. Whatever methods you
have in mind could be implemented in a generic way and reused.
Personally, I would like to use something like:

// Groovy, JavaScript
partyValue = script.entityOne("Party");
if (partyValue)...

In other words, have an object in the context that gives us the
convenience of mini-language.

-Adrian

On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:

> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>
>> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.
> Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
> If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.
>
>> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>>
> I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.
>
> Jacopo
>
>> -Adrian
>>
>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>
>>>> 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?
>>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>>
>>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>>
>>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>>
>>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>>
>>> Jacopo
>>>
>>>> -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
>>>>>>
>>>>>>
>>>>>>

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>
> Okay, we can give it a try and see if we run into any problems.
>
> Btw, expressions should go in the from-field attribute, not the value attribute.

Why? I'd prefer to stay the same than now. I agree it's a convention, but from-field makes less sense to me for evaluated
expressions (being in a script or inlined)

Jacques

> -Adrian
>
> On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
>> Yes, this is fine and I was thinking about a similar solution; however I would like to find a simpler convention because
>> [script:groovy] is a lot of typing and could be difficult to read when the code in buried in the "value" attribute of a "set"
>> element.
>> Something like:
>> ${script:jython code_here}
>> ${script:groovy code_here}
>> ${script: code_here} this could use the "default" language set in some properties file (i.e. "groovy"); this follows the
>> "configuration by exception" pattern (specify the script only if you want to use a non default one).
>>
>> But we should also consider a shortcut where the "script" word is abbreviated, for example by the "s" word:
>> ${s:jython code_here}
>> ${s:groovy code_here}
>> ${s: code_here}
>>
>> Jacopo
>>
>> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>>
>>> I was thinking we could use something like ${[script:groovy]...} ${[script:jython]...} etc. I'm concerned that looking for a
>>> string followed by a colon can lead to errors.
>>>
>>> -Adrian
>>>
>>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>>> I would like to clarify that in this first pass I focused on "moving code around" keeping the same exact behavior currently
>>>> implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent on
>>>> ScriptUtil class.
>>>> In order to implement JSR-223 we may have to change some of the current behavior (the different way Beanshell and Groovy are
>>>> preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no spaces)
>>>> followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on existing
>>>> scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify them
>>>> to be compatible with the convention. I intentionally didn't focus on this second step.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>>
>>>>> 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"<[hidden email]>
>>>>>> 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"<[hidden email]>
>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

[Adrian Crum-3]

Because the value attribute is supposed to represent a string constant
(that can be converted to another type via the type attribute), and the
from-field attribute is supposed to represent a variable.

My preference is to have a from-expression attribute to make things clearer.

 From my perspective, the main reason mini-language has such strange and
quirky behavior is because the syntax has not been clearly expressed or
implemented.

-Adrian

On 3/5/2012 8:51 AM, Jacques Le Roux wrote:

> From: "Adrian Crum" <[hidden email]>
>> Okay, we can give it a try and see if we run into any problems.
>>
>> Btw, expressions should go in the from-field attribute, not the value
>> attribute.
>
> Why? I'd prefer to stay the same than now. I agree it's a convention,
> but from-field makes less sense to me for evaluated expressions (being
> in a script or inlined)
>
> Jacques
>
>> -Adrian
>>
>> On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
>>> Yes, this is fine and I was thinking about a similar solution;
>>> however I would like to find a simpler convention because
>>> [script:groovy] is a lot of typing and could be difficult to read
>>> when the code in buried in the "value" attribute of a "set"
>>> element.
>>> Something like:
>>> ${script:jython code_here}
>>> ${script:groovy code_here}
>>> ${script: code_here} this could use the "default" language set in
>>> some properties file (i.e. "groovy"); this follows the
>>> "configuration by exception" pattern (specify the script only if you
>>> want to use a non default one).
>>>
>>> But we should also consider a shortcut where the "script" word is
>>> abbreviated, for example by the "s" word:
>>> ${s:jython code_here}
>>> ${s:groovy code_here}
>>> ${s: code_here}
>>>
>>> Jacopo
>>>
>>> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>>>
>>>> I was thinking we could use something like ${[script:groovy]...}
>>>> ${[script:jython]...} etc. I'm concerned that looking for a
>>>> string followed by a colon can lead to errors.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>>>> I would like to clarify that in this first pass I focused on
>>>>> "moving code around" keeping the same exact behavior currently
>>>>> implemented: now all the code that had a dependency on Groovy or
>>>>> Beanshell packages has been converted to be only dependent on
>>>>> ScriptUtil class.
>>>>> In order to implement JSR-223 we may have to change some of the
>>>>> current behavior (the different way Beanshell and Groovy are
>>>>> preparsed/executed) and also check if we can always assume that if
>>>>> the code inside of ${...} starts with a string (no spaces)
>>>>> followed by a colon (and a blank character?) then the string is
>>>>> the scripting language: I didn't check the impact on existing
>>>>> scripts but it should be easy to write a reg exp to find all of
>>>>> them (I expect that the number will be small) and modify them
>>>>> to be compatible with the convention. I intentionally didn't focus
>>>>> on this second step.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>>>
>>>>>> 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"<[hidden email]>
>>>>>>> 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"<[hidden email]>
>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

[Malin Nicolas]

Le 05/03/2012 10:08, Adrian Crum a écrit :
> Because the value attribute is supposed to represent a string constant
> (that can be converted to another type via the type attribute), and
> the from-field attribute is supposed to represent a variable.
>
> My preference is to have a from-expression attribute to make things
> clearer.

Same opinion, the from-expression miss to separate the value origin:
  * from-field : provide only from existent context field
  * value : only given value (Parsing by the given type)
  * from-expression : calling script interface to resolve value.

>
> From my perspective, the main reason mini-language has such strange
> and quirky behavior is because the syntax has not been clearly
> expressed or implemented.
>
> -Adrian
>
> On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <[hidden email]>
>>> Okay, we can give it a try and see if we run into any problems.
>>>
>>> Btw, expressions should go in the from-field attribute, not the
>>> value attribute.
>>
>> Why? I'd prefer to stay the same than now. I agree it's a convention,
>> but from-field makes less sense to me for evaluated expressions
>> (being in a script or inlined)
>>
>> Jacques
>>
>>> -Adrian
>>>
>>> On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
>>>> Yes, this is fine and I was thinking about a similar solution;
>>>> however I would like to find a simpler convention because
>>>> [script:groovy] is a lot of typing and could be difficult to read
>>>> when the code in buried in the "value" attribute of a "set"
>>>> element.
>>>> Something like:
>>>> ${script:jython code_here}
>>>> ${script:groovy code_here}
>>>> ${script: code_here} this could use the "default" language set in
>>>> some properties file (i.e. "groovy"); this follows the
>>>> "configuration by exception" pattern (specify the script only if
>>>> you want to use a non default one).
>>>>
>>>> But we should also consider a shortcut where the "script" word is
>>>> abbreviated, for example by the "s" word:
>>>> ${s:jython code_here}
>>>> ${s:groovy code_here}
>>>> ${s: code_here}
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>>>>
>>>>> I was thinking we could use something like ${[script:groovy]...}
>>>>> ${[script:jython]...} etc. I'm concerned that looking for a
>>>>> string followed by a colon can lead to errors.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>>>>> I would like to clarify that in this first pass I focused on
>>>>>> "moving code around" keeping the same exact behavior currently
>>>>>> implemented: now all the code that had a dependency on Groovy or
>>>>>> Beanshell packages has been converted to be only dependent on
>>>>>> ScriptUtil class.
>>>>>> In order to implement JSR-223 we may have to change some of the
>>>>>> current behavior (the different way Beanshell and Groovy are
>>>>>> preparsed/executed) and also check if we can always assume that
>>>>>> if the code inside of ${...} starts with a string (no spaces)
>>>>>> followed by a colon (and a blank character?) then the string is
>>>>>> the scripting language: I didn't check the impact on existing
>>>>>> scripts but it should be easy to write a reg exp to find all of
>>>>>> them (I expect that the number will be small) and modify them
>>>>>> to be compatible with the convention. I intentionally didn't
>>>>>> focus on this second step.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> 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"<[hidden email]>
>>>>>>>> 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"<[hidden email]>
>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Jacques Le Roux]

Mmm... from-expression indeed.... This remembered me a discussion we had already
http://markmail.org/message/dzljmdhg2c3i52aq

No time to re-read at the moment, but yes from-expression sounds good to me and not that hard to change in current code.

Jacques


From: "Adrian Crum" <[hidden email]>

> Because the value attribute is supposed to represent a string constant
> (that can be converted to another type via the type attribute), and the
> from-field attribute is supposed to represent a variable.
>
> My preference is to have a from-expression attribute to make things clearer.
>
> From my perspective, the main reason mini-language has such strange and
> quirky behavior is because the syntax has not been clearly expressed or
> implemented.
>
> -Adrian
>
> On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <[hidden email]>
>>> Okay, we can give it a try and see if we run into any problems.
>>>
>>> Btw, expressions should go in the from-field attribute, not the value
>>> attribute.
>>
>> Why? I'd prefer to stay the same than now. I agree it's a convention,
>> but from-field makes less sense to me for evaluated expressions (being
>> in a script or inlined)
>>
>> Jacques
>>
>>> -Adrian
>>>
>>> On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
>>>> Yes, this is fine and I was thinking about a similar solution;
>>>> however I would like to find a simpler convention because
>>>> [script:groovy] is a lot of typing and could be difficult to read
>>>> when the code in buried in the "value" attribute of a "set"
>>>> element.
>>>> Something like:
>>>> ${script:jython code_here}
>>>> ${script:groovy code_here}
>>>> ${script: code_here} this could use the "default" language set in
>>>> some properties file (i.e. "groovy"); this follows the
>>>> "configuration by exception" pattern (specify the script only if you
>>>> want to use a non default one).
>>>>
>>>> But we should also consider a shortcut where the "script" word is
>>>> abbreviated, for example by the "s" word:
>>>> ${s:jython code_here}
>>>> ${s:groovy code_here}
>>>> ${s: code_here}
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>>>>
>>>>> I was thinking we could use something like ${[script:groovy]...}
>>>>> ${[script:jython]...} etc. I'm concerned that looking for a
>>>>> string followed by a colon can lead to errors.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>>>>> I would like to clarify that in this first pass I focused on
>>>>>> "moving code around" keeping the same exact behavior currently
>>>>>> implemented: now all the code that had a dependency on Groovy or
>>>>>> Beanshell packages has been converted to be only dependent on
>>>>>> ScriptUtil class.
>>>>>> In order to implement JSR-223 we may have to change some of the
>>>>>> current behavior (the different way Beanshell and Groovy are
>>>>>> preparsed/executed) and also check if we can always assume that if
>>>>>> the code inside of ${...} starts with a string (no spaces)
>>>>>> followed by a colon (and a blank character?) then the string is
>>>>>> the scripting language: I didn't check the impact on existing
>>>>>> scripts but it should be easy to write a reg exp to find all of
>>>>>> them (I expect that the number will be small) and modify them
>>>>>> to be compatible with the convention. I intentionally didn't focus
>>>>>> on this second step.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> 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"<[hidden email]>
>>>>>>>> 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"<[hidden email]>
>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

[Malin Nicolas]

Hi Jacopo,

Interesting discussion :)

Like you said, the selected solution will have all the features we need.
At this time Apache OFBiz offering a great functional framework with
technical interface, this allows to functional developer to stay focused
on their needsand don't waste on technical problem. It's really
important to don't lose it.

My feedback between Neogia and OFBiz (since we have in the same case
that choice 3) and 4))

  * Fork : easier to improve the framework, but really difficult to back
improvements to original project. Many waste time to realize
improvement in parallel. I don't recommend it
  * Synchronize by repository : import a external framework release,
provides flexibility to update the external source and show own
improvement. But with time past, the differences grow, increasing the
synchro time and decreasing the back improvement quality. We stop this
solution there are two years.
   * At this time, with develop addon manager system to separate each
improvement on dedicate addon. This simplify the synchronization with
external source, keep back improvement quality. We lost in commit
celerit, it's a little more complicated to improve an addon than only
commit in a repository.

Whatever solution, I am available to help you.

Nicolas

Le 02/03/2012 09:28, Jacopo Cappellato a écrit :

> On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:
>
>> Jacopo,
>>
>> You would even consider forking?
>  From Wikipedia [*]:
>
> "[...] More recently, distributed revision control (DVCS) tools have popularised a less emotive use of the term "fork", blurring the distinction with "branch". With a DVCS such as Mercurial or Git, the normal way to contribute to a project is to first branch the repository, and later seek to have your changes integrated with the main repository. Sites such as Github, Bitbucket and Launchpad provide free DVCS hosting expressly supporting independent branches, such that the technical, social and financial barriers to forking a source code repository are massively reduced."
>
> In order of preference (descending), here are the options I see for the future of the OFBiz framework:
>
> 1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then release it separately from the Apache OFBiz ERP
> 2) greatly clean up and improve the existing framework (I was not sure if this could go at #1)
> 3) if the above will not be possible (frankly speaking, in the committers group, apart from David, none of us ever implemented with success an open source framework) we should also consider to drop the existing code and have our community focusing on the ERP part (as Hans seems to advocate); at this point Moqui would be the most natural choice; if we will ever go with this path a great exchange of information will have to happen between the two projects: for example OFBiz will probably have to ask the Moqui framework to evolve some of its features; given the current nature of the Moqui project, I doubt that the OFBiz committers will be ever invited as committers there; if Moqui will be our choice, I see two possibilities:
> 3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be possible if Moqui release will have all the features we need (and if Moqui community will be interested in getting contribution to evolve in the direction required by OFBzi)
> 3.b) if 3.a will not be possible because OFBiz will need some features that Moqui community will not consider as a good fit for Moqui, then, under the guidance and bless of David, we could work on a fork: get the code from a Moqui release, import in our repository and add to it, in a controlled way, the features we need; of course this should be always kept as close as possible to the original code; we could synch our custom code with every new Moqui release; I was not thinking about *stealing* code to Moqui and the fact that David is both the founder of OFBiz and of Moqui and he is both in the OFBiz PMC and the leader of the Moqui project will definitely facilitate this; but it will be still an ugly solution but for example when you said: "My proposal is that Apache OFBiz will be in the future just the ERP system based on many opensource products like birt and also Moqui...." you are actually implying that the ERP applications will be able to use Birt... but this requires some sort of framework and what would you do if Moqui will not think that Birt is a good fit for them?
> 4) if Moqui will not be a good option we may consider other frameworks (?), but it will be difficult, or continue with what we have
>
> Jacopo
>
>
>
> [*]: http://en.wikipedia.org/wiki/Fork_(software_development)

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Upep à les7arts]

From: "Nicolas Malin" <[hidden email]>
> Le 05/03/2012 10:08, Adrian Crum a écrit :
>> Because the value attribute is supposed to represent a string constant (that can be converted to another type via the type
>> attribute), and the from-field attribute is supposed to represent a variable.
>>
>> My preference is to have a from-expression attribute to make things clearer.
>
> Same opinion, the from-expression miss to separate the value origin:

I guess you meant from-field above ;o)

Jacques

>  * from-field : provide only from existent context field
>  * value : only given value (Parsing by the given type)
>  * from-expression : calling script interface to resolve value.
>
>>
>> From my perspective, the main reason mini-language has such strange and quirky behavior is because the syntax has not been
>> clearly expressed or implemented.
>>
>> -Adrian
>>
>> On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
>>> From: "Adrian Crum" <[hidden email]>
>>>> Okay, we can give it a try and see if we run into any problems.
>>>>
>>>> Btw, expressions should go in the from-field attribute, not the value attribute.
>>>
>>> Why? I'd prefer to stay the same than now. I agree it's a convention, but from-field makes less sense to me for evaluated
>>> expressions (being in a script or inlined)
>>>
>>> Jacques
>>>
>>>> -Adrian
>>>>
>>>> On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
>>>>> Yes, this is fine and I was thinking about a similar solution; however I would like to find a simpler convention because
>>>>> [script:groovy] is a lot of typing and could be difficult to read when the code in buried in the "value" attribute of a "set"
>>>>> element.
>>>>> Something like:
>>>>> ${script:jython code_here}
>>>>> ${script:groovy code_here}
>>>>> ${script: code_here} this could use the "default" language set in some properties file (i.e. "groovy"); this follows the
>>>>> "configuration by exception" pattern (specify the script only if you want to use a non default one).
>>>>>
>>>>> But we should also consider a shortcut where the "script" word is abbreviated, for example by the "s" word:
>>>>> ${s:jython code_here}
>>>>> ${s:groovy code_here}
>>>>> ${s: code_here}
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
>>>>>
>>>>>> I was thinking we could use something like ${[script:groovy]...} ${[script:jython]...} etc. I'm concerned that looking for a
>>>>>> string followed by a colon can lead to errors.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
>>>>>>> I would like to clarify that in this first pass I focused on "moving code around" keeping the same exact behavior currently
>>>>>>> implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent
>>>>>>> on
>>>>>>> ScriptUtil class.
>>>>>>> In order to implement JSR-223 we may have to change some of the current behavior (the different way Beanshell and Groovy are
>>>>>>> preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no
>>>>>>> spaces)
>>>>>>> followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on
>>>>>>> existing
>>>>>>> scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify
>>>>>>> them
>>>>>>> to be compatible with the convention. I intentionally didn't focus on this second step.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
>>>>>>>
>>>>>>>> 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"<[hidden email]>
>>>>>>>>> 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"<[hidden email]>
>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>
>
> --
> Nicolas MALIN
> Consultant
> Tél : [phone]
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : [phone]
> Site : http://www.librenberry.net/
>

[Shi Jinghai-3]

+1 to 3.a).


On 2012-3-2, at 下午4:28, Jacopo Cappellato wrote:

>
> On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:
>
>> Jacopo,
>>
>> You would even consider forking?
>
> From Wikipedia [*]:
>
> "[...] More recently, distributed revision control (DVCS) tools have popularised a less emotive use of the term "fork", blurring the distinction with "branch". With a DVCS such as Mercurial or Git, the normal way to contribute to a project is to first branch the repository, and later seek to have your changes integrated with the main repository. Sites such as Github, Bitbucket and Launchpad provide free DVCS hosting expressly supporting independent branches, such that the technical, social and financial barriers to forking a source code repository are massively reduced."
>
> In order of preference (descending), here are the options I see for the future of the OFBiz framework:
>
> 1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then release it separately from the Apache OFBiz ERP
> 2) greatly clean up and improve the existing framework (I was not sure if this could go at #1)
> 3) if the above will not be possible (frankly speaking, in the committers group, apart from David, none of us ever implemented with success an open source framework) we should also consider to drop the existing code and have our community focusing on the ERP part (as Hans seems to advocate); at this point Moqui would be the most natural choice; if we will ever go with this path a great exchange of information will have to happen between the two projects: for example OFBiz will probably have to ask the Moqui framework to evolve some of its features; given the current nature of the Moqui project, I doubt that the OFBiz committers will be ever invited as committers there; if Moqui will be our choice, I see two possibilities:
> 3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be possible if Moqui release will have all the features we need (and if Moqui community will be interested in getting contribution to evolve in the direction required by OFBzi)
> 3.b) if 3.a will not be possible because OFBiz will need some features that Moqui community will not consider as a good fit for Moqui, then, under the guidance and bless of David, we could work on a fork: get the code from a Moqui release, import in our repository and add to it, in a controlled way, the features we need; of course this should be always kept as close as possible to the original code; we could synch our custom code with every new Moqui release; I was not thinking about *stealing* code to Moqui and the fact that David is both the founder of OFBiz and of Moqui and he is both in the OFBiz PMC and the leader of the Moqui project will definitely facilitate this; but it will be still an ugly solution but for example when you said: "My proposal is that Apache OFBiz will be in the future just the ERP system based on many opensource products like birt and also Moqui...." you are actually implying that the ERP applications will be able to use Birt... but this requires some sort of framework and what would you do if Moqui will not think that Birt is a good fit for them?
> 4) if Moqui will not be a good option we may consider other frameworks (?), but it will be difficult, or continue with what we have
>
> Jacopo
>
>
>
> [*]: http://en.wikipedia.org/wiki/Fork_(software_development)

[Jacopo Cappellato-4]

This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
But I don't have a clear list at the moment so please do not consider my notes a blocker.
I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.

Jacopo

On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:

> If you don't mind, I would like to get all of the issues resolved during the design phase.
>
> I will wait for the private email to understand what you mean by a "secure" scripting package.
>
> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>
> // Groovy, JavaScript
> partyValue = script.entityOne("Party");
> if (partyValue)...
>
> In other words, have an object in the context that gives us the convenience of mini-language.
>
> -Adrian
>
> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>
>>> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.
>> Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
>> If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.
>>
>>> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>>>
>> I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.
>>
>> Jacopo
>>
>>> -Adrian
>>>
>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>
>>>>> 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?
>>>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>>>
>>>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>>>
>>>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>>>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>>>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>>>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>>>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>>>
>>>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>>>
>>>> Jacopo
>>>>
>>>>> -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
>>>>>>>
>>>>>>>
>>>>>>>

[Adrian Crum-3]

Update: I added a generic ScriptEngine to the service engine in rev 1297323.

I haven't updated screen widgets and mini-lang to use JSR-223 because
there is a compatibility problem. In JSR-223, the "context" binding is
reserved for the ScriptContext object, so any script code that uses the
variable "context" will be using the ScriptContext object - not the
context Map. I'm not sure how to proceed from here.

-Adrian

On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:

> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
> But I don't have a clear list at the moment so please do not consider my notes a blocker.
> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>
> Jacopo
>
> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>
>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>
>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>
>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>
>> // Groovy, JavaScript
>> partyValue = script.entityOne("Party");
>> if (partyValue)...
>>
>> In other words, have an object in the context that gives us the convenience of mini-language.
>>
>> -Adrian
>>
>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>
>>>> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.
>>> Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
>>> If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.
>>>
>>>> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>>>>
>>> I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.
>>>
>>> Jacopo
>>>
>>>> -Adrian
>>>>
>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>
>>>>>> 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?
>>>>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>>>>
>>>>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>>>>
>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>>>>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>>>>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>>>>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>>>>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>>>>
>>>>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>> -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
>>>>>>>>
>>>>>>>>
>>>>>>>>

[Jacopo Cappellato-4]

I would be in favor of bulk renaming all the "context" variables in our scripts... maybe we could wait after the creation of the 12.04 release branch... but I would be in favor even if we do this earlier.

Jacopo

On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:

> Update: I added a generic ScriptEngine to the service engine in rev 1297323.
>
> I haven't updated screen widgets and mini-lang to use JSR-223 because there is a compatibility problem. In JSR-223, the "context" binding is reserved for the ScriptContext object, so any script code that uses the variable "context" will be using the ScriptContext object - not the context Map. I'm not sure how to proceed from here.
>
> -Adrian
>
> On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>
>> Jacopo
>>
>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>
>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>
>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>
>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>
>>> // Groovy, JavaScript
>>> partyValue = script.entityOne("Party");
>>> if (partyValue)...
>>>
>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>
>>> -Adrian
>>>
>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>>
>>>>> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.
>>>> Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
>>>> If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.
>>>>
>>>>> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>>>>>
>>>> I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.
>>>>
>>>> Jacopo
>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>>
>>>>>>> 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?
>>>>>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>>>>>
>>>>>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>>>>>
>>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>>>>>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>>>>>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>>>>>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>>>>>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>>>>>
>>>>>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>> -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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

[Adrian Crum-3]

I was thinking of using _context. I know we try to stay away from
leading underscores as a general practice, but in this case I thought it
would make the replacement (and learning curve) easier.

-Adrian

On 3/6/2012 8:57 AM, Jacopo Cappellato wrote:

> I would be in favor of bulk renaming all the "context" variables in our scripts... maybe we could wait after the creation of the 12.04 release branch... but I would be in favor even if we do this earlier.
>
> Jacopo
>
> On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
>
>> Update: I added a generic ScriptEngine to the service engine in rev 1297323.
>>
>> I haven't updated screen widgets and mini-lang to use JSR-223 because there is a compatibility problem. In JSR-223, the "context" binding is reserved for the ScriptContext object, so any script code that uses the variable "context" will be using the ScriptContext object - not the context Map. I'm not sure how to proceed from here.
>>
>> -Adrian
>>
>> On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
>>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>>
>>> Jacopo
>>>
>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>
>>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>>
>>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>>
>>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>>
>>>> // Groovy, JavaScript
>>>> partyValue = script.entityOne("Party");
>>>> if (partyValue)...
>>>>
>>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>>>
>>>>>> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.
>>>>> Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
>>>>> If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.
>>>>>
>>>>>> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>>>>>>
>>>>> I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> 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?
>>>>>>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>>>>>>
>>>>>>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>>>>>>
>>>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>>>>>>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>>>>>>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>>>>>>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>>>>>>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>>>>>>
>>>>>>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>> -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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

[Scott Gray-2]

The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).

A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder

Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.

Regards
Scott

On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:

> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
> But I don't have a clear list at the moment so please do not consider my notes a blocker.
> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>
> Jacopo
>
> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>
>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>
>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>
>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>
>> // Groovy, JavaScript
>> partyValue = script.entityOne("Party");
>> if (partyValue)...
>>
>> In other words, have an object in the context that gives us the convenience of mini-language.
>>
>> -Adrian
>>
>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>
>>>> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.
>>> Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
>>> If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.
>>>
>>>> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>>>>
>>> I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.
>>>
>>> Jacopo
>>>
>>>> -Adrian
>>>>
>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>
>>>>>> 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?
>>>>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>>>>
>>>>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>>>>
>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>>>>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>>>>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>>>>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>>>>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>>>>
>>>>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>> -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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>

[Adrian Crum-3]

The EntityConditionBuilder class is a good example of how we can make
scripting more convenient.

Different scripting languages will have varying support for Java
classes. It was my hope that we could come up with a Java-based script
helper class that can be used by a variety of scripting languages that
can access Java objects.

I understand that there is an interest in Groovy in this community, but
other communities might prefer a different language. For example, Jython
and Ruby have sizable communities.

My motivation in in implementing JSR-223 is the same as my motivation to
implement internationalization/globalization years ago - to open up the
project to more users.

So, let's try to keep the big picture in mind. If we come up with a
scripting convenience, let's try to accommodate the most users with it.

-Adrian


On 3/6/2012 10:23 AM, Scott Gray wrote:

> The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).
>
> A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
> conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
>
> Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.
>
> Regards
> Scott
>
> On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
>
>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>
>> Jacopo
>>
>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>
>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>
>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>
>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>
>>> // Groovy, JavaScript
>>> partyValue = script.entityOne("Party");
>>> if (partyValue)...
>>>
>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>
>>> -Adrian
>>>
>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>>
>>>>> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.
>>>> Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
>>>> If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.
>>>>
>>>>> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>>>>>
>>>> I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.
>>>>
>>>> Jacopo
>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>>
>>>>>>> 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?
>>>>>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>>>>>
>>>>>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>>>>>
>>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>>>>>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>>>>>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>>>>>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>>>>>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>>>>>
>>>>>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>> -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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

[Scott Gray-2]

I'm not sure I follow what you're saying.  I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features.  

I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice.  I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating.

Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need.

Regards
Scott

On 7/03/2012, at 12:33 PM, Adrian Crum wrote:

> The EntityConditionBuilder class is a good example of how we can make scripting more convenient.
>
> Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects.
>
> I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities.
>
> My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users.
>
> So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it.
>
> -Adrian
>
>
> On 3/6/2012 10:23 AM, Scott Gray wrote:
>> The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).
>>
>> A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
>> conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
>>
>> Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.
>>
>> Regards
>> Scott
>>
>> On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
>>
>>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>>
>>> Jacopo
>>>
>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>
>>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>>
>>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>>
>>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>>
>>>> // Groovy, JavaScript
>>>> partyValue = script.entityOne("Party");
>>>> if (partyValue)...
>>>>
>>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>>>
>>>>>> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.
>>>>> Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
>>>>> If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.
>>>>>
>>>>>> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>>>>>>
>>>>> I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> 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?
>>>>>>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>>>>>>
>>>>>>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>>>>>>
>>>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>>>>>>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>>>>>>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>>>>>>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>>>>>>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>>>>>>
>>>>>>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>> -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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

[Adrian Crum-3]

Fair enough. Users of other scripting languages can adapt the code to
suit their language.

-Adrian

On 3/6/2012 11:49 PM, Scott Gray wrote:

> I'm not sure I follow what you're saying.  I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features.
>
> I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice.  I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating.
>
> Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need.
>
> Regards
> Scott
>
> On 7/03/2012, at 12:33 PM, Adrian Crum wrote:
>
>> The EntityConditionBuilder class is a good example of how we can make scripting more convenient.
>>
>> Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects.
>>
>> I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities.
>>
>> My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users.
>>
>> So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it.
>>
>> -Adrian
>>
>>
>> On 3/6/2012 10:23 AM, Scott Gray wrote:
>>> The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).
>>>
>>> A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
>>> conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
>>>
>>> Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.
>>>
>>> Regards
>>> Scott
>>>
>>> On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
>>>
>>>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>>>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>>>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>>
>>>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>>>
>>>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>>>
>>>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>>>
>>>>> // Groovy, JavaScript
>>>>> partyValue = script.entityOne("Party");
>>>>> if (partyValue)...
>>>>>
>>>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.
>>>>>> Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
>>>>>> If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.
>>>>>>
>>>>>>> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>>>>>>>
>>>>>> I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> 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?
>>>>>>>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>>>>>>>
>>>>>>>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>>>>>>>
>>>>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>>>>>>>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>>>>>>>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>>>>>>>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>>>>>>>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>>>>>>>
>>>>>>>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>> -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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

[Jacopo Cappellato-4]

Yes, I agree with the general strategy: OFBiz will be (or it is) flexible and ready to be used with alternative tools; our effort as a community will be that of "opening it up" and slimming it down instead of trying to include all the possible alternative tools in our package; and the work that Adrian is doing to enable OFBiz to JSR-223 is a good example in this direction because it provides a flexible mechanism to plug in different scripting languages by just dropping the (JSR-223 compliant) jar files of the language of preference in the classpath; of course this will be a generic/basic support (i.e. the generic/basic one provided by JSR-223) and if the user will want to implement a library of custom objects to better structure the work in the new script then it will be fine, but these classes will not find a way to OFBiz because they will be custom and because they will be useless if you don't plan to use that specific language.
In a similar way the community has chosen for the OFBiz applications a scripting language of choice (currently Groovy) and this is the reason we have some Groovy friendly classes (shipped ootb) that are used by our Groovy scripts.

Jacopo

On Mar 7, 2012, at 12:58 AM, Adrian Crum wrote:

> Fair enough. Users of other scripting languages can adapt the code to suit their language.
>
> -Adrian
>
> On 3/6/2012 11:49 PM, Scott Gray wrote:
>> I'm not sure I follow what you're saying.  I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features.
>>
>> I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice.  I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating.
>>
>> Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need.
>>
>> Regards
>> Scott
>>
>> On 7/03/2012, at 12:33 PM, Adrian Crum wrote:
>>
>>> The EntityConditionBuilder class is a good example of how we can make scripting more convenient.
>>>
>>> Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects.
>>>
>>> I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities.
>>>
>>> My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users.
>>>
>>> So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it.
>>>
>>> -Adrian
>>>
>>>
>>> On 3/6/2012 10:23 AM, Scott Gray wrote:
>>>> The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).
>>>>
>>>> A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
>>>> conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
>>>>
>>>> Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
>>>>
>>>>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>>>>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>>>>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>>>
>>>>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>>>>
>>>>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>>>>
>>>>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>>>>
>>>>>> // Groovy, JavaScript
>>>>>> partyValue = script.entityOne("Party");
>>>>>> if (partyValue)...
>>>>>>
>>>>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.
>>>>>>> Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
>>>>>>> If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.
>>>>>>>
>>>>>>>> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>>>>>>>>
>>>>>>> I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>>>>>>>>
>>>>>>>>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>>>>>>>>
>>>>>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>>>>>>>>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>>>>>>>>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>>>>>>>>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>>>>>>>>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>>>>>>>>
>>>>>>>>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>>> -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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

[Adrian Crum-3]

Since the "context" binding (variable) is used only in scripts run from
screen widgets, I was thinking we could rename it "widget" - which has
the added benefit of making operations on it more meaningful.

To summarize: service and event scripts return values via the "results"
binding, and screen widget scripts return values via the "widget" binding.

What do you think?

-Adrian

On 3/6/2012 9:17 AM, Adrian Crum wrote:

> I was thinking of using _context. I know we try to stay away from
> leading underscores as a general practice, but in this case I thought
> it would make the replacement (and learning curve) easier.
>
> -Adrian
>
> On 3/6/2012 8:57 AM, Jacopo Cappellato wrote:
>> I would be in favor of bulk renaming all the "context" variables in
>> our scripts... maybe we could wait after the creation of the 12.04
>> release branch... but I would be in favor even if we do this earlier.
>>
>> Jacopo
>>
>> On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
>>
>>> Update: I added a generic ScriptEngine to the service engine in rev
>>> 1297323.
>>>
>>> I haven't updated screen widgets and mini-lang to use JSR-223
>>> because there is a compatibility problem. In JSR-223, the "context"
>>> binding is reserved for the ScriptContext object, so any script code
>>> that uses the variable "context" will be using the ScriptContext
>>> object - not the context Map. I'm not sure how to proceed from here.
>>>
>>> -Adrian
>>>
>>> On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
>>>> This could work but I was thinking to something more like having
>>>> some "core" packages (like entity and service) always imported in
>>>> groovy scripts/services; or having the "delegator" and "dispatcher"
>>>> objects properly casted to their interfaces (to take advantage of
>>>> IDE autocompletion features); etc...
>>>> But I don't have a clear list at the moment so please do not
>>>> consider my notes a blocker.
>>>> I am working at a POC for a "best practice" Groovy service
>>>> implementation and this should end up with a "wish list" of
>>>> features I would like to have. Then we can discuss the best way to
>>>> achieve this.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>>
>>>>> If you don't mind, I would like to get all of the issues resolved
>>>>> during the design phase.
>>>>>
>>>>> I will wait for the private email to understand what you mean by a
>>>>> "secure" scripting package.
>>>>>
>>>>> What I was suggesting is a script utility object that can be put
>>>>> in the context so that all scripting languages can use it.
>>>>> Whatever methods you have in mind could be implemented in a
>>>>> generic way and reused. Personally, I would like to use something
>>>>> like:
>>>>>
>>>>> // Groovy, JavaScript
>>>>> partyValue = script.entityOne("Party");
>>>>> if (partyValue)...
>>>>>
>>>>> In other words, have an object in the context that gives us the
>>>>> convenience of mini-language.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> It seems to me if there is a security issue using Groovy, then
>>>>>>> there would be an issue using any scripting language.
>>>>>> Yes, but what we would bundle ootb would be a secured packaged
>>>>>> ready to run Groovy scripts in a "secure" way and already
>>>>>> packaged with hundreds of scripts.
>>>>>> If the user will add a new jar to support a different script (and
>>>>>> the user will also have to implement the custom scripts) then
>>>>>> this will be less secure but there isn't much we could do as we
>>>>>> delegate to JSR-223 the implementation of security.
>>>>>>
>>>>>>> Why can't we put the "friendly methods" in the context, so all
>>>>>>> scripting languages can use them?
>>>>>>>
>>>>>> I am not sure I understand what you are proposing (the method
>>>>>> would be language specific) but for now we can postpone this
>>>>>> discussion at when (if it will ever happen) we will discuss about
>>>>>> this approach.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> 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?
>>>>>>>> First of all, I apologize for having added my personal opinion
>>>>>>>> to those comments :-) but I thought that in this way it was
>>>>>>>> easier to exchange design ideas; the comments can actually be
>>>>>>>> removed.
>>>>>>>>
>>>>>>>> The reasons I think we could treat Groovy in a special way (but
>>>>>>>> I don't have a strong opinion on this) are:
>>>>>>>>
>>>>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are
>>>>>>>> required by all the existing scripts and by some other code
>>>>>>>> like the implementation of "Groovy service engine" and "Groovy
>>>>>>>> event handler") and so the dependency on Groovy will still be
>>>>>>>> there even if we run it with JSR-223
>>>>>>>> * the code to run Groovy in the special way is now all
>>>>>>>> contained in the ScriptUtil class and there are actually a few
>>>>>>>> lines of code to maintain for it
>>>>>>>> * keeping a custom way for Groovy has two main advantages that
>>>>>>>> are not currently used but I would like to consider in the
>>>>>>>> short term (and I don't think they are supported thru
>>>>>>>> JSR-223... but I am not sure):
>>>>>>>> ** security: I would like to restrict the JVM security settings
>>>>>>>> for dynamic Groovy snippets like ${groovy: ...}; I have some
>>>>>>>> concerns in this area that I will address in a separate email
>>>>>>>> soon; in this way we will "secure" the ootb system (packaged
>>>>>>>> with several groovy scripts and the groovy jars) but of course
>>>>>>>> if the user will add to it jars files for a new scripting
>>>>>>>> language (executed using JSR-223) then the security issue will
>>>>>>>> still be there, but at least the user will know about it
>>>>>>>> ** I would like to inject some OFBiz friendly methods to all
>>>>>>>> Groovy scripts, so that they can be used by Groovy scripts to
>>>>>>>> run services, use the delegator etc...
>>>>>>>>
>>>>>>>> We should also consider the impact on performance, even if the
>>>>>>>> best way to go is probably to run some performance tests on the
>>>>>>>> system running Groovy with current code and with the system
>>>>>>>> running Groovy using a custom method and then compare the results.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>> -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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

[Adrian Crum-3]

I finished my work on this integration in rev 1299924. We now have a
basic scripting framework that developers can extend by adding scripting
language engines. The framework includes a script helper class that is
based on Jacopo's DSL idea. Scripts can access the helper class using
the "ofbiz" variable.

There is still some work left to do to complete this task - various bits
of framework code that invoke scripts need to use the new ScriptUtil
class instead of whatever they are using now. Also, the JavaDocs are
incomplete. I will leave those tasks for others to complete.

As I mentioned previously, there is a name clash with the "context"
variable that might cause problems. I added a "widget" variable to take
its place, so scripts that reference "context" need to be changed to
reference "widget" instead. By the way, BSH uses the "script" variable
name for its own helper class - that's why we use the "ofbiz" variable
name. I'm sure we will encounter other surprises as this is built out.

-Adrian


On 3/11/2012 4:32 PM, Adrian Crum wrote:

> Since the "context" binding (variable) is used only in scripts run
> from screen widgets, I was thinking we could rename it "widget" -
> which has the added benefit of making operations on it more meaningful.
>
> To summarize: service and event scripts return values via the
> "results" binding, and screen widget scripts return values via the
> "widget" binding.
>
> What do you think?
>
> -Adrian
>
> On 3/6/2012 9:17 AM, Adrian Crum wrote:
>> I was thinking of using _context. I know we try to stay away from
>> leading underscores as a general practice, but in this case I thought
>> it would make the replacement (and learning curve) easier.
>>
>> -Adrian
>>
>> On 3/6/2012 8:57 AM, Jacopo Cappellato wrote:
>>> I would be in favor of bulk renaming all the "context" variables in
>>> our scripts... maybe we could wait after the creation of the 12.04
>>> release branch... but I would be in favor even if we do this earlier.
>>>
>>> Jacopo
>>>
>>> On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
>>>
>>>> Update: I added a generic ScriptEngine to the service engine in rev
>>>> 1297323.
>>>>
>>>> I haven't updated screen widgets and mini-lang to use JSR-223
>>>> because there is a compatibility problem. In JSR-223, the "context"
>>>> binding is reserved for the ScriptContext object, so any script
>>>> code that uses the variable "context" will be using the
>>>> ScriptContext object - not the context Map. I'm not sure how to
>>>> proceed from here.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
>>>>> This could work but I was thinking to something more like having
>>>>> some "core" packages (like entity and service) always imported in
>>>>> groovy scripts/services; or having the "delegator" and
>>>>> "dispatcher" objects properly casted to their interfaces (to take
>>>>> advantage of IDE autocompletion features); etc...
>>>>> But I don't have a clear list at the moment so please do not
>>>>> consider my notes a blocker.
>>>>> I am working at a POC for a "best practice" Groovy service
>>>>> implementation and this should end up with a "wish list" of
>>>>> features I would like to have. Then we can discuss the best way to
>>>>> achieve this.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>>>
>>>>>> If you don't mind, I would like to get all of the issues resolved
>>>>>> during the design phase.
>>>>>>
>>>>>> I will wait for the private email to understand what you mean by
>>>>>> a "secure" scripting package.
>>>>>>
>>>>>> What I was suggesting is a script utility object that can be put
>>>>>> in the context so that all scripting languages can use it.
>>>>>> Whatever methods you have in mind could be implemented in a
>>>>>> generic way and reused. Personally, I would like to use something
>>>>>> like:
>>>>>>
>>>>>> // Groovy, JavaScript
>>>>>> partyValue = script.entityOne("Party");
>>>>>> if (partyValue)...
>>>>>>
>>>>>> In other words, have an object in the context that gives us the
>>>>>> convenience of mini-language.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> It seems to me if there is a security issue using Groovy, then
>>>>>>>> there would be an issue using any scripting language.
>>>>>>> Yes, but what we would bundle ootb would be a secured packaged
>>>>>>> ready to run Groovy scripts in a "secure" way and already
>>>>>>> packaged with hundreds of scripts.
>>>>>>> If the user will add a new jar to support a different script
>>>>>>> (and the user will also have to implement the custom scripts)
>>>>>>> then this will be less secure but there isn't much we could do
>>>>>>> as we delegate to JSR-223 the implementation of security.
>>>>>>>
>>>>>>>> Why can't we put the "friendly methods" in the context, so all
>>>>>>>> scripting languages can use them?
>>>>>>>>
>>>>>>> I am not sure I understand what you are proposing (the method
>>>>>>> would be language specific) but for now we can postpone this
>>>>>>> discussion at when (if it will ever happen) we will discuss
>>>>>>> about this approach.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>> First of all, I apologize for having added my personal opinion
>>>>>>>>> to those comments :-) but I thought that in this way it was
>>>>>>>>> easier to exchange design ideas; the comments can actually be
>>>>>>>>> removed.
>>>>>>>>>
>>>>>>>>> The reasons I think we could treat Groovy in a special way
>>>>>>>>> (but I don't have a strong opinion on this) are:
>>>>>>>>>
>>>>>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are
>>>>>>>>> required by all the existing scripts and by some other code
>>>>>>>>> like the implementation of "Groovy service engine" and "Groovy
>>>>>>>>> event handler") and so the dependency on Groovy will still be
>>>>>>>>> there even if we run it with JSR-223
>>>>>>>>> * the code to run Groovy in the special way is now all
>>>>>>>>> contained in the ScriptUtil class and there are actually a few
>>>>>>>>> lines of code to maintain for it
>>>>>>>>> * keeping a custom way for Groovy has two main advantages that
>>>>>>>>> are not currently used but I would like to consider in the
>>>>>>>>> short term (and I don't think they are supported thru
>>>>>>>>> JSR-223... but I am not sure):
>>>>>>>>> ** security: I would like to restrict the JVM security
>>>>>>>>> settings for dynamic Groovy snippets like ${groovy: ...}; I
>>>>>>>>> have some concerns in this area that I will address in a
>>>>>>>>> separate email soon; in this way we will "secure" the ootb
>>>>>>>>> system (packaged with several groovy scripts and the groovy
>>>>>>>>> jars) but of course if the user will add to it jars files for
>>>>>>>>> a new scripting language (executed using JSR-223) then the
>>>>>>>>> security issue will still be there, but at least the user will
>>>>>>>>> know about it
>>>>>>>>> ** I would like to inject some OFBiz friendly methods to all
>>>>>>>>> Groovy scripts, so that they can be used by Groovy scripts to
>>>>>>>>> run services, use the delegator etc...
>>>>>>>>>
>>>>>>>>> We should also consider the impact on performance, even if the
>>>>>>>>> best way to go is probably to run some performance tests on
>>>>>>>>> the system running Groovy with current code and with the
>>>>>>>>> system running Groovy using a custom method and then compare
>>>>>>>>> the results.
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>>> -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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

[Adrian Crum-3]

Now that we have the basic framework working, we can explore this idea
further.

Right now we have ScriptHelper object available through the key "ofbiz".
The object is retrieved from a single ScriptHelperFactory  instance.

If we made the getInstance method of ScriptHelperFactory return a
java.lang.Object, then any number of factories could be used to add any
number of custom helper objects to the bindings.

-Adrian

On 3/6/2012 11:49 PM, Scott Gray wrote:

> I'm not sure I follow what you're saying.  I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features.
>
> I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice.  I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating.
>
> Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need.
>
> Regards
> Scott
>
> On 7/03/2012, at 12:33 PM, Adrian Crum wrote:
>
>> The EntityConditionBuilder class is a good example of how we can make scripting more convenient.
>>
>> Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects.
>>
>> I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities.
>>
>> My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users.
>>
>> So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it.
>>
>> -Adrian
>>
>>
>> On 3/6/2012 10:23 AM, Scott Gray wrote:
>>> The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway).
>>>
>>> A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables:
>>> conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
>>>
>>> Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag.
>>>
>>> Regards
>>> Scott
>>>
>>> On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
>>>
>>>> This could work but I was thinking to something more like having some "core" packages (like entity and service) always imported in groovy scripts/services; or having the "delegator" and "dispatcher" objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc...
>>>> But I don't have a clear list at the moment so please do not consider my notes a blocker.
>>>> I am working at a POC for a "best practice" Groovy service implementation and this should end up with a "wish list" of features I would like to have. Then we can discuss the best way to achieve this.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>>>>
>>>>> If you don't mind, I would like to get all of the issues resolved during the design phase.
>>>>>
>>>>> I will wait for the private email to understand what you mean by a "secure" scripting package.
>>>>>
>>>>> What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like:
>>>>>
>>>>> // Groovy, JavaScript
>>>>> partyValue = script.entityOne("Party");
>>>>> if (partyValue)...
>>>>>
>>>>> In other words, have an object in the context that gives us the convenience of mini-language.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>>>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language.
>>>>>> Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a "secure" way and already packaged with hundreds of scripts.
>>>>>> If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security.
>>>>>>
>>>>>>> Why can't we put the "friendly methods" in the context, so all scripting languages can use them?
>>>>>>>
>>>>>> I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> 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?
>>>>>>>> First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed.
>>>>>>>>
>>>>>>>> The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are:
>>>>>>>>
>>>>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of "Groovy service engine" and "Groovy event handler") and so the dependency on Groovy will still be there even if we run it with JSR-223
>>>>>>>> * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it
>>>>>>>> * keeping a custom way for Groovy has two main advantages that are not currently used but I would like to consider in the short term (and I don't think they are supported thru JSR-223... but I am not sure):
>>>>>>>> ** security: I would like to restrict the JVM security settings for dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this area that I will address in a separate email soon; in this way we will "secure" the ootb system (packaged with several groovy scripts and the groovy jars) but of course if the user will add to it jars files for a new scripting language (executed using JSR-223) then the security issue will still be there, but at least the user will know about it
>>>>>>>> ** I would like to inject some OFBiz friendly methods to all Groovy scripts, so that they can be used by Groovy scripts to run services, use the delegator etc...
>>>>>>>>
>>>>>>>> We should also consider the impact on performance, even if the best way to go is probably to run some performance tests on the system running Groovy with current code and with the system running Groovy using a custom method and then compare the results.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>> -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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>