Groovy and ScriptUtil: pragmatic consideration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Groovy and ScriptUtil: pragmatic consideration

Jacques Le Roux
Administrator
For https://issues.apache.org/jira/browse/OFBIZ-4882 I stumbled upon this with OOTB setting for ScriptUtil

---- exception report ----------------------------------------------------------
Error running script at location [component://order/webapp/ordermgr/WEB-INF/actions/entry/catalog/ProductSummary.groovy]:
javax.script.ScriptException: java.lang.ClassCastException: org.ofbiz.base.util.UtilMi
sc$SimpleMap cannot be cast to java.lang.String
Exception: javax.script.ScriptException
Message: java.lang.ClassCastException: org.ofbiz.base.util.UtilMisc$SimpleMap cannot be cast to java.lang.String
---- cause ---------------------------------------------------------------------
Exception: java.lang.ClassCastException
Message: org.ofbiz.base.util.UtilMisc$SimpleMap cannot be cast to java.lang.String
---- stack trace ---------------------------------------------------------------
java.lang.ClassCastException: org.ofbiz.base.util.UtilMisc$SimpleMap cannot be cast to java.lang.String
org.ofbiz.base.util.UtilMisc.toMap(UtilMisc.java:202)
org.ofbiz.entity.GenericDelegator.findByAnd(GenericDelegator.java:1692)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSite.invoke(PojoMetaMethodSite.java:189)
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:53)
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
Script12.run(Script12.groovy:137)
org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:320)
org.codehaus.groovy.jsr223.GroovyCompiledScript.eval(GroovyCompiledScript.java:41)
org.ofbiz.base.util.ScriptUtil.executeScript(ScriptUtil.java:298)

I then used the trick to rather use the old GroovyUtil.runScriptAtLocation()

And got this

---- runtime exception report --------------------------------------------------
Error running script at location [component://order/webapp/ordermgr/WEB-INF/actions/entry/catalog/ProductSummary.groovy]:
java.lang.ClassCastException: org.ofbiz.base.util.UtilMisc$SimpleMap cannot be cast to
 java.lang.String
Exception: java.lang.ClassCastException
Message: org.ofbiz.base.util.UtilMisc$SimpleMap cannot be cast to java.lang.String
---- stack trace ---------------------------------------------------------------
java.lang.ClassCastException: org.ofbiz.base.util.UtilMisc$SimpleMap cannot be cast to java.lang.String
org.ofbiz.base.util.UtilMisc.toMap(UtilMisc.java:202)
org.ofbiz.entity.GenericDelegator.findByAnd(GenericDelegator.java:1692)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSite.invoke(PojoMetaMethodSite.java:189)
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:53)
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
ProductSummary.run(ProductSummary.groovy:137)


I think you see the difference when it comes to debug errors in script between

Script12.run(Script12.groovy:137)
and
ProductSummary.run(ProductSummary.groovy:137)

Of course ProductSummary.groovy name showed also in the 1st stack trace, but not the line number.

I wonder if OOTB we should not rather use GroovyUtil.runScriptAtLocation(). In term ofdebugging executeScript() is really hard to
follow. If someone wants to implment it's own version (ie not using Groovy) then s/he could still use executeScript()

Opinions?

Jacques
Reply | Threaded
Open this post in threaded view
|

Re: Groovy and ScriptUtil: pragmatic consideration

Adam Heath-2
On 06/03/2012 07:47 AM, Jacques Le Roux wrote:

> For https://issues.apache.org/jira/browse/OFBIZ-4882 I stumbled upon
> this with OOTB setting for ScriptUtil
>
> ---- exception report
> ----------------------------------------------------------
> Error running script at location
> [component://order/webapp/ordermgr/WEB-INF/actions/entry/catalog/ProductSummary.groovy]:
> javax.script.ScriptException: java.lang.ClassCastException:
> org.ofbiz.base.util.UtilMi
> sc$SimpleMap cannot be cast to java.lang.String
> Exception: javax.script.ScriptException
> Message: java.lang.ClassCastException:
> org.ofbiz.base.util.UtilMisc$SimpleMap cannot be cast to java.lang.String
> ---- cause
> ---------------------------------------------------------------------
> Exception: java.lang.ClassCastException
> Message: org.ofbiz.base.util.UtilMisc$SimpleMap cannot be cast to
> java.lang.String
> ---- stack trace
> ---------------------------------------------------------------
> java.lang.ClassCastException: org.ofbiz.base.util.UtilMisc$SimpleMap
> cannot be cast to java.lang.String
> org.ofbiz.base.util.UtilMisc.toMap(UtilMisc.java:202)
> org.ofbiz.entity.GenericDelegator.findByAnd(GenericDelegator.java:1692)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> java.lang.reflect.Method.invoke(Method.java:597)
> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSite.invoke(PojoMetaMethodSite.java:189)
>
> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:53)
>
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
>
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
>
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
>
> Script12.run(Script12.groovy:137)
> org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:320)
>
> org.codehaus.groovy.jsr223.GroovyCompiledScript.eval(GroovyCompiledScript.java:41)
>
> org.ofbiz.base.util.ScriptUtil.executeScript(ScriptUtil.java:298)
>
> I then used the trick to rather use the old
> GroovyUtil.runScriptAtLocation()
>
> And got this
>
> ---- runtime exception report
> --------------------------------------------------
> Error running script at location
> [component://order/webapp/ordermgr/WEB-INF/actions/entry/catalog/ProductSummary.groovy]:
> java.lang.ClassCastException: org.ofbiz.base.util.UtilMisc$SimpleMap
> cannot be cast to
> java.lang.String
> Exception: java.lang.ClassCastException
> Message: org.ofbiz.base.util.UtilMisc$SimpleMap cannot be cast to
> java.lang.String
> ---- stack trace
> ---------------------------------------------------------------
> java.lang.ClassCastException: org.ofbiz.base.util.UtilMisc$SimpleMap
> cannot be cast to java.lang.String
> org.ofbiz.base.util.UtilMisc.toMap(UtilMisc.java:202)
> org.ofbiz.entity.GenericDelegator.findByAnd(GenericDelegator.java:1692)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> java.lang.reflect.Method.invoke(Method.java:597)
> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSite.invoke(PojoMetaMethodSite.java:189)
>
> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:53)
>
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
>
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
>
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
>
> ProductSummary.run(ProductSummary.groovy:137)
>
>
> I think you see the difference when it comes to debug errors in script
> between
>
> Script12.run(Script12.groovy:137)
> and
> ProductSummary.run(ProductSummary.groovy:137)

