OFBiz › OFBiz - Dev

Groovy issues

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

mrisaliti@libero.it

Groovy issues

Hi to all,

at the moment there are only a few scripts that use Groovy but during my first tests I have seen a little issue.
If you try to go on Edit Product Features (https://demo.hotwaxmedia.com/catalog/control/EditProductFeatures?productId=GZ-1006) and then refresh the page then it you will receive the following error:

Expression productFeatureAndAppls is undefined on line 41, column 20 in component://product/webapp/catalog/product/EditProductFeatures.ftl. The problematic instruction: ---------- ==> list productFeatureAndAppls as productFeatureAndAppl [on line 41, column 13 in component://product/webapp/catalog/product/EditProductFeatures.ftl] ---------- Java backtrace for programmers: ---------- freemarker.core.InvalidReferenceException: Expression productFeatureAndAppls is undefined on line 41, column 20 in component://product/webapp/catalog/product/EditProductFeatures.ftl. at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:124) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:93) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.Environment.process(Environment.java:176) at org.ofbiz.base.util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:198) at org.ofbiz.base.util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:163) at

something like the groovy script does not insert nothing in the context map.
Doing some print into the groovy script I saw that it was run and inserted into the context but the ftl file does not see it.

It seems to me that is something is not working correctly.
So it's better to look at this error before continue to convert the scripts from bsh to groovy.
It would be great if someone can help me on how to solve this issue.

Thanks
Marco

Rashko Rejmer

Re: Groovy issues

Hi,
I have also noticed this issue in form widget. When I am refreshing a
screen, ones groovy puts into the context the list variable expected by
form widget, ones not.

Regards,
Rashko Rejmer

On Mon, 2008-05-26 at 13:52 +0200, [hidden email] wrote:

> Hi to all,
>
> at the moment there are only a few scripts that use Groovy but during my first tests I have seen a little issue.
> If you try to go on Edit Product Features (https://demo.hotwaxmedia.com/catalog/control/EditProductFeatures?productId=GZ-1006) and then refresh the page then it you will receive the following error:
>
> Expression productFeatureAndAppls is undefined on line 41, column 20 in component://product/webapp/catalog/product/EditProductFeatures.ftl. The problematic instruction: ---------- ==> list productFeatureAndAppls as productFeatureAndAppl [on line 41, column 13 in component://product/webapp/catalog/product/EditProductFeatures.ftl] ---------- Java backtrace for programmers: ---------- freemarker.core.InvalidReferenceException: Expression productFeatureAndAppls is undefined on line 41, column 20 in component://product/webapp/catalog/product/EditProductFeatures.ftl. at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:124) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:93) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.Environment.process(Environment.java:176) at org.ofbiz.base.util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:198) at org.ofbiz.base.util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:163) at
>
> something like the groovy script does not insert nothing in the context map.
> Doing some print into the groovy script I saw that it was run and inserted into the context but the ftl file does not see it.
>
> It seems to me that is something is not working correctly.
> So it's better to look at this error before continue to convert the scripts from bsh to groovy.
> It would be great if someone can help me on how to solve this issue.
>
> Thanks
> Marco
>
>
>
>
>

David E Jones

Re: Groovy issues

In reply to this post by mrisaliti@libero.it

A quick look at the GroovyUtil.java file revealed why this is
happening. I apologize for not reviewing this better initially.

Just as with BeanShell it looks like the way you run groovy scripts is
a little backwards and there appears to be no thread-safe way to cache
a parsed script and run it from the cache.

Someone please prove me wrong before I go ask/complain on the groovy
mailing lists... there's got to be a way to do this!

For now I've implemented a simple variation that just caches the
script text so at least we're not reading from the FS over and over.
The performance is okay with this (about 10-20ms to parse and run a
script), but I'm sure with a pre-parsed script it would be a lot better.

See SVN rev 660228 for more info.

If no one beats me to it I'll look at this more later... outta time
for now (or about 1.5hrs in the red... running late ;) ).

-David

On May 26, 2008, at 5:52 AM, [hidden email] wrote:

> Hi to all,
>
> at the moment there are only a few scripts that use Groovy but
> during my first tests I have seen a little issue.
> If you try to go on Edit Product Features (https://demo.hotwaxmedia.com/catalog/control/EditProductFeatures?productId=GZ-1006
> ) and then refresh the page then it you will receive the following
> error:
>
> Expression productFeatureAndAppls is undefined on line 41, column 20
> in component://product/webapp/catalog/product/
> EditProductFeatures.ftl. The problematic instruction: ---------- ==>
> list productFeatureAndAppls as productFeatureAndAppl [on line 41,
> column 13 in component://product/webapp/catalog/product/
> EditProductFeatures.ftl] ---------- Java backtrace for programmers:
> ---------- freemarker.core.InvalidReferenceException: Expression
> productFeatureAndAppls is undefined on line 41, column 20 in
> component://product/webapp/catalog/product/EditProductFeatures.ftl.
> at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:
> 124) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:93)
> at freemarker.core.Environment.visit(Environment.java:196) at
> freemarker.core.MixedContent.accept(MixedContent.java:92) at
> freemarker.core.Environment.visit(Environment.java:196) at
> freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79) at
> freemarker.core.Environment.visit(Environment.java:196) at
> freemarker.core.MixedContent.accept(MixedContent.java:92) at
> freemarker.core.Environment.visit(Environment.java:196) at
> freemarker.core.Environment.process(Environment.java:176) at
> org
> .ofbiz
> .base
> .util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
> 198) at
> org
> .ofbiz
> .base
> .util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
> 163) at
>
> something like the groovy script does not insert nothing in the
> context map.
> Doing some print into the groovy script I saw that it was run and
> inserted into the context but the ftl file does not see it.
>
> It seems to me that is something is not working correctly.
> So it's better to look at this error before continue to convert the
> scripts from bsh to groovy.
> It would be great if someone can help me on how to solve this issue.
>
> Thanks
> Marco
>
>
>
>
>

Adrian Crum-2

Re: Groovy issues

David,

I just spent some time looking through the Groovy source code, and you're right - there is no thread-safe way to cache compiled scripts. The Script, GroovyShell, and supporting classes all hold instances of context variables (properties).

