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
