It seems to me if there is a security issue using Groovy, then there
would be an issue using any scripting language.
Why can't we put the "friendly methods" in the context, so all scripting
languages can use them?
-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