There is a chance we can pull something off by digging deeper into their source code and see if we can derive our own thread-safe classes from some of their code. Let me know if you think it is worth pursuing.

-Adrian

David E Jones <[hidden email]> wrote:
A quick look at the GroovyUtil.java file revealed why this is
happening. I apologize for not reviewing this better initially.

Just as with BeanShell it looks like the way you run groovy scripts is
a little backwards and there appears to be no thread-safe way to cache
a parsed script and run it from the cache.

Someone please prove me wrong before I go ask/complain on the groovy
mailing lists... there's got to be a way to do this!

For now I've implemented a simple variation that just caches the
script text so at least we're not reading from the FS over and over.
The performance is okay with this (about 10-20ms to parse and run a
script), but I'm sure with a pre-parsed script it would be a lot better.

See SVN rev 660228 for more info.

If no one beats me to it I'll look at this more later... outta time
for now (or about 1.5hrs in the red... running late ;) ).

-David

On May 26, 2008, at 5:52 AM, [hidden email] wrote:

risalitim@gmail.com

Re: Groovy issues

In reply to this post by David E Jones

Great thanks David for your quick fix, now it's working well.
Your new groovy example are very more reducing code and understandable
for dot sintax.
Did you think I can proceed now to continue the conversion of some bsh
scritps to groovy ?

Thanks
Marco

Il giorno 26/mag/08, alle ore 18:57, David E Jones ha scritto:

>
> A quick look at the GroovyUtil.java file revealed why this is
> happening. I apologize for not reviewing this better initially.
>
> Just as with BeanShell it looks like the way you run groovy scripts
> is a little backwards and there appears to be no thread-safe way to
> cache a parsed script and run it from the cache.
>
> Someone please prove me wrong before I go ask/complain on the groovy
> mailing lists... there's got to be a way to do this!
>
> For now I've implemented a simple variation that just caches the
> script text so at least we're not reading from the FS over and over.
> The performance is okay with this (about 10-20ms to parse and run a
> script), but I'm sure with a pre-parsed script it would be a lot
> better.
>
> See SVN rev 660228 for more info.
>
> If no one beats me to it I'll look at this more later... outta time
> for now (or about 1.5hrs in the red... running late ;) ).
>
> -David
>
>
> On May 26, 2008, at 5:52 AM, [hidden email] wrote:
>
>> Hi to all,
>>
>> at the moment there are only a few scripts that use Groovy but
>> during my first tests I have seen a little issue.
>> If you try to go on Edit Product Features (https://demo.hotwaxmedia.com/catalog/control/EditProductFeatures?productId=GZ-1006
>> ) and then refresh the page then it you will receive the following
>> error:
>>
>> Expression productFeatureAndAppls is undefined on line 41, column
>> 20 in component://product/webapp/catalog/product/
>> EditProductFeatures.ftl. The problematic instruction: ----------
>> ==> list productFeatureAndAppls as productFeatureAndAppl [on line
>> 41, column 13 in component://product/webapp/catalog/product/
>> EditProductFeatures.ftl] ---------- Java backtrace for programmers:
>> ---------- freemarker.core.InvalidReferenceException: Expression
>> productFeatureAndAppls is undefined on line 41, column 20 in
>> component://product/webapp/catalog/product/EditProductFeatures.ftl.
>> at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:
>> 124) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:93)
>> at freemarker.core.Environment.visit(Environment.java:196) at
>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>> freemarker.core.Environment.visit(Environment.java:196) at
>> freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79)
>> at freemarker.core.Environment.visit(Environment.java:196) at
>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>> freemarker.core.Environment.visit(Environment.java:196) at
>> freemarker.core.Environment.process(Environment.java:176) at
>> org
>> .ofbiz
>> .base
>> .util
>> .template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>> 198) at
>> org
>> .ofbiz
>> .base
>> .util
>> .template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>> 163) at
>>
>> something like the groovy script does not insert nothing in the
>> context map.
>> Doing some print into the groovy script I saw that it was run and
>> inserted into the context but the ftl file does not see it.
>>
>> It seems to me that is something is not working correctly.
>> So it's better to look at this error before continue to convert the
>> scripts from bsh to groovy.
>> It would be great if someone can help me on how to solve this issue.
>>
>> Thanks
>> Marco
>>
>>
>>
>>
>>
>

David E Jones

Re: Groovy issues

Yes, I'd say please proceed (according to what has been discussed and
voted on). Small technical issues like this are not a big problem and
are generally relatively easy to fix (if only everything were so
easy! ;) ).

-David

On May 26, 2008, at 2:23 PM, [hidden email] wrote:

