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