+1.  Ideally, it could even encode the full path to the file into the
classname(not the filename), like this:

home.adam.code.ofbiz.webapp.WEB%2DINF.actions.ProductSummary%2Egroovy(ProductSummary.groovy:137)

(package name shortened)

The serviceengine wrapping stuff that made use of some smaller parts of
webslinger had this kind of encoding going on; but it turned each
service call into a new class.  For the above, we already have a unique
class, so it's not that much of a bigger loss.

> Of course ProductSummary.groovy name showed also in the 1st stack trace,
> but not the line number.
>
> I wonder if OOTB we should not rather use
> GroovyUtil.runScriptAtLocation(). In term ofdebugging executeScript() is
> really hard to follow. If someone wants to implment it's own version (ie
> not using Groovy) then s/he could still use executeScript()
>
> Opinions?
>
> Jacques

Reply | Threaded
Open this post in threaded view
|

Re: Groovy and ScriptUtil: pragmatic consideration

Jacopo Cappellato-4
In reply to this post by Jacques Le Roux

On Jun 3, 2012, at 2:47 PM, Jacques Le Roux wrote:

> I wonder if OOTB we should not rather use GroovyUtil.runScriptAtLocation(). In term ofdebugging executeScript() is really hard to follow. If someone wants to implment it's own version (ie not using Groovy) then s/he could still use executeScript()
>
> Opinions?
>
> Jacques

+1

Enabling Groovy specific processor will also enable the usage of debuggers; I already mentioned this some weeks ago and Adrian agreed in temporarily enabling Groovy specific processing.

Jacopo
Reply | Threaded
Open this post in threaded view
|

Re: Groovy and ScriptUtil: pragmatic consideration

Adrian Crum-3
On 6/4/2012 6:54 AM, Jacopo Cappellato wrote:

> On Jun 3, 2012, at 2:47 PM, Jacques Le Roux wrote:
>
>> I wonder if OOTB we should not rather use GroovyUtil.runScriptAtLocation(). In term ofdebugging executeScript() is really hard to follow. If someone wants to implment it's own version (ie not using Groovy) then s/he could still use executeScript()
>>
>> Opinions?
>>
>> Jacques
> +1
>
> Enabling Groovy specific processor will also enable the usage of debuggers; I already mentioned this some weeks ago and Adrian agreed in temporarily enabling Groovy specific processing.

Do whatever it takes to make the various script engines work. Ideally,
we should not need to write language-specific code, but we don't live in
an ideal world.

-Adrian

Reply | Threaded
Open this post in threaded view
|

Re: Groovy and ScriptUtil: pragmatic consideration

Jacques Le Roux
Administrator
In reply to this post by Jacopo Cappellato-4
Done at http://svn.apache.org/viewvc?rev=1345840&view=rev

Sorry Adrian, due to a VPN blocking my msg it stayed in my local box since this morning early

Jacques

From: "Jacopo Cappellato" <[hidden email]>

> On Jun 3, 2012, at 2:47 PM, Jacques Le Roux wrote:
>
>> I wonder if OOTB we should not rather use GroovyUtil.runScriptAtLocation(). In term ofdebugging executeScript() is really hard to
>> follow. If someone wants to implment it's own version (ie not using Groovy) then s/he could still use executeScript()
>>
>> Opinions?
>>
>> Jacques
>
> +1
>
> Enabling Groovy specific processor will also enable the usage of debuggers; I already mentioned this some weeks ago and Adrian
> agreed in temporarily enabling Groovy specific processing.
>
> Jacopo