> Great thanks David for your quick fix, now it's working well.
> Your new groovy example are very more reducing code and
> understandable for dot sintax.
> Did you think I can proceed now to continue the conversion of some
> bsh scritps to groovy ?
>
> Thanks
> Marco
>
>
> Il giorno 26/mag/08, alle ore 18:57, David E Jones ha scritto:
>
>>
>> A quick look at the GroovyUtil.java file revealed why this is
>> happening. I apologize for not reviewing this better initially.
>>
>> Just as with BeanShell it looks like the way you run groovy scripts
>> is a little backwards and there appears to be no thread-safe way to
>> cache a parsed script and run it from the cache.
>>
>> Someone please prove me wrong before I go ask/complain on the
>> groovy mailing lists... there's got to be a way to do this!
>>
>> For now I've implemented a simple variation that just caches the
>> script text so at least we're not reading from the FS over and
>> over. The performance is okay with this (about 10-20ms to parse and
>> run a script), but I'm sure with a pre-parsed script it would be a
>> lot better.
>>
>> See SVN rev 660228 for more info.
>>
>> If no one beats me to it I'll look at this more later... outta time
>> for now (or about 1.5hrs in the red... running late ;) ).
>>
>> -David
>>
>>
>> On May 26, 2008, at 5:52 AM, [hidden email] wrote:
>>
>>> Hi to all,
>>>
>>> at the moment there are only a few scripts that use Groovy but
>>> during my first tests I have seen a little issue.
>>> If you try to go on Edit Product Features (https://demo.hotwaxmedia.com/catalog/control/EditProductFeatures?productId=GZ-1006
>>> ) and then refresh the page then it you will receive the following
>>> error:
>>>
>>> Expression productFeatureAndAppls is undefined on line 41, column
>>> 20 in component://product/webapp/catalog/product/
>>> EditProductFeatures.ftl. The problematic instruction: ----------
>>> ==> list productFeatureAndAppls as productFeatureAndAppl [on line
>>> 41, column 13 in component://product/webapp/catalog/product/
>>> EditProductFeatures.ftl] ---------- Java backtrace for
>>> programmers: ---------- freemarker.core.InvalidReferenceException:
>>> Expression productFeatureAndAppls is undefined on line 41, column
>>> 20 in component://product/webapp/catalog/product/
>>> EditProductFeatures.ftl. at
>>> freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:
>>> 124) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:
>>> 93) at freemarker.core.Environment.visit(Environment.java:196) at
>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>> freemarker.core.Environment.visit(Environment.java:196) at
>>> freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79)
>>> at freemarker.core.Environment.visit(Environment.java:196) at
>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>> freemarker.core.Environment.visit(Environment.java:196) at
>>> freemarker.core.Environment.process(Environment.java:176) at
>>> org
>>> .ofbiz
>>> .base
>>> .util
>>> .template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>> 198) at
>>> org
>>> .ofbiz
>>> .base
>>> .util
>>> .template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>> 163) at
>>>
>>> something like the groovy script does not insert nothing in the
>>> context map.
>>> Doing some print into the groovy script I saw that it was run and
>>> inserted into the context but the ftl file does not see it.
>>>
>>> It seems to me that is something is not working correctly.
>>> So it's better to look at this error before continue to convert
>>> the scripts from bsh to groovy.
>>> It would be great if someone can help me on how to solve this issue.
>>>
>>> Thanks
>>> Marco
>>>
>>>
>>>
>>>
>>>
>>
>

David E Jones

Re: Groovy issues

In reply to this post by Adrian Crum-2

Yes, I think this is definitely something worth pursuing. Groovy
parses and runs scripts way faster than BeanShell, but my guess is
that we could increase efficiency and reduce execution time quite a
bit by running scripts that are parsed in advance.

The 10-20ms times I was seeing for running these scripts are fairly
high, but they included a number of database interactions which also
take a LOT of time, generally way more than parsing and running the
script itself. I guess a good test would be to write a simple scripts
that does a number of operations but no database interaction so that
the load is mostly on parsing the script before running it. Then we
would have a better idea of the parsing overhead time. I'm guess that
parsing and running most scripts we use is WAY under 1ms, which is a
lot less than the time to do even a single database query, so doing
this will have an impact on the app server CPU load, but probably not
much on overall application/system response times and performance.

In general it seems like Groovy (and BeanShell and others are this way
too...) is written to support running multiple scripts within the same
context whereas we need to run the same scripts over and over many
times with different contexts.

The first step should probably be a question on a Groovy mailing list
to see if anyone has ideas about how to do this with the existing
version (1.5) or ideas about how such a thing might be added and if
there is community interest in it.

Would you like to do that Adrian, or would you prefer that I do it? In
other words, I'm totally fine with you doing it but if you don't want
to I'm happy to.

-David

On May 26, 2008, at 12:32 PM, Adrian Crum wrote:

> David,
>
> I just spent some time looking through the Groovy source code, and
> you're right - there is no thread-safe way to cache compiled
> scripts. The Script, GroovyShell, and supporting classes all hold
> instances of context variables (properties).
>
> There is a chance we can pull something off by digging deeper into
> their source code and see if we can derive our own thread-safe
> classes from some of their code. Let me know if you think it is
> worth pursuing.
>
> -Adrian
>
>
> David E Jones <[hidden email]> wrote:
> A quick look at the GroovyUtil.java file revealed why this is
> happening. I apologize for not reviewing this better initially.
>
> Just as with BeanShell it looks like the way you run groovy scripts is
> a little backwards and there appears to be no thread-safe way to cache
> a parsed script and run it from the cache.
>
> Someone please prove me wrong before I go ask/complain on the groovy
> mailing lists... there's got to be a way to do this!
>
> For now I've implemented a simple variation that just caches the
> script text so at least we're not reading from the FS over and over.
> The performance is okay with this (about 10-20ms to parse and run a
> script), but I'm sure with a pre-parsed script it would be a lot
> better.
>
> See SVN rev 660228 for more info.
>
> If no one beats me to it I'll look at this more later... outta time
> for now (or about 1.5hrs in the red... running late ;) ).
>
> -David
>
>
> On May 26, 2008, at 5:52 AM, [hidden email] wrote:
>
>> Hi to all,
>>
>> at the moment there are only a few scripts that use Groovy but
>> during my first tests I have seen a little issue.
>> If you try to go on Edit Product Features (https://demo.hotwaxmedia.com/catalog/control/EditProductFeatures?productId=GZ-1006
>> ) and then refresh the page then it you will receive the following
>> error:
>>
>> Expression productFeatureAndAppls is undefined on line 41, column 20
>> in component://product/webapp/catalog/product/
>> EditProductFeatures.ftl. The problematic instruction: ---------- ==>
>> list productFeatureAndAppls as productFeatureAndAppl [on line 41,
>> column 13 in component://product/webapp/catalog/product/
>> EditProductFeatures.ftl] ---------- Java backtrace for programmers:
>> ---------- freemarker.core.InvalidReferenceException: Expression
>> productFeatureAndAppls is undefined on line 41, column 20 in
>> component://product/webapp/catalog/product/EditProductFeatures.ftl.
>> at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:
>> 124) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:93)
>> at freemarker.core.Environment.visit(Environment.java:196) at
>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>> freemarker.core.Environment.visit(Environment.java:196) at
>> freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79) at
>> freemarker.core.Environment.visit(Environment.java:196) at
>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>> freemarker.core.Environment.visit(Environment.java:196) at
>> freemarker.core.Environment.process(Environment.java:176) at
>> org
>> .ofbiz
>> .base
>> .util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>> 198) at
>> org
>> .ofbiz
>> .base
>> .util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>> 163) at
>>
>> something like the groovy script does not insert nothing in the
>> context map.
>> Doing some print into the groovy script I saw that it was run and
>> inserted into the context but the ftl file does not see it.
>>
>> It seems to me that is something is not working correctly.
>> So it's better to look at this error before continue to convert the
>> scripts from bsh to groovy.
>> It would be great if someone can help me on how to solve this issue.
>>
>> Thanks
>> Marco
>>
>>
>>
>>
>>
>
>
>

