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
>>>
>>>
>>>
