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