Adrian Crum

Re: Groovy issues

David,

I'd like to work on it. I have some time here and there over the next
week or two. I you have more time to devote to it, then go ahead. Either
way works for me.

-Adrian

David E Jones wrote:

>
> Yes, I think this is definitely something worth pursuing. Groovy parses
> and runs scripts way faster than BeanShell, but my guess is that we
> could increase efficiency and reduce execution time quite a bit by
> running scripts that are parsed in advance.
>
> The 10-20ms times I was seeing for running these scripts are fairly
> high, but they included a number of database interactions which also
> take a LOT of time, generally way more than parsing and running the
> script itself. I guess a good test would be to write a simple scripts
> that does a number of operations but no database interaction so that the
> load is mostly on parsing the script before running it. Then we would
> have a better idea of the parsing overhead time. I'm guess that parsing
> and running most scripts we use is WAY under 1ms, which is a lot less
> than the time to do even a single database query, so doing this will
> have an impact on the app server CPU load, but probably not much on
> overall application/system response times and performance.
>
> In general it seems like Groovy (and BeanShell and others are this way
> too...) is written to support running multiple scripts within the same
> context whereas we need to run the same scripts over and over many times
> with different contexts.
>
> The first step should probably be a question on a Groovy mailing list to
> see if anyone has ideas about how to do this with the existing version
> (1.5) or ideas about how such a thing might be added and if there is
> community interest in it.
>
> Would you like to do that Adrian, or would you prefer that I do it? In
> other words, I'm totally fine with you doing it but if you don't want to
> I'm happy to.
>
> -David
>
>
> On May 26, 2008, at 12:32 PM, Adrian Crum wrote:
>
>> David,
>>
>> I just spent some time looking through the Groovy source code, and
>> you're right - there is no thread-safe way to cache compiled scripts.
>> The Script, GroovyShell, and supporting classes all hold instances of
>> context variables (properties).
>>
>> There is a chance we can pull something off by digging deeper into
>> their source code and see if we can derive our own thread-safe classes
>> from some of their code. Let me know if you think it is worth pursuing.
>>
>> -Adrian
>>
>>
>> David E Jones <[hidden email]> wrote:
>> A quick look at the GroovyUtil.java file revealed why this is
>> happening. I apologize for not reviewing this better initially.
>>
>> Just as with BeanShell it looks like the way you run groovy scripts is
>> a little backwards and there appears to be no thread-safe way to cache
>> a parsed script and run it from the cache.
>>
>> Someone please prove me wrong before I go ask/complain on the groovy
>> mailing lists... there's got to be a way to do this!
>>
>> For now I've implemented a simple variation that just caches the
>> script text so at least we're not reading from the FS over and over.
>> The performance is okay with this (about 10-20ms to parse and run a
>> script), but I'm sure with a pre-parsed script it would be a lot better.
>>
>> See SVN rev 660228 for more info.
>>
>> If no one beats me to it I'll look at this more later... outta time
>> for now (or about 1.5hrs in the red... running late ;) ).
>>
>> -David
>>
>>
>> On May 26, 2008, at 5:52 AM, [hidden email] wrote:
>>
>>> Hi to all,
>>>
>>> at the moment there are only a few scripts that use Groovy but
>>> during my first tests I have seen a little issue.
>>> If you try to go on Edit Product Features
>>> (https://demo.hotwaxmedia.com/catalog/control/EditProductFeatures?productId=GZ-1006
>>>
>>> ) and then refresh the page then it you will receive the following
>>> error:
>>>
>>> Expression productFeatureAndAppls is undefined on line 41, column 20
>>> in component://product/webapp/catalog/product/
>>> EditProductFeatures.ftl. The problematic instruction: ---------- ==>
>>> list productFeatureAndAppls as productFeatureAndAppl [on line 41,
>>> column 13 in component://product/webapp/catalog/product/
>>> EditProductFeatures.ftl] ---------- Java backtrace for programmers:
>>> ---------- freemarker.core.InvalidReferenceException: Expression
>>> productFeatureAndAppls is undefined on line 41, column 20 in
>>> component://product/webapp/catalog/product/EditProductFeatures.ftl.
>>> at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:
>>> 124) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:93)
>>> at freemarker.core.Environment.visit(Environment.java:196) at
>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>> freemarker.core.Environment.visit(Environment.java:196) at
>>> freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79) at
>>> freemarker.core.Environment.visit(Environment.java:196) at
>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>> freemarker.core.Environment.visit(Environment.java:196) at
>>> freemarker.core.Environment.process(Environment.java:176) at
>>> org
>>> .ofbiz
>>> .base
>>> .util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>> 198) at
>>> org
>>> .ofbiz
>>> .base
>>> .util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>> 163) at
>>>
>>> something like the groovy script does not insert nothing in the
>>> context map.
>>> Doing some print into the groovy script I saw that it was run and
>>> inserted into the context but the ftl file does not see it.
>>>
>>> It seems to me that is something is not working correctly.
>>> So it's better to look at this error before continue to convert the
>>> scripts from bsh to groovy.
>>> It would be great if someone can help me on how to solve this issue.
>>>
>>> Thanks
>>> Marco
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>

David E Jones

Re: Groovy issues

Yes, please go for it then.

-David

On May 27, 2008, at 1:05 PM, Adrian Crum wrote:

> David,
>
> I'd like to work on it. I have some time here and there over the
> next week or two. I you have more time to devote to it, then go
> ahead. Either way works for me.
>
> -Adrian
>
> David E Jones wrote:
>> Yes, I think this is definitely something worth pursuing. Groovy
>> parses and runs scripts way faster than BeanShell, but my guess is
>> that we could increase efficiency and reduce execution time quite a
>> bit by running scripts that are parsed in advance.
>> The 10-20ms times I was seeing for running these scripts are fairly
>> high, but they included a number of database interactions which
>> also take a LOT of time, generally way more than parsing and
>> running the script itself. I guess a good test would be to write a
>> simple scripts that does a number of operations but no database
>> interaction so that the load is mostly on parsing the script before
>> running it. Then we would have a better idea of the parsing
>> overhead time. I'm guess that parsing and running most scripts we
>> use is WAY under 1ms, which is a lot less than the time to do even
>> a single database query, so doing this will have an impact on the
>> app server CPU load, but probably not much on overall application/
>> system response times and performance.
>> In general it seems like Groovy (and BeanShell and others are this
>> way too...) is written to support running multiple scripts within
>> the same context whereas we need to run the same scripts over and
>> over many times with different contexts.
>> The first step should probably be a question on a Groovy mailing
>> list to see if anyone has ideas about how to do this with the
>> existing version (1.5) or ideas about how such a thing might be
>> added and if there is community interest in it.
>> Would you like to do that Adrian, or would you prefer that I do it?
>> In other words, I'm totally fine with you doing it but if you don't
>> want to I'm happy to.
>> -David
>> On May 26, 2008, at 12:32 PM, Adrian Crum wrote:
>>> David,
>>>
>>> I just spent some time looking through the Groovy source code, and
>>> you're right - there is no thread-safe way to cache compiled
>>> scripts. The Script, GroovyShell, and supporting classes all hold
>>> instances of context variables (properties).
>>>
>>> There is a chance we can pull something off by digging deeper into
>>> their source code and see if we can derive our own thread-safe
>>> classes from some of their code. Let me know if you think it is
>>> worth pursuing.
>>>
>>> -Adrian
>>>
>>>
>>> David E Jones <[hidden email]> wrote:
>>> A quick look at the GroovyUtil.java file revealed why this is
>>> happening. I apologize for not reviewing this better initially.
>>>
>>> Just as with BeanShell it looks like the way you run groovy
>>> scripts is
>>> a little backwards and there appears to be no thread-safe way to
>>> cache
>>> a parsed script and run it from the cache.
>>>
>>> Someone please prove me wrong before I go ask/complain on the groovy
>>> mailing lists... there's got to be a way to do this!
>>>
>>> For now I've implemented a simple variation that just caches the
>>> script text so at least we're not reading from the FS over and over.
>>> The performance is okay with this (about 10-20ms to parse and run a
>>> script), but I'm sure with a pre-parsed script it would be a lot
>>> better.
>>>
>>> See SVN rev 660228 for more info.
>>>
>>> If no one beats me to it I'll look at this more later... outta time
>>> for now (or about 1.5hrs in the red... running late ;) ).
>>>
>>> -David
>>>
>>>
>>> On May 26, 2008, at 5:52 AM, [hidden email] wrote:
>>>
>>>> Hi to all,
>>>>
>>>> at the moment there are only a few scripts that use Groovy but
>>>> during my first tests I have seen a little issue.
>>>> If you try to go on Edit Product Features (https://demo.hotwaxmedia.com/catalog/control/EditProductFeatures?productId=GZ-1006
>>>> ) and then refresh the page then it you will receive the following
>>>> error:
>>>>
>>>> Expression productFeatureAndAppls is undefined on line 41, column
>>>> 20
>>>> in component://product/webapp/catalog/product/
>>>> EditProductFeatures.ftl. The problematic instruction: ----------
>>>> ==>
>>>> list productFeatureAndAppls as productFeatureAndAppl [on line 41,
>>>> column 13 in component://product/webapp/catalog/product/
>>>> EditProductFeatures.ftl] ---------- Java backtrace for programmers:
>>>> ---------- freemarker.core.InvalidReferenceException: Expression
>>>> productFeatureAndAppls is undefined on line 41, column 20 in
>>>> component://product/webapp/catalog/product/EditProductFeatures.ftl.
>>>> at
>>>> freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:
>>>> 124) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:93)
>>>> at freemarker.core.Environment.visit(Environment.java:196) at
>>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>> freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79)
>>>> at
>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>> freemarker.core.Environment.process(Environment.java:176) at
>>>> org
>>>> .ofbiz
>>>> .base
>>>> .util
>>>> .template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>>> 198) at
>>>> org
>>>> .ofbiz
>>>> .base
>>>> .util
>>>> .template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>>> 163) at
>>>>
>>>> something like the groovy script does not insert nothing in the
>>>> context map.
>>>> Doing some print into the groovy script I saw that it was run and
>>>> inserted into the context but the ftl file does not see it.
>>>>
>>>> It seems to me that is something is not working correctly.
>>>> So it's better to look at this error before continue to convert the
>>>> scripts from bsh to groovy.
>>>> It would be great if someone can help me on how to solve this
>>>> issue.
>>>>
>>>> Thanks
>>>> Marco
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>

Adrian Crum

Re: Groovy issues

Will do!

David E Jones wrote:

>
> Yes, please go for it then.
>
> -David
>
>
> On May 27, 2008, at 1:05 PM, Adrian Crum wrote:
>
>> David,
>>
>> I'd like to work on it. I have some time here and there over the next
>> week or two. I you have more time to devote to it, then go ahead.
>> Either way works for me.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> Yes, I think this is definitely something worth pursuing. Groovy
>>> parses and runs scripts way faster than BeanShell, but my guess is
>>> that we could increase efficiency and reduce execution time quite a
>>> bit by running scripts that are parsed in advance.
>>> The 10-20ms times I was seeing for running these scripts are fairly
>>> high, but they included a number of database interactions which also
>>> take a LOT of time, generally way more than parsing and running the
>>> script itself. I guess a good test would be to write a simple scripts
>>> that does a number of operations but no database interaction so that
>>> the load is mostly on parsing the script before running it. Then we
>>> would have a better idea of the parsing overhead time. I'm guess that
>>> parsing and running most scripts we use is WAY under 1ms, which is a
>>> lot less than the time to do even a single database query, so doing
>>> this will have an impact on the app server CPU load, but probably not
>>> much on overall application/system response times and performance.
>>> In general it seems like Groovy (and BeanShell and others are this
>>> way too...) is written to support running multiple scripts within the
>>> same context whereas we need to run the same scripts over and over
>>> many times with different contexts.
>>> The first step should probably be a question on a Groovy mailing list
>>> to see if anyone has ideas about how to do this with the existing
>>> version (1.5) or ideas about how such a thing might be added and if
>>> there is community interest in it.
>>> Would you like to do that Adrian, or would you prefer that I do it?
>>> In other words, I'm totally fine with you doing it but if you don't
>>> want to I'm happy to.
>>> -David
>>> On May 26, 2008, at 12:32 PM, Adrian Crum wrote:
>>>> David,
>>>>
>>>> I just spent some time looking through the Groovy source code, and
>>>> you're right - there is no thread-safe way to cache compiled
>>>> scripts. The Script, GroovyShell, and supporting classes all hold
>>>> instances of context variables (properties).
>>>>
>>>> There is a chance we can pull something off by digging deeper into
>>>> their source code and see if we can derive our own thread-safe
>>>> classes from some of their code. Let me know if you think it is
>>>> worth pursuing.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> David E Jones <[hidden email]> wrote:
>>>> A quick look at the GroovyUtil.java file revealed why this is
>>>> happening. I apologize for not reviewing this better initially.
>>>>
>>>> Just as with BeanShell it looks like the way you run groovy scripts is
>>>> a little backwards and there appears to be no thread-safe way to cache
>>>> a parsed script and run it from the cache.
>>>>
>>>> Someone please prove me wrong before I go ask/complain on the groovy
>>>> mailing lists... there's got to be a way to do this!
>>>>
>>>> For now I've implemented a simple variation that just caches the
>>>> script text so at least we're not reading from the FS over and over.
>>>> The performance is okay with this (about 10-20ms to parse and run a
>>>> script), but I'm sure with a pre-parsed script it would be a lot
>>>> better.
>>>>
>>>> See SVN rev 660228 for more info.
>>>>
>>>> If no one beats me to it I'll look at this more later... outta time
>>>> for now (or about 1.5hrs in the red... running late ;) ).
>>>>
>>>> -David
>>>>
>>>>
>>>> On May 26, 2008, at 5:52 AM, [hidden email] wrote:
>>>>
>>>>> Hi to all,
>>>>>
>>>>> at the moment there are only a few scripts that use Groovy but
>>>>> during my first tests I have seen a little issue.
>>>>> If you try to go on Edit Product Features
>>>>> (https://demo.hotwaxmedia.com/catalog/control/EditProductFeatures?productId=GZ-1006
>>>>>
>>>>> ) and then refresh the page then it you will receive the following
>>>>> error:
>>>>>
>>>>> Expression productFeatureAndAppls is undefined on line 41, column 20
>>>>> in component://product/webapp/catalog/product/
>>>>> EditProductFeatures.ftl. The problematic instruction: ---------- ==>
>>>>> list productFeatureAndAppls as productFeatureAndAppl [on line 41,
>>>>> column 13 in component://product/webapp/catalog/product/
>>>>> EditProductFeatures.ftl] ---------- Java backtrace for programmers:
>>>>> ---------- freemarker.core.InvalidReferenceException: Expression
>>>>> productFeatureAndAppls is undefined on line 41, column 20 in
>>>>> component://product/webapp/catalog/product/EditProductFeatures.ftl.
>>>>> at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:
>>>>> 124) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:93)
>>>>> at freemarker.core.Environment.visit(Environment.java:196) at
>>>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>>> freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79) at
>>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>>> freemarker.core.Environment.process(Environment.java:176) at
>>>>> org
>>>>> .ofbiz
>>>>> .base
>>>>> .util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>>>> 198) at
>>>>> org
>>>>> .ofbiz
>>>>> .base
>>>>> .util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>>>> 163) at
>>>>>
>>>>> something like the groovy script does not insert nothing in the
>>>>> context map.
>>>>> Doing some print into the groovy script I saw that it was run and
>>>>> inserted into the context but the ftl file does not see it.
>>>>>
>>>>> It seems to me that is something is not working correctly.
>>>>> So it's better to look at this error before continue to convert the
>>>>> scripts from bsh to groovy.
>>>>> It would be great if someone can help me on how to solve this issue.
>>>>>
>>>>> Thanks
>>>>> Marco
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>
>

David E Jones

Re: Groovy issues

Adrian,

I hate to say it as you were so willing to help out, but Joe Eckard
sent me some comments based on his looking around and in the
GroovyScriptEngine.java file in Groovy itself they do some caching. I
didn't want to use that class because it does it's own caching instead
of using the common/shared cache in OFBiz. I don't know why I didn't
think earlier to see what that class uses, but doing so revealed a
couple of interesting static methods and the fact the Groovy uses the
Class object to refer to cached scripts (crazy I know! but pretty cool
too...).

Anyway, in SVN rev 660695 we now have a parsed script cache working.

-David

On May 27, 2008, at 1:13 PM, Adrian Crum wrote:

> Will do!
>
> David E Jones wrote:
>> Yes, please go for it then.
>> -David
>> On May 27, 2008, at 1:05 PM, Adrian Crum wrote:
>>> David,
>>>
>>> I'd like to work on it. I have some time here and there over the
>>> next week or two. I you have more time to devote to it, then go
>>> ahead. Either way works for me.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> Yes, I think this is definitely something worth pursuing. Groovy
>>>> parses and runs scripts way faster than BeanShell, but my guess
>>>> is that we could increase efficiency and reduce execution time
>>>> quite a bit by running scripts that are parsed in advance.
>>>> The 10-20ms times I was seeing for running these scripts are
>>>> fairly high, but they included a number of database interactions
>>>> which also take a LOT of time, generally way more than parsing
>>>> and running the script itself. I guess a good test would be to
>>>> write a simple scripts that does a number of operations but no
>>>> database interaction so that the load is mostly on parsing the
>>>> script before running it. Then we would have a better idea of the
>>>> parsing overhead time. I'm guess that parsing and running most
>>>> scripts we use is WAY under 1ms, which is a lot less than the
>>>> time to do even a single database query, so doing this will have
>>>> an impact on the app server CPU load, but probably not much on
>>>> overall application/system response times and performance.
>>>> In general it seems like Groovy (and BeanShell and others are
>>>> this way too...) is written to support running multiple scripts
>>>> within the same context whereas we need to run the same scripts
>>>> over and over many times with different contexts.
>>>> The first step should probably be a question on a Groovy mailing
>>>> list to see if anyone has ideas about how to do this with the
>>>> existing version (1.5) or ideas about how such a thing might be
>>>> added and if there is community interest in it.
>>>> Would you like to do that Adrian, or would you prefer that I do
>>>> it? In other words, I'm totally fine with you doing it but if you
>>>> don't want to I'm happy to.
>>>> -David
>>>> On May 26, 2008, at 12:32 PM, Adrian Crum wrote:
>>>>> David,
>>>>>
>>>>> I just spent some time looking through the Groovy source code,
>>>>> and you're right - there is no thread-safe way to cache compiled
>>>>> scripts. The Script, GroovyShell, and supporting classes all
>>>>> hold instances of context variables (properties).
>>>>>
>>>>> There is a chance we can pull something off by digging deeper
>>>>> into their source code and see if we can derive our own thread-
>>>>> safe classes from some of their code. Let me know if you think
>>>>> it is worth pursuing.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> David E Jones <[hidden email]> wrote:
>>>>> A quick look at the GroovyUtil.java file revealed why this is
>>>>> happening. I apologize for not reviewing this better initially.
>>>>>
>>>>> Just as with BeanShell it looks like the way you run groovy
>>>>> scripts is
>>>>> a little backwards and there appears to be no thread-safe way to
>>>>> cache
>>>>> a parsed script and run it from the cache.
>>>>>
>>>>> Someone please prove me wrong before I go ask/complain on the
>>>>> groovy
>>>>> mailing lists... there's got to be a way to do this!
>>>>>
>>>>> For now I've implemented a simple variation that just caches the
>>>>> script text so at least we're not reading from the FS over and
>>>>> over.
>>>>> The performance is okay with this (about 10-20ms to parse and
>>>>> run a
>>>>> script), but I'm sure with a pre-parsed script it would be a lot
>>>>> better.
>>>>>
>>>>> See SVN rev 660228 for more info.
>>>>>
>>>>> If no one beats me to it I'll look at this more later... outta
>>>>> time
>>>>> for now (or about 1.5hrs in the red... running late ;) ).
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On May 26, 2008, at 5:52 AM, [hidden email] wrote:
>>>>>
>>>>>> Hi to all,
>>>>>>
>>>>>> at the moment there are only a few scripts that use Groovy but
>>>>>> during my first tests I have seen a little issue.
>>>>>> If you try to go on Edit Product Features (https://demo.hotwaxmedia.com/catalog/control/EditProductFeatures?productId=GZ-1006
>>>>>> ) and then refresh the page then it you will receive the
>>>>>> following
>>>>>> error:
>>>>>>
>>>>>> Expression productFeatureAndAppls is undefined on line 41,
>>>>>> column 20
>>>>>> in component://product/webapp/catalog/product/
>>>>>> EditProductFeatures.ftl. The problematic instruction:
>>>>>> ---------- ==>
>>>>>> list productFeatureAndAppls as productFeatureAndAppl [on line 41,
>>>>>> column 13 in component://product/webapp/catalog/product/
>>>>>> EditProductFeatures.ftl] ---------- Java backtrace for
>>>>>> programmers:
>>>>>> ---------- freemarker.core.InvalidReferenceException: Expression
>>>>>> productFeatureAndAppls is undefined on line 41, column 20 in
>>>>>> component://product/webapp/catalog/product/
>>>>>> EditProductFeatures.ftl.
>>>>>> at
>>>>>> freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:
>>>>>> 124) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:
>>>>>> 93)
>>>>>> at freemarker.core.Environment.visit(Environment.java:196) at
>>>>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>>>> freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:
>>>>>> 79) at
>>>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>>>> freemarker.core.Environment.process(Environment.java:176) at
>>>>>> org
>>>>>> .ofbiz
>>>>>> .base
>>>>>> .util
>>>>>> .template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>>>>> 198) at
>>>>>> org
>>>>>> .ofbiz
>>>>>> .base
>>>>>> .util
>>>>>> .template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>>>>> 163) at
>>>>>>
>>>>>> something like the groovy script does not insert nothing in the
>>>>>> context map.
>>>>>> Doing some print into the groovy script I saw that it was run and
>>>>>> inserted into the context but the ftl file does not see it.
>>>>>>
>>>>>> It seems to me that is something is not working correctly.
>>>>>> So it's better to look at this error before continue to convert
>>>>>> the
>>>>>> scripts from bsh to groovy.
>>>>>> It would be great if someone can help me on how to solve this
>>>>>> issue.
>>>>>>
>>>>>> Thanks
>>>>>> Marco
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>

Adrian Crum

Re: Groovy issues

Sweet! One less thing for me to do. ;-)

I'll get back to Ajax development.

David E Jones wrote:

>
> Adrian,
>
> I hate to say it as you were so willing to help out, but Joe Eckard sent
> me some comments based on his looking around and in the
> GroovyScriptEngine.java file in Groovy itself they do some caching. I
> didn't want to use that class because it does it's own caching instead
> of using the common/shared cache in OFBiz. I don't know why I didn't
> think earlier to see what that class uses, but doing so revealed a
> couple of interesting static methods and the fact the Groovy uses the
> Class object to refer to cached scripts (crazy I know! but pretty cool
> too...).
>
> Anyway, in SVN rev 660695 we now have a parsed script cache working.
>
> -David
>
>
> On May 27, 2008, at 1:13 PM, Adrian Crum wrote:
>
>> Will do!
>>
>> David E Jones wrote:
>>> Yes, please go for it then.
>>> -David
>>> On May 27, 2008, at 1:05 PM, Adrian Crum wrote:
>>>> David,
>>>>
>>>> I'd like to work on it. I have some time here and there over the
>>>> next week or two. I you have more time to devote to it, then go
>>>> ahead. Either way works for me.
>>>>
>>>> -Adrian
>>>>
>>>> David E Jones wrote:
>>>>> Yes, I think this is definitely something worth pursuing. Groovy
>>>>> parses and runs scripts way faster than BeanShell, but my guess is
>>>>> that we could increase efficiency and reduce execution time quite a
>>>>> bit by running scripts that are parsed in advance.
>>>>> The 10-20ms times I was seeing for running these scripts are fairly
>>>>> high, but they included a number of database interactions which
>>>>> also take a LOT of time, generally way more than parsing and
>>>>> running the script itself. I guess a good test would be to write a
>>>>> simple scripts that does a number of operations but no database
>>>>> interaction so that the load is mostly on parsing the script before
>>>>> running it. Then we would have a better idea of the parsing
>>>>> overhead time. I'm guess that parsing and running most scripts we
>>>>> use is WAY under 1ms, which is a lot less than the time to do even
>>>>> a single database query, so doing this will have an impact on the
>>>>> app server CPU load, but probably not much on overall
>>>>> application/system response times and performance.
>>>>> In general it seems like Groovy (and BeanShell and others are this
>>>>> way too...) is written to support running multiple scripts within
>>>>> the same context whereas we need to run the same scripts over and
>>>>> over many times with different contexts.
>>>>> The first step should probably be a question on a Groovy mailing
>>>>> list to see if anyone has ideas about how to do this with the
>>>>> existing version (1.5) or ideas about how such a thing might be
>>>>> added and if there is community interest in it.
>>>>> Would you like to do that Adrian, or would you prefer that I do it?
>>>>> In other words, I'm totally fine with you doing it but if you don't
>>>>> want to I'm happy to.
>>>>> -David
>>>>> On May 26, 2008, at 12:32 PM, Adrian Crum wrote:
>>>>>> David,
>>>>>>
>>>>>> I just spent some time looking through the Groovy source code, and
>>>>>> you're right - there is no thread-safe way to cache compiled
>>>>>> scripts. The Script, GroovyShell, and supporting classes all hold
>>>>>> instances of context variables (properties).
>>>>>>
>>>>>> There is a chance we can pull something off by digging deeper into
>>>>>> their source code and see if we can derive our own thread-safe
>>>>>> classes from some of their code. Let me know if you think it is
>>>>>> worth pursuing.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> David E Jones <[hidden email]> wrote:
>>>>>> A quick look at the GroovyUtil.java file revealed why this is
>>>>>> happening. I apologize for not reviewing this better initially.
>>>>>>
>>>>>> Just as with BeanShell it looks like the way you run groovy
>>>>>> scripts is
>>>>>> a little backwards and there appears to be no thread-safe way to
>>>>>> cache
>>>>>> a parsed script and run it from the cache.
>>>>>>
>>>>>> Someone please prove me wrong before I go ask/complain on the groovy
>>>>>> mailing lists... there's got to be a way to do this!
>>>>>>
>>>>>> For now I've implemented a simple variation that just caches the
>>>>>> script text so at least we're not reading from the FS over and over.
>>>>>> The performance is okay with this (about 10-20ms to parse and run a
>>>>>> script), but I'm sure with a pre-parsed script it would be a lot
>>>>>> better.
>>>>>>
>>>>>> See SVN rev 660228 for more info.
>>>>>>
>>>>>> If no one beats me to it I'll look at this more later... outta time
>>>>>> for now (or about 1.5hrs in the red... running late ;) ).
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On May 26, 2008, at 5:52 AM, [hidden email] wrote:
>>>>>>
>>>>>>> Hi to all,
>>>>>>>
>>>>>>> at the moment there are only a few scripts that use Groovy but
>>>>>>> during my first tests I have seen a little issue.
>>>>>>> If you try to go on Edit Product Features
>>>>>>> (https://demo.hotwaxmedia.com/catalog/control/EditProductFeatures?productId=GZ-1006
>>>>>>>
>>>>>>> ) and then refresh the page then it you will receive the following
>>>>>>> error:
>>>>>>>
>>>>>>> Expression productFeatureAndAppls is undefined on line 41, column 20
>>>>>>> in component://product/webapp/catalog/product/
>>>>>>> EditProductFeatures.ftl. The problematic instruction: ---------- ==>
>>>>>>> list productFeatureAndAppls as productFeatureAndAppl [on line 41,
>>>>>>> column 13 in component://product/webapp/catalog/product/
>>>>>>> EditProductFeatures.ftl] ---------- Java backtrace for programmers:
>>>>>>> ---------- freemarker.core.InvalidReferenceException: Expression
>>>>>>> productFeatureAndAppls is undefined on line 41, column 20 in
>>>>>>> component://product/webapp/catalog/product/EditProductFeatures.ftl.
>>>>>>> at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:
>>>>>>> 124) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:93)
>>>>>>> at freemarker.core.Environment.visit(Environment.java:196) at
>>>>>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>>>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>>>>> freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79) at
>>>>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>>>>> freemarker.core.MixedContent.accept(MixedContent.java:92) at
>>>>>>> freemarker.core.Environment.visit(Environment.java:196) at
>>>>>>> freemarker.core.Environment.process(Environment.java:176) at
>>>>>>> org
>>>>>>> .ofbiz
>>>>>>> .base
>>>>>>> .util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>>>>>>
>>>>>>> 198) at
>>>>>>> org
>>>>>>> .ofbiz
>>>>>>> .base
>>>>>>> .util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:
>>>>>>>
>>>>>>> 163) at
>>>>>>>
>>>>>>> something like the groovy script does not insert nothing in the
>>>>>>> context map.
>>>>>>> Doing some print into the groovy script I saw that it was run and
>>>>>>> inserted into the context but the ftl file does not see it.
>>>>>>>
>>>>>>> It seems to me that is something is not working correctly.
>>>>>>> So it's better to look at this error before continue to convert the
>>>>>>> scripts from bsh to groovy.
>>>>>>> It would be great if someone can help me on how to solve this issue.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Marco
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>
>