Grails 1.3.7 and bean-fields

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Grails 1.3.7 and bean-fields

Göran Ehrsson
Hi,

I upgraded one of my apps to grails 1.3.7 and noticed that some of my bean-field usage render this on the page:

org.codehaus.groovy.grails.web.pages.GroovyPageOutputStack$GroovyPageProxyWriter@161c6e8

I patched bean-fields and made tag methods return null. Then the above output disappeared from the page.

Something must have changed that output the return value of tags to the page. I fear this will break lots of taglibs. Or is it just bean-fields that is affected?

Anyone else seen this?

/Göran Ehrsson

Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Lari Hotari -
18.02.2011 00:46, Goran Ehrsson wrote:
Hi,

I upgraded one of my apps to grails 1.3.7 and noticed that some of my bean-field usage render this on the page:

org.codehaus.groovy.grails.web.pages.GroovyPageOutputStack$GroovyPageProxyWriter@161c6e8

I patched bean-fields and made tag methods return null. Then the above output disappeared from the page.

Something must have changed that output the return value of tags to the page. I fear this will break lots of taglibs. Or is it just bean-fields that is affected?

Anyone else seen this?

/Göran Ehrsson


We are using bean-fields 1.0-RC4 & Grails 1.3.7 and we don't have the problem.

For some reason http://www.grails.org/plugin/bean-fields & http://svn.codehaus.org/grails-plugins/.plugin-meta/plugins-list.xml shows that the latest version is 1.0-RC3.
In http://svn.codehaus.org/grails-plugins/grails-bean-fields/trunk/ 1.0-RC4 is the latest.

Are you using 1.0-RC4 version of bean-fields? Does the problem exist with that version?
What version of Grails did you upgrade from? (There are only minor changes between 1.3.6 & 1.3.7 in the web package:
diff -r grails-1.3.6/src/java/org/codehaus/groovy/grails/web grails-1.3.7/src/java/org/codehaus/groovy/grails/web)

Lari

Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Göran Ehrsson
Lari Hotari wrote 2011-02-18 06:58:
18.02.2011 00:46, Goran Ehrsson wrote:
Hi,

I upgraded one of my apps to grails 1.3.7 and noticed that some of my bean-field usage render this on the page:

org.codehaus.groovy.grails.web.pages.GroovyPageOutputStack$GroovyPageProxyWriter@161c6e8

I patched bean-fields and made tag methods return null. Then the above output disappeared from the page.

Something must have changed that output the return value of tags to the page. I fear this will break lots of taglibs. Or is it just bean-fields that is affected?

Anyone else seen this?

/Göran Ehrsson


We are using bean-fields 1.0-RC4 & Grails 1.3.7 and we don't have the problem.

For some reason http://www.grails.org/plugin/bean-fields & http://svn.codehaus.org/grails-plugins/.plugin-meta/plugins-list.xml shows that the latest version is 1.0-RC3.
In http://svn.codehaus.org/grails-plugins/grails-bean-fields/trunk/ 1.0-RC4 is the latest.

Are you using 1.0-RC4 version of bean-fields? Does the problem exist with that version?
What version of Grails did you upgrade from? (There are only minor changes between 1.3.6 & 1.3.7 in the web package:
diff -r grails-1.3.6/src/java/org/codehaus/groovy/grails/web grails-1.3.7/src/java/org/codehaus/groovy/grails/web)

Lari


I was using bean-fields 1.0-RC3, so I upgraded to RC4 today but the problem still exists.

This is the markup:

<bean:withBean beanName="fileImportSpec">
 <fieldset>
  <legend><g:message code="fileImport.misc.title" default="Generic Information"/></legend>
  <bean:select property="type" from="${importerList}" optionKey="propertyName" valueMessagePrefix="fileImportSpec.type"/>
  <bean:input property="name"/>
  <bean:field property="description"/>
  <bean:select property="source" from="${sourceList}" optionKey="key" optionValue="value" noSelection="['':'Uploaded client file']"/>
  <bean:checkBox property="automatic"/>
 </fieldset>
</bean:withBean>


The "description" field is rendered  like this:

<label for="description" class=" ">Description</label><textarea id="description" cols="40" rows="2" name="description"></textarea><br>org.codehaus.groovy.grails.web.pages.GroovyPageOutputStack$GroovyPageProxyWriter@d8265a

The strange thing is that not all input fields on a page are affected. But I cannot see anything different between the fields that look ok, and those that look bad.

Once again I patched bean-fields, returning null in input, textArea, etc. tags. Then it works again (output in red above is not rendered).

I upgraded from 1.3.6 to 1.3.7

I will try to do a smaller reproducable case.

/Göran
Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Lari Hotari -
Hi,

I was able to reproduce the same problem by using the bean:field tag.

The problem seems to be caused by changes in Groovy after 1.7.5 .

I tested running Grails 1.3.7 with Groovy 1.7.5 by simply copying Groovy 1.7.5 jar to the name groovy-all-1.7.8.jar to $GRAILS_HOME/lib and removing ~/.ivy2/cache/org.codehaus.groovy/groovy-all/jars/groovy-all-1.7.8.jar. I don't think it's recommended for production setups, but good for quickly testing if Groovy downgrade makes a difference.
Do "grails clean" after changing the Groovy version (and remember the ivy2 cache when you switch versions).


This line in the field tag in bean-fields (in BeanTagLib.groovy) doesn't work correctly:

line 524:
            out << this."$tagName"(attrs)

This call is now going "directly" to the closure called "input". In 1.7.5 the call first goes to the MetaClass method with the same name ("input" in this case) introduced in WebMetaUtils.registerMethodMissingForTags .

Normally GroovyPage.captureTagOutput "captures" the output of a taglib call (also if you call other taglib closures within the same taglib class) and returns a StreamCharBuffer instance .
(see metaclass setup code in:
https://github.com/grails/grails-core/blob/1.3.x/src/java/org/codehaus/groovy/grails/web/plugins/support/WebMetaUtils.groovy#L252
https://github.com/grails/grails-core/blob/1.3.x/src/java/org/codehaus/groovy/grails/plugins/web/GroovyPagesGrailsPlugin.groovy#L256)


I placed a breakpoint on line 540 in BeanTagLib.groovy (1.0-RC4) and checked the call stacks:

Debugger stacktrace for Groovy 1.7.5:

Daemon Thread [http-8080-1] (Suspended (breakpoint at line 540 in BeanTagLib$_closure30))   
    BeanTagLib$_closure30.doCall(Object) line: 540   
    NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]   
    NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39   
    DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25   
    Method.invoke(Object, Object...) line: 597   
    CachedMethod.invoke(Object, Object[]) line: 88   
    CachedMethod(MetaMethod).doMethodInvoke(Object, Object[]) line: 233   
    ExpandoMetaClass(MetaClassImpl).invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1058   
    ExpandoMetaClass.invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1070   
    ExpandoMetaClass(MetaClassImpl).invokeMethod(Object, String, Object[]) line: 886   
    BeanTagLib$_closure30(Closure).call(Object[]) line: 276   
    GroovyPage.captureTagOutput(TagLibraryLookup, String, String, Map, Object, GrailsWebRequest) line: 529   
    GroovyPage$captureTagOutput.call(Object, Object[]) line: not available   
    CallSiteArray.defaultCall(CallSite, Object, Object[]) line: 40   
    GroovyPage$captureTagOutput.call(Object, Object[]) line: not available   
    WebMetaUtils$_registerMethodMissingForTags_closure24.doCall(Map) line: 247   
    NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]   
    NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39   
    DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25   
    Method.invoke(Object, Object...) line: 597   
    CachedMethod.invoke(Object, Object[]) line: 88   
    ClosureMetaMethod.invoke(Object, Object[]) line: 80   
    ClosureMetaMethod(MetaMethod).doMethodInvoke(Object, Object[]) line: 233   
    ExpandoMetaClass(MetaClassImpl).invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1058   
    ExpandoMetaClass.invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1070   
    ScriptBytecodeAdapter.invokeMethodOnCurrentN(Class, GroovyObject, String, Object[]) line: 77   
    BeanTagLib$_closure28.doCall(Object) line: 524   
    NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]   
    NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39   
    DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25   
    Method.invoke(Object, Object...) line: 597   
    CachedMethod.invoke(Object, Object[]) line: 88   
    CachedMethod(MetaMethod).doMethodInvoke(Object, Object[]) line: 233   
    ExpandoMetaClass(MetaClassImpl).invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1058   
    ExpandoMetaClass.invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1070   
    ExpandoMetaClass(MetaClassImpl).invokeMethod(Object, String, Object[]) line: 886   
    BeanTagLib$_closure28(Closure).call(Object[]) line: 276   
    some_long_filename_for_gsp(GroovyPage).invokeTag(String, String, int, Map, Closure) line: 357   
 


Debugger stacktrace in 1.7.8:
Daemon Thread [http-8080-1] (Suspended (breakpoint at line 540 in BeanTagLib$_closure30))   
    BeanTagLib$_closure30.doCall(Object) line: 540   
    GeneratedMethodAccessor492.invoke(Object, Object[]) line: not available   
    DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25   
    Method.invoke(Object, Object...) line: 597   
    CachedMethod.invoke(Object, Object[]) line: 90   
    CachedMethod(MetaMethod).doMethodInvoke(Object, Object[]) line: 233   
    ExpandoMetaClass(MetaClassImpl).invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1058   
    ExpandoMetaClass.invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1070   
    ExpandoMetaClass(MetaClassImpl).invokePropertyOrMissing(Object, String, Object[], boolean, boolean) line: 1097   
    ExpandoMetaClass(MetaClassImpl).invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1060   
    ExpandoMetaClass.invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1070   
    ScriptBytecodeAdapter.invokeMethodOnCurrentN(Class, GroovyObject, String, Object[]) line: 77   
    BeanTagLib$_closure28.doCall(Object) line: 524   
    NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]   
    NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39   
    DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25   
    Method.invoke(Object, Object...) line: 597   
    CachedMethod.invoke(Object, Object[]) line: 90   
    CachedMethod(MetaMethod).doMethodInvoke(Object, Object[]) line: 233   
    ExpandoMetaClass(MetaClassImpl).invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1058   
    ExpandoMetaClass.invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1070   
    ExpandoMetaClass(MetaClassImpl).invokeMethod(Object, String, Object[]) line: 886   
    BeanTagLib$_closure28(Closure).call(Object[]) line: 282
    some_long_filename_for_gsp(GroovyPage).invokeTag(String, String, int, Map, Closure) line: 357


Groovy 1.7.8 behaves differently.
I remember noticing that if you run groovy 1.7.8 compiled groovy classes on 1.7.5 the problem still exists, so it might be a compiler change.

It should be quite easy to do a workaround for beanfields, but the difference seen here seems to be quite a big change in Groovy.



Lari



18.02.2011 23:17, Goran Ehrsson wrote:
Lari Hotari wrote 2011-02-18 06:58:
18.02.2011 00:46, Goran Ehrsson wrote:
Hi,

I upgraded one of my apps to grails 1.3.7 and noticed that some of my bean-field usage render this on the page:

org.codehaus.groovy.grails.web.pages.GroovyPageOutputStack$GroovyPageProxyWriter@161c6e8

I patched bean-fields and made tag methods return null. Then the above output disappeared from the page.

Something must have changed that output the return value of tags to the page. I fear this will break lots of taglibs. Or is it just bean-fields that is affected?

Anyone else seen this?

/Göran Ehrsson


We are using bean-fields 1.0-RC4 & Grails 1.3.7 and we don't have the problem.

For some reason http://www.grails.org/plugin/bean-fields & http://svn.codehaus.org/grails-plugins/.plugin-meta/plugins-list.xml shows that the latest version is 1.0-RC3.
In http://svn.codehaus.org/grails-plugins/grails-bean-fields/trunk/ 1.0-RC4 is the latest.

Are you using 1.0-RC4 version of bean-fields? Does the problem exist with that version?
What version of Grails did you upgrade from? (There are only minor changes between 1.3.6 & 1.3.7 in the web package:
diff -r grails-1.3.6/src/java/org/codehaus/groovy/grails/web grails-1.3.7/src/java/org/codehaus/groovy/grails/web)

Lari


I was using bean-fields 1.0-RC3, so I upgraded to RC4 today but the problem still exists.

This is the markup:

<bean:withBean beanName="fileImportSpec">
 <fieldset>
  <legend><g:message code="fileImport.misc.title" default="Generic Information"/></legend>
  <bean:select property="type" from="${importerList}" optionKey="propertyName" valueMessagePrefix="fileImportSpec.type"/>
  <bean:input property="name"/>
  <bean:field property="description"/>
  <bean:select property="source" from="${sourceList}" optionKey="key" optionValue="value" noSelection="['':'Uploaded client file']"/>
  <bean:checkBox property="automatic"/>
 </fieldset>
</bean:withBean>


The "description" field is rendered  like this:

<label for="description" class=" ">Description</label><textarea id="description" cols="40" rows="2" name="description"></textarea><br>org.codehaus.groovy.grails.web.pages.GroovyPageOutputStack$GroovyPageProxyWriter@d8265a

The strange thing is that not all input fields on a page are affected. But I cannot see anything different between the fields that look ok, and those that look bad.

Once again I patched bean-fields, returning null in input, textArea, etc. tags. Then it works again (output in red above is not rendered).

I upgraded from 1.3.6 to 1.3.7

I will try to do a smaller reproducable case.

/Göran

Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Jochen Theodorou
Am 19.02.2011 03:39, schrieb Lari Hotari:

> Hi,
>
> I was able to reproduce the same problem by using the bean:field tag.
>
> The problem seems to be caused by changes in Groovy after 1.7.5 .
>
> I tested running Grails 1.3.7 with Groovy 1.7.5 by simply copying Groovy
> 1.7.5 jar to the name groovy-all-1.7.8.jar to $GRAILS_HOME/lib and
> removing
> ~/.ivy2/cache/org.codehaus.groovy/groovy-all/jars/groovy-all-1.7.8.jar.
> I don't think it's recommended for production setups, but good for
> quickly testing if Groovy downgrade makes a difference.
> Do "grails clean" after changing the Groovy version (and remember the
> ivy2 cache when you switch versions).

it would actually good to test against 1.7.6 and maybe even 1.7.7 (but
that one will probably be not different from 1.7.8)

> This line in the field tag in bean-fields (in BeanTagLib.groovy) doesn't
> work correctly:
>
> line 524:
> out << this."$tagName"(attrs)

from what I have seen only the this."$tagName"(attrs) part is important
here.

> This call is now going "directly" to the closure called "input". In
> 1.7.5 the call first goes to the MetaClass method with the same name
> ("input" in this case) introduced in
> WebMetaUtils.registerMethodMissingForTags .


form the stack

> *Debugger stacktrace for Groovy 1.7.5:*
[...]

> *GroovyPage.captureTagOutput(TagLibraryLookup, String, String, Map, Object, GrailsWebRequest) line: 529 *
> GroovyPage$captureTagOutput.call(Object, Object[]) line: not available
> CallSiteArray.defaultCall(CallSite, Object, Object[]) line: 40
> GroovyPage$captureTagOutput.call(Object, Object[]) line: not available
> WebMetaUtils$_registerMethodMissingForTags_closure24.doCall(Map) line: 247
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
> available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
> Method.invoke(Object, Object...) line: 597
> CachedMethod.invoke(Object, Object[]) line: 88
> ClosureMetaMethod.invoke(Object, Object[]) line: 80
> ClosureMetaMethod(MetaMethod).doMethodInvoke(Object, Object[]) line: 233
> ExpandoMetaClass(MetaClassImpl).invokeMethod(Class, Object, String,
> Object[], boolean, boolean) line: 1058
> ExpandoMetaClass.invokeMethod(Class, Object, String, Object[], boolean,
> boolean) line: 1070
> ScriptBytecodeAdapter.invokeMethodOnCurrentN(Class, GroovyObject, String, Object[]) line: 77
> *BeanTagLib$_closure28.doCall(Object) line: 524 *

I can see ClosureMetaMethod. This is used if you for example add a
method to EMC using a Closure. I assume that is the tagName method. In
the trace

> *Debugger stacktrace in 1.7.8:*
> Daemon Thread [http-8080-1] (Suspended (breakpoint at line 540 in BeanTagLib$_closure30))
> *BeanTagLib$_closure30.doCall(Object) line: 540*
> GeneratedMethodAccessor492.invoke(Object, Object[]) line: not available
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
> Method.invoke(Object, Object...) line: 597
> CachedMethod.invoke(Object, Object[]) line: 90
> CachedMethod(MetaMethod).doMethodInvoke(Object, Object[]) line: 233
> ExpandoMetaClass(MetaClassImpl).invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1058
> ExpandoMetaClass.invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1070
> ExpandoMetaClass(MetaClassImpl).invokePropertyOrMissing(Object, String, Object[], boolean, boolean) line: 1097
> ExpandoMetaClass(MetaClassImpl).invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1060
> ExpandoMetaClass.invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1070
> ScriptBytecodeAdapter.invokeMethodOnCurrentN(Class, GroovyObject, String, Object[]) line: 77
> *BeanTagLib$_closure28.doCall(Object) line: 524 *

I can see that EMC is not going to call the ClosureMetaMethod, instead
it goes to invokePropertyOrMissing, which means the tagName method was
not found.

> Groovy 1.7.8 behaves differently.
> I remember noticing that if you run groovy 1.7.8 compiled groovy classes
> on 1.7.5 the problem still exists, so it might be a compiler change.

the bytecode interface used is
ScriptBytecodeAdapter#invokeMethodOnCurrentN in both cases, so no
compiler change at that place. Since it is a method call using a GString
there is also no method call site caching involved. Actually the only
part that makes sense is that something in EMC has changed, but since
the last change to EMC that got into 1.7.x was on April 14 2010, I think
that can be almost surely excluded. So it should be something else,
something I am not aware of atm.

> It should be quite easy to do a workaround for beanfields, but the
> difference seen here seems to be quite a big change in Groovy.

Well, if you can reproduce the issue in Groovy without using Grails,
then this indeed is a sure Groovy bug, and will be fixed right away. If
you can reproduce it only in Grails, then it is impossible to exclude
Grails from the sourced of possible bugs.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Marc Palmer Local

On 21 Feb 2011, at 09:59, Jochen Theodorou wrote:

>
> I can see ClosureMetaMethod. This is used if you for example add a method to EMC using a Closure. I assume that is the tagName method. In the trace
>
>> *Debugger stacktrace in 1.7.8:*
>> Daemon Thread [http-8080-1] (Suspended (breakpoint at line 540 in BeanTagLib$_closure30))
>> *BeanTagLib$_closure30.doCall(Object) line: 540*
>> GeneratedMethodAccessor492.invoke(Object, Object[]) line: not available
>> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
>> Method.invoke(Object, Object...) line: 597
>> CachedMethod.invoke(Object, Object[]) line: 90
>> CachedMethod(MetaMethod).doMethodInvoke(Object, Object[]) line: 233
>> ExpandoMetaClass(MetaClassImpl).invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1058
>> ExpandoMetaClass.invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1070
>> ExpandoMetaClass(MetaClassImpl).invokePropertyOrMissing(Object, String, Object[], boolean, boolean) line: 1097
>> ExpandoMetaClass(MetaClassImpl).invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1060
>> ExpandoMetaClass.invokeMethod(Class, Object, String, Object[], boolean, boolean) line: 1070
>> ScriptBytecodeAdapter.invokeMethodOnCurrentN(Class, GroovyObject, String, Object[]) line: 77
>> *BeanTagLib$_closure28.doCall(Object) line: 524 *
>
> I can see that EMC is not going to call the ClosureMetaMethod, instead it goes to invokePropertyOrMissing, which means the tagName method was not found.
>

If I recall correctly, methodMissing is used for taglib tag invocation. The tag is found, but using this mechanism.

This taglib is possibly the most "complex" taglib out there, if only because of its extensive use of closures including nested closures.

As a result it does show up "nuances" in implementations of groovy/grails over time :)

>> Groovy 1.7.8 behaves differently.
>> I remember noticing that if you run groovy 1.7.8 compiled groovy classes
>> on 1.7.5 the problem still exists, so it might be a compiler change.
>
> the bytecode interface used is ScriptBytecodeAdapter#invokeMethodOnCurrentN in both cases, so no compiler change at that place. Since it is a method call using a GString there is also no method call site caching involved. Actually the only part that makes sense is that something in EMC has changed, but since the last change to EMC that got into 1.7.x was on April 14 2010, I think that can be almost surely excluded. So it should be something else, something I am not aware of atm.
>

Well these apps and this code runs fine with Grails 1.3.6 (groovy 1.7.5) and all versions (in recent memory) prior.

>> It should be quite easy to do a workaround for beanfields, but the
>> difference seen here seems to be quite a big change in Groovy.
>
> Well, if you can reproduce the issue in Groovy without using Grails, then this indeed is a sure Groovy bug, and will be fixed right away. If you can reproduce it only in Grails, then it is impossible to exclude Grails from the sourced of possible bugs.

Please Jochen... humour us :)

As the authors of a language you cannot constantly throw out any difficult problems to the apps that are built on the language. One needs to be proactive. Any regression of language-level behaviour out to be a serious concern/bad smell for the devs of the language. I would hope for a little more enthusiasm.

I don't understand why it appears that core groovy devs are not eager to try to reproduce issues with Grails themselves, and in fact seem quite unfamiliar with Grails internals. Seeing as Grails is doubtless the major source of interest in Groovy, it is in the groovy team's direct interests to be more on top of this.

Sometimes you guys seem completely separate, even though the paid devs are all at the same company. Its a bit of a "WTF?" sometimes.

Grails and Groovy's success are intimately linked.

What if users of Grails got so fed up with regressions/instability due to Groovy and put unbearable pressure on SpringSource to pull Groovy out of Grails and replace it with e.g. Scale.

Imagine the groovy world without Grails as its major user base.

Its not likely to happen - its just a thought experiment - but I know everyone I talk to is concerned about stability of Grails, and often (but not always) this comes down to Groovy issues.

Anyway the "blame" for this issue can be easily narrowed down.

We just need to run the failing code with Grails 1.3.6 and a groovy 1.7.8-all jar.

I'll be back shortly with the outcome. Whether the problem is with groovy or grails, most of the devs are all on the same team so....

Marc
~ ~ ~
Marc Palmer
Freelancer (Grails/Groovy/Java)

Blog         > http://www.anyware.co.uk
Twitter      > http://twitter.com/wangjammer5
Grails Rocks > http://www.grailsrocks.com








---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Marc Palmer Local
In reply to this post by Jochen Theodorou

Results of testing:

Grails 1.3.7 + Groovy 1.7.8: FAIL
Grails 1.3.7 + Groovy 1.7.5: OK
Grails 1.3.6 + Groovy 1.7.5: OK
Grails 1.3.6 + Groovy 1.7.8: FAIL

So how about we all get together and review the taglib code and how Grails invokes it so that we can all isolate this?

I say this, because I cannot do it alone. The cost is prohibitive, especially after all the time spent reviewing heap dumps and trying to isolate the Groovy 1.7.5 permgen leaks. I'm truly not being awkward about this, its just reality. A team effort will get this cracked.

The concern is also where else is this failure occurring. It is unlikely to be just beanfields - but beanfields is a visual place for it to occur, so it is relatively easy to spot.

Frankly, I thought the groovy team were aware of this problem as some of my client's developers had encountered this problem with 1.7.7... and I asked them to raise it on the groovy list. Either they didn't or it got overlooked. :(

Cheers,
Marc
~ ~ ~
Marc Palmer
Freelancer (Grails/Groovy/Java)

Blog         > http://www.anyware.co.uk
Twitter      > http://twitter.com/wangjammer5
Grails Rocks > http://www.grailsrocks.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Jochen Theodorou
In reply to this post by Marc Palmer Local
Am 22.02.2011 11:27, schrieb Marc Palmer:
[...]
>>> Groovy 1.7.8 behaves differently.
>>> I remember noticing that if you run groovy 1.7.8 compiled groovy classes
>>> on 1.7.5 the problem still exists, so it might be a compiler change.
>>
>> the bytecode interface used is ScriptBytecodeAdapter#invokeMethodOnCurrentN in both cases,
 >> so no compiler change at that place. Since it is a method call using
a GString there is also
>> no method call site caching involved. Actually the only part that makes sense is that
>> something in EMC has changed, but since the last change to EMC that got into 1.7.x was on
>> April 14 2010, I think that can be almost surely excluded. So it should be something else,
>> something I am not aware of atm.
>
> Well these apps and this code runs fine with Grails 1.3.6 (groovy
> 1.7.5) and all versions (in recent memory) prior.

I didn't say there is no problem, I only said that I expect the class,
the compiler spits out is not the problem. Something in the runtime
should be responsible. If it is the bytecode, then just compare the
bytecode of them both and if you find more differences than the added
hotswap reloading method, then it might be really something in that
area. But I find it unlikely.

[...]
> I don't understand why it appears that core groovy devs are not
> eager  to try to reproduce issues with Grails themselves, and in fact
> seem quite unfamiliar with Grails internals. Seeing as Grails is
> doubtless the major source of interest in Groovy, it is in the groovy
> team's direct interests to be more on top of this.

So you think the grails people and dev team are not able to narrow down
the problem? Marc, why not having more faith in them? The groovy core
devs are not all that many people. A comparable number of people is
working on grails too. And for both there is more than enough to do. So
I think we should try to support each other, but something like
narrowing down to a certain version is something that an be done as
preparation or not?

I asked for trying out 1.7.6 and 1.7.7 so we can at least assume what
may be responsible. But maybe I should have written that that was not
directed at Lari, but at Goran.

> Sometimes you guys seem completely separate, even though the paid
> devs  are all at the same company. Its a bit of a "WTF?" sometimes.

I think some people would get angry at me if I openly discuss management
here. That should tell you enough.

> Grails and Groovy's success are intimately linked.
>
> What if users of Grails got so fed up with regressions/instability
> due  to Groovy and put unbearable pressure on SpringSource to pull
> Groovy out of Grails and replace it with e.g. Scale.
>
> Imagine the groovy world without Grails as its major user base.
>
> Its not likely to happen - its just a thought experiment - but I
> know  everyone I talk to is concerned about stability of Grails,
> and often (but not always) this comes down to Groovy issues.

well, I often enough had a Groovy issue that turned out as feature
request or Grails issue. And then?

> Anyway the "blame" for this issue can be easily narrowed down.
>
> We just need to run the failing code with Grails 1.3.6 and a groovy
> 1.7.8-all jar.

It would help to use for everything the exact same version except for
the groovy-all, or to use for everything the new version and use the
1.7.5 groovy-all jar. If you change too many components then there are
too many sources of errors.

> I'll be back shortly with the outcome. Whether the problem is with
> groovy or grails, most of the devs are all on the same team so....

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Jochen Theodorou
In reply to this post by Marc Palmer Local
Am 22.02.2011 13:19, schrieb Marc Palmer:
>
> Results of testing:
>
> Grails 1.3.7 + Groovy 1.7.8: FAIL
> Grails 1.3.7 + Groovy 1.7.5: OK
> Grails 1.3.6 + Groovy 1.7.5: OK
> Grails 1.3.6 + Groovy 1.7.8: FAIL

can you test with 1.7.6 as well? That helps much more than just testing
1.7.8 and 1.7.5. But this of course speaks for a Groovy problem.

[...]
> Frankly, I thought the groovy team were aware of this problem as
> some  of my client's developers had encountered this problem with 1.7.7...
> and I asked them to raise it on the groovy list. Either they didn't or it
> got overlooked. :(

they didn't do it as far as I can see.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Marc Palmer Local
In reply to this post by Jochen Theodorou

On 22 Feb 2011, at 12:31, Jochen Theodorou wrote:

> [...]
>> I don't understand why it appears that core groovy devs are not
>> eager  to try to reproduce issues with Grails themselves, and in fact
>> seem quite unfamiliar with Grails internals. Seeing as Grails is
>> doubtless the major source of interest in Groovy, it is in the groovy
>> team's direct interests to be more on top of this.
>
> So you think the grails people and dev team are not able to narrow down the problem? Marc, why not having more faith in them? The groovy core devs are not all that many people. A comparable number of people is working on grails too. And for both there is more than enough to do. So I think we should try to support each other, but something like narrowing down to a certain version is something that an be done as preparation or not?
>
> I asked for trying out 1.7.6 and 1.7.7 so we can at least assume what may be responsible. But maybe I should have written that that was not directed at Lari, but at Goran.
>
>> Sometimes you guys seem completely separate, even though the paid
>> devs  are all at the same company. Its a bit of a "WTF?" sometimes.
>
> I think some people would get angry at me if I openly discuss management here. That should tell you enough.
>

:(

>> Grails and Groovy's success are intimately linked.
>>
>> What if users of Grails got so fed up with regressions/instability
>> due  to Groovy and put unbearable pressure on SpringSource to pull
>> Groovy out of Grails and replace it with e.g. Scale.
>>
>> Imagine the groovy world without Grails as its major user base.
>>
>> Its not likely to happen - its just a thought experiment - but I
>> know  everyone I talk to is concerned about stability of Grails,
>> and often (but not always) this comes down to Groovy issues.
>
> well, I often enough had a Groovy issue that turned out as feature request or Grails issue. And then?
>

I don't know what to say to that... except I think it demonstrates exactly my point. The relationship between Groovy and Grails is completely symbiotic at the moment, and yet seems to be dysfunctional at times.

I know all you guys couldn't work harder than you do. I am not questioning that. I also don't think there is anything here that is atypical for open source. One would hope for more coherence and a joined up "customer relations" strategy given that both teams are "owned" by the same company.

This is getting off topic from the actual problem though...

>> Anyway the "blame" for this issue can be easily narrowed down.
>>
>> We just need to run the failing code with Grails 1.3.6 and a groovy
>> 1.7.8-all jar.
>
> It would help to use for everything the exact same version except for the groovy-all, or to use for everything the new version and use the 1.7.5 groovy-all jar. If you change too many components then there are too many sources of errors.

You've already seen my other post.

Marc


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Guillaume Laforge-2
Do you have a simple sample app exhibiting those problems?

On Tue, Feb 22, 2011 at 15:27, Marc Palmer <[hidden email]> wrote:

On 22 Feb 2011, at 12:31, Jochen Theodorou wrote:

> [...]
>> I don't understand why it appears that core groovy devs are not
>> eager  to try to reproduce issues with Grails themselves, and in fact
>> seem quite unfamiliar with Grails internals. Seeing as Grails is
>> doubtless the major source of interest in Groovy, it is in the groovy
>> team's direct interests to be more on top of this.
>
> So you think the grails people and dev team are not able to narrow down the problem? Marc, why not having more faith in them? The groovy core devs are not all that many people. A comparable number of people is working on grails too. And for both there is more than enough to do. So I think we should try to support each other, but something like narrowing down to a certain version is something that an be done as preparation or not?
>
> I asked for trying out 1.7.6 and 1.7.7 so we can at least assume what may be responsible. But maybe I should have written that that was not directed at Lari, but at Goran.
>
>> Sometimes you guys seem completely separate, even though the paid
>> devs  are all at the same company. Its a bit of a "WTF?" sometimes.
>
> I think some people would get angry at me if I openly discuss management here. That should tell you enough.
>

:(

>> Grails and Groovy's success are intimately linked.
>>
>> What if users of Grails got so fed up with regressions/instability
>> due  to Groovy and put unbearable pressure on SpringSource to pull
>> Groovy out of Grails and replace it with e.g. Scale.
>>
>> Imagine the groovy world without Grails as its major user base.
>>
>> Its not likely to happen - its just a thought experiment - but I
>> know  everyone I talk to is concerned about stability of Grails,
>> and often (but not always) this comes down to Groovy issues.
>
> well, I often enough had a Groovy issue that turned out as feature request or Grails issue. And then?
>

I don't know what to say to that... except I think it demonstrates exactly my point. The relationship between Groovy and Grails is completely symbiotic at the moment, and yet seems to be dysfunctional at times.

I know all you guys couldn't work harder than you do. I am not questioning that. I also don't think there is anything here that is atypical for open source. One would hope for more coherence and a joined up "customer relations" strategy given that both teams are "owned" by the same company.

This is getting off topic from the actual problem though...

>> Anyway the "blame" for this issue can be easily narrowed down.
>>
>> We just need to run the failing code with Grails 1.3.6 and a groovy
>> 1.7.8-all jar.
>
> It would help to use for everything the exact same version except for the groovy-all, or to use for everything the new version and use the 1.7.5 groovy-all jar. If you change too many components then there are too many sources of errors.

You've already seen my other post.

Marc


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Göran Ehrsson
I have a minimal test app. I will attach it to a JIRA issue within a few minutes. Stay tuned...

/Göran

Guillaume Laforge skrev 2011-02-22 15:49:
Do you have a simple sample app exhibiting those problems?

On Tue, Feb 22, 2011 at 15:27, Marc Palmer <[hidden email]> wrote:

On 22 Feb 2011, at 12:31, Jochen Theodorou wrote:

> [...]
>> I don't understand why it appears that core groovy devs are not
>> eager  to try to reproduce issues with Grails themselves, and in fact
>> seem quite unfamiliar with Grails internals. Seeing as Grails is
>> doubtless the major source of interest in Groovy, it is in the groovy
>> team's direct interests to be more on top of this.
>
> So you think the grails people and dev team are not able to narrow down the problem? Marc, why not having more faith in them? The groovy core devs are not all that many people. A comparable number of people is working on grails too. And for both there is more than enough to do. So I think we should try to support each other, but something like narrowing down to a certain version is something that an be done as preparation or not?
>
> I asked for trying out 1.7.6 and 1.7.7 so we can at least assume what may be responsible. But maybe I should have written that that was not directed at Lari, but at Goran.
>
>> Sometimes you guys seem completely separate, even though the paid
>> devs  are all at the same company. Its a bit of a "WTF?" sometimes.
>
> I think some people would get angry at me if I openly discuss management here. That should tell you enough.
>

:(

>> Grails and Groovy's success are intimately linked.
>>
>> What if users of Grails got so fed up with regressions/instability
>> due  to Groovy and put unbearable pressure on SpringSource to pull
>> Groovy out of Grails and replace it with e.g. Scale.
>>
>> Imagine the groovy world without Grails as its major user base.
>>
>> Its not likely to happen - its just a thought experiment - but I
>> know  everyone I talk to is concerned about stability of Grails,
>> and often (but not always) this comes down to Groovy issues.
>
> well, I often enough had a Groovy issue that turned out as feature request or Grails issue. And then?
>

I don't know what to say to that... except I think it demonstrates exactly my point. The relationship between Groovy and Grails is completely symbiotic at the moment, and yet seems to be dysfunctional at times.

I know all you guys couldn't work harder than you do. I am not questioning that. I also don't think there is anything here that is atypical for open source. One would hope for more coherence and a joined up "customer relations" strategy given that both teams are "owned" by the same company.

This is getting off topic from the actual problem though...

>> Anyway the "blame" for this issue can be easily narrowed down.
>>
>> We just need to run the failing code with Grails 1.3.6 and a groovy
>> 1.7.8-all jar.
>
> It would help to use for everything the exact same version except for the groovy-all, or to use for everything the new version and use the 1.7.5 groovy-all jar. If you change too many components then there are too many sources of errors.

You've already seen my other post.

Marc


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one


Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Guillaume Laforge-2
Thank you Goran!

On Tue, Feb 22, 2011 at 16:17, Goran Ehrsson <[hidden email]> wrote:
I have a minimal test app. I will attach it to a JIRA issue within a few minutes. Stay tuned...

/Göran

Guillaume Laforge skrev 2011-02-22 15:49:
Do you have a simple sample app exhibiting those problems?

On Tue, Feb 22, 2011 at 15:27, Marc Palmer <[hidden email]> wrote:

On 22 Feb 2011, at 12:31, Jochen Theodorou wrote:

> [...]
>> I don't understand why it appears that core groovy devs are not
>> eager  to try to reproduce issues with Grails themselves, and in fact
>> seem quite unfamiliar with Grails internals. Seeing as Grails is
>> doubtless the major source of interest in Groovy, it is in the groovy
>> team's direct interests to be more on top of this.
>
> So you think the grails people and dev team are not able to narrow down the problem? Marc, why not having more faith in them? The groovy core devs are not all that many people. A comparable number of people is working on grails too. And for both there is more than enough to do. So I think we should try to support each other, but something like narrowing down to a certain version is something that an be done as preparation or not?
>
> I asked for trying out 1.7.6 and 1.7.7 so we can at least assume what may be responsible. But maybe I should have written that that was not directed at Lari, but at Goran.
>
>> Sometimes you guys seem completely separate, even though the paid
>> devs  are all at the same company. Its a bit of a "WTF?" sometimes.
>
> I think some people would get angry at me if I openly discuss management here. That should tell you enough.
>

:(

>> Grails and Groovy's success are intimately linked.
>>
>> What if users of Grails got so fed up with regressions/instability
>> due  to Groovy and put unbearable pressure on SpringSource to pull
>> Groovy out of Grails and replace it with e.g. Scale.
>>
>> Imagine the groovy world without Grails as its major user base.
>>
>> Its not likely to happen - its just a thought experiment - but I
>> know  everyone I talk to is concerned about stability of Grails,
>> and often (but not always) this comes down to Groovy issues.
>
> well, I often enough had a Groovy issue that turned out as feature request or Grails issue. And then?
>

I don't know what to say to that... except I think it demonstrates exactly my point. The relationship between Groovy and Grails is completely symbiotic at the moment, and yet seems to be dysfunctional at times.

I know all you guys couldn't work harder than you do. I am not questioning that. I also don't think there is anything here that is atypical for open source. One would hope for more coherence and a joined up "customer relations" strategy given that both teams are "owned" by the same company.

This is getting off topic from the actual problem though...

>> Anyway the "blame" for this issue can be easily narrowed down.
>>
>> We just need to run the failing code with Grails 1.3.6 and a groovy
>> 1.7.8-all jar.
>
> It would help to use for everything the exact same version except for the groovy-all, or to use for everything the new version and use the 1.7.5 groovy-all jar. If you change too many components then there are too many sources of errors.

You've already seen my other post.

Marc


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Göran Ehrsson
In reply to this post by Guillaume Laforge-2
http://jira.codehaus.org/browse/GRAILS-7299

/Göran

Guillaume Laforge wrote 2011-02-22 15:49:
Do you have a simple sample app exhibiting those problems?

On Tue, Feb 22, 2011 at 15:27, Marc Palmer <[hidden email]> wrote:

On 22 Feb 2011, at 12:31, Jochen Theodorou wrote:

> [...]
>> I don't understand why it appears that core groovy devs are not
>> eager  to try to reproduce issues with Grails themselves, and in fact
>> seem quite unfamiliar with Grails internals. Seeing as Grails is
>> doubtless the major source of interest in Groovy, it is in the groovy
>> team's direct interests to be more on top of this.
>
> So you think the grails people and dev team are not able to narrow down the problem? Marc, why not having more faith in them? The groovy core devs are not all that many people. A comparable number of people is working on grails too. And for both there is more than enough to do. So I think we should try to support each other, but something like narrowing down to a certain version is something that an be done as preparation or not?
>
> I asked for trying out 1.7.6 and 1.7.7 so we can at least assume what may be responsible. But maybe I should have written that that was not directed at Lari, but at Goran.
>
>> Sometimes you guys seem completely separate, even though the paid
>> devs  are all at the same company. Its a bit of a "WTF?" sometimes.
>
> I think some people would get angry at me if I openly discuss management here. That should tell you enough.
>

:(

>> Grails and Groovy's success are intimately linked.
>>
>> What if users of Grails got so fed up with regressions/instability
>> due  to Groovy and put unbearable pressure on SpringSource to pull
>> Groovy out of Grails and replace it with e.g. Scale.
>>
>> Imagine the groovy world without Grails as its major user base.
>>
>> Its not likely to happen - its just a thought experiment - but I
>> know  everyone I talk to is concerned about stability of Grails,
>> and often (but not always) this comes down to Groovy issues.
>
> well, I often enough had a Groovy issue that turned out as feature request or Grails issue. And then?
>

I don't know what to say to that... except I think it demonstrates exactly my point. The relationship between Groovy and Grails is completely symbiotic at the moment, and yet seems to be dysfunctional at times.

I know all you guys couldn't work harder than you do. I am not questioning that. I also don't think there is anything here that is atypical for open source. One would hope for more coherence and a joined up "customer relations" strategy given that both teams are "owned" by the same company.

This is getting off topic from the actual problem though...

>> Anyway the "blame" for this issue can be easily narrowed down.
>>
>> We just need to run the failing code with Grails 1.3.6 and a groovy
>> 1.7.8-all jar.
>
> It would help to use for everything the exact same version except for the groovy-all, or to use for everything the new version and use the 1.7.5 groovy-all jar. If you change too many components then there are too many sources of errors.

You've already seen my other post.

Marc


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one


-- 
Technipelago AB, Gransbergsvägen 18, 139 73 Djurhamn, 08-57151036
Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Guillaume Laforge-2
Thanks again!

On Tue, Feb 22, 2011 at 16:31, Goran Ehrsson <[hidden email]> wrote:
http://jira.codehaus.org/browse/GRAILS-7299

/Göran

Guillaume Laforge wrote 2011-02-22 15:49:
Do you have a simple sample app exhibiting those problems?

On Tue, Feb 22, 2011 at 15:27, Marc Palmer <[hidden email]> wrote:

On 22 Feb 2011, at 12:31, Jochen Theodorou wrote:

> [...]
>> I don't understand why it appears that core groovy devs are not
>> eager  to try to reproduce issues with Grails themselves, and in fact
>> seem quite unfamiliar with Grails internals. Seeing as Grails is
>> doubtless the major source of interest in Groovy, it is in the groovy
>> team's direct interests to be more on top of this.
>
> So you think the grails people and dev team are not able to narrow down the problem? Marc, why not having more faith in them? The groovy core devs are not all that many people. A comparable number of people is working on grails too. And for both there is more than enough to do. So I think we should try to support each other, but something like narrowing down to a certain version is something that an be done as preparation or not?
>
> I asked for trying out 1.7.6 and 1.7.7 so we can at least assume what may be responsible. But maybe I should have written that that was not directed at Lari, but at Goran.
>
>> Sometimes you guys seem completely separate, even though the paid
>> devs  are all at the same company. Its a bit of a "WTF?" sometimes.
>
> I think some people would get angry at me if I openly discuss management here. That should tell you enough.
>

:(

>> Grails and Groovy's success are intimately linked.
>>
>> What if users of Grails got so fed up with regressions/instability
>> due  to Groovy and put unbearable pressure on SpringSource to pull
>> Groovy out of Grails and replace it with e.g. Scale.
>>
>> Imagine the groovy world without Grails as its major user base.
>>
>> Its not likely to happen - its just a thought experiment - but I
>> know  everyone I talk to is concerned about stability of Grails,
>> and often (but not always) this comes down to Groovy issues.
>
> well, I often enough had a Groovy issue that turned out as feature request or Grails issue. And then?
>

I don't know what to say to that... except I think it demonstrates exactly my point. The relationship between Groovy and Grails is completely symbiotic at the moment, and yet seems to be dysfunctional at times.

I know all you guys couldn't work harder than you do. I am not questioning that. I also don't think there is anything here that is atypical for open source. One would hope for more coherence and a joined up "customer relations" strategy given that both teams are "owned" by the same company.

This is getting off topic from the actual problem though...

>> Anyway the "blame" for this issue can be easily narrowed down.
>>
>> We just need to run the failing code with Grails 1.3.6 and a groovy
>> 1.7.8-all jar.
>
> It would help to use for everything the exact same version except for the groovy-all, or to use for everything the new version and use the 1.7.5 groovy-all jar. If you change too many components then there are too many sources of errors.

You've already seen my other post.

Marc


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one


-- 
Technipelago AB, Gransbergsvägen 18, 139 73 Djurhamn, 08-57151036



--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Guillaume Laforge-2
I just updated my Grails installation to 1.3.7, and unzipped your sample app, and tried grails run-app on it and got:

glaforge-2:bftest-bug-report-22022011 glaforge$ grails run-app
Welcome to Grails 1.3.7 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: /Library/Grails/grails-1.3.7

Base Directory: /Users/glaforge/Downloads/bftest-bug-report-22022011
Resolving dependencies...
Downloading: /Library/Grails/grails-1.3.7/dist/grails-docs-1.3.7.jar ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/dist/grails-bootstrap-1.3.7.jar ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/dist/grails-scripts-1.3.7.jar ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/dist/grails-core-1.3.7.jar ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/dist/grails-resources-1.3.7.jar ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/dist/grails-web-1.3.7.jar ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/lib/groovy-all-1.7.8.jar ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/dist/grails-crud-1.3.7.jar ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/dist/grails-gorm-1.3.7.jar ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/dist/grails-spring-1.3.7.jar ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/dist/grails-test-1.3.7.jar ...
Download complete.
Dependencies resolved in 2667ms.
Running script /Library/Grails/grails-1.3.7/scripts/RunApp.groovy
Environment set to development
    [mkdir] Created dir: /Users/glaforge/Downloads/bftest-bug-report-22022011/scripts
    [mkdir] Created dir: /Users/glaforge/Downloads/bftest-bug-report-22022011/web-app
    [mkdir] Created dir: /Users/glaforge/Downloads/bftest-bug-report-22022011/web-app/js
    [mkdir] Created dir: /Users/glaforge/Downloads/bftest-bug-report-22022011/web-app/css
    [mkdir] Created dir: /Users/glaforge/Downloads/bftest-bug-report-22022011/web-app/images
    [mkdir] Created dir: /Users/glaforge/Downloads/bftest-bug-report-22022011/web-app/META-INF
    [mkdir] Created dir: /Users/glaforge/Downloads/bftest-bug-report-22022011/lib
Plugin [bean-fields-1.0-RC4] not installed. ...
Plugin [tomcat-1.3.7] not installed. ...
Plugin [hibernate-1.3.7] not installed. ...
Resolving new plugins. Please wait... ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/plugins/grails-tomcat-1.3.7.zip ...
Download complete.
Downloading: /Library/Grails/grails-1.3.7/plugins/grails-hibernate-1.3.7.zip ...
Download complete.
Installing zip /Users/glaforge/.ivy2/cache/org.grails.plugins/bean-fields/zips/bean-fields-1.0-RC4.zip... ...
    [mkdir] Created dir: /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/plugins/bean-fields-1.0-RC4
    [unzip] Expanding: /Users/glaforge/.ivy2/cache/org.grails.plugins/bean-fields/zips/bean-fields-1.0-RC4.zip into /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/plugins/bean-fields-1.0-RC4
Installed plugin bean-fields-1.0-RC4 to location /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/plugins/bean-fields-1.0-RC4. ...
Executing bean-fields-1.0-RC4 plugin post-install script ...
Plugin bean-fields-1.0-RC4 installed
   [delete] Deleting directory /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/resources
Installing zip /Users/glaforge/.ivy2/cache/org.grails.plugins/tomcat/zips/tomcat-1.3.7.zip... ...
    [mkdir] Created dir: /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/plugins/tomcat-1.3.7
    [unzip] Expanding: /Users/glaforge/.ivy2/cache/org.grails.plugins/tomcat/zips/tomcat-1.3.7.zip into /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/plugins/tomcat-1.3.7
Installed plugin tomcat-1.3.7 to location /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/plugins/tomcat-1.3.7. ...
Executing tomcat-1.3.7 plugin post-install script ...
Plugin tomcat-1.3.7 installed
Plugin provides the following new scripts:
------------------------------------------
grails tomcat
Installing zip /Users/glaforge/.ivy2/cache/org.grails.plugins/hibernate/zips/hibernate-1.3.7.zip... ...
    [mkdir] Created dir: /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/plugins/hibernate-1.3.7
    [unzip] Expanding: /Users/glaforge/.ivy2/cache/org.grails.plugins/hibernate/zips/hibernate-1.3.7.zip into /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/plugins/hibernate-1.3.7
Installed plugin hibernate-1.3.7 to location /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/plugins/hibernate-1.3.7. ...
Resolving plugin JAR dependencies ...
Executing hibernate-1.3.7 plugin post-install script ...
Plugin hibernate-1.3.7 installed
     [copy] Copied 3 empty directories to 2 empty directories under /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/resources
    [mkdir] Created dir: /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/plugin-classes
  [groovyc] Compiling 3 source files to /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/plugin-classes
    [mkdir] Created dir: /Users/glaforge/Downloads/bftest-bug-report-22022011/target/classes
  [groovyc] Compiling 9 source files to /Users/glaforge/Downloads/bftest-bug-report-22022011/target/classes
    [mkdir] Created dir: /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/resources/grails-app/i18n
[native2ascii] Converting 13 files from /Users/glaforge/Downloads/bftest-bug-report-22022011/grails-app/i18n to /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/resources/grails-app/i18n
     [copy] Copying 1 file to /Users/glaforge/Downloads/bftest-bug-report-22022011/target/classes
     [copy] Copied 2 empty directories to 2 empty directories under /Users/glaforge/.grails/1.3.7/projects/bftest-bug-report-22022011/resources
Running Grails application..
2011-02-22 16:48:47,845 [main] ERROR context.GrailsContextLoader  - Error executing bootstraps: IOException parsing XML document from ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/applicationContext.xml]
org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/applicationContext.xml]
at org.grails.tomcat.TomcatServer.start(TomcatServer.groovy:212)
at grails.web.container.EmbeddableServer$start.call(Unknown Source)
at RunApp$_run_closure5_closure12.doCall(RunApp:158)
at RunApp$_run_closure5_closure12.doCall(RunApp)
at RunApp$_run_closure10.doCall(RunApp:280)
at RunApp$_run_closure10.call(RunApp)
at RunApp$_run_closure5.doCall(RunApp:149)
at RunApp$_run_closure5.call(RunApp)
at RunApp.runInline(RunApp:116)
at RunApp.this$4$runInline(RunApp)
at RunApp$_run_closure1.doCall(RunApp:59)
at RunApp$_run_closure1.doCall(RunApp.groovy:33)
at gant.Gant$_dispatch_closure5.doCall(Gant.groovy:381)
at gant.Gant$_dispatch_closure7.doCall(Gant.groovy:415)
at gant.Gant$_dispatch_closure7.doCall(Gant.groovy)
at gant.Gant.withBuildListeners(Gant.groovy:427)
at gant.Gant.this$2$withBuildListeners(Gant.groovy)
at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
at gant.Gant.dispatch(Gant.groovy:415)
at gant.Gant.this$2$dispatch(Gant.groovy)
at gant.Gant.invokeMethod(Gant.groovy)
at gant.Gant.executeTargets(Gant.groovy:590)
at gant.Gant.executeTargets(Gant.groovy:589)
Caused by: java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/applicationContext.xml]
... 23 more


On Tue, Feb 22, 2011 at 16:36, Guillaume Laforge <[hidden email]> wrote:
Thanks again!


On Tue, Feb 22, 2011 at 16:31, Goran Ehrsson <[hidden email]> wrote:
http://jira.codehaus.org/browse/GRAILS-7299

/Göran

Guillaume Laforge wrote 2011-02-22 15:49:
Do you have a simple sample app exhibiting those problems?

On Tue, Feb 22, 2011 at 15:27, Marc Palmer <[hidden email]> wrote:

On 22 Feb 2011, at 12:31, Jochen Theodorou wrote:

> [...]
>> I don't understand why it appears that core groovy devs are not
>> eager  to try to reproduce issues with Grails themselves, and in fact
>> seem quite unfamiliar with Grails internals. Seeing as Grails is
>> doubtless the major source of interest in Groovy, it is in the groovy
>> team's direct interests to be more on top of this.
>
> So you think the grails people and dev team are not able to narrow down the problem? Marc, why not having more faith in them? The groovy core devs are not all that many people. A comparable number of people is working on grails too. And for both there is more than enough to do. So I think we should try to support each other, but something like narrowing down to a certain version is something that an be done as preparation or not?
>
> I asked for trying out 1.7.6 and 1.7.7 so we can at least assume what may be responsible. But maybe I should have written that that was not directed at Lari, but at Goran.
>
>> Sometimes you guys seem completely separate, even though the paid
>> devs  are all at the same company. Its a bit of a "WTF?" sometimes.
>
> I think some people would get angry at me if I openly discuss management here. That should tell you enough.
>

:(

>> Grails and Groovy's success are intimately linked.
>>
>> What if users of Grails got so fed up with regressions/instability
>> due  to Groovy and put unbearable pressure on SpringSource to pull
>> Groovy out of Grails and replace it with e.g. Scale.
>>
>> Imagine the groovy world without Grails as its major user base.
>>
>> Its not likely to happen - its just a thought experiment - but I
>> know  everyone I talk to is concerned about stability of Grails,
>> and often (but not always) this comes down to Groovy issues.
>
> well, I often enough had a Groovy issue that turned out as feature request or Grails issue. And then?
>

I don't know what to say to that... except I think it demonstrates exactly my point. The relationship between Groovy and Grails is completely symbiotic at the moment, and yet seems to be dysfunctional at times.

I know all you guys couldn't work harder than you do. I am not questioning that. I also don't think there is anything here that is atypical for open source. One would hope for more coherence and a joined up "customer relations" strategy given that both teams are "owned" by the same company.

This is getting off topic from the actual problem though...

>> Anyway the "blame" for this issue can be easily narrowed down.
>>
>> We just need to run the failing code with Grails 1.3.6 and a groovy
>> 1.7.8-all jar.
>
> It would help to use for everything the exact same version except for the groovy-all, or to use for everything the new version and use the 1.7.5 groovy-all jar. If you change too many components then there are too many sources of errors.

You've already seen my other post.

Marc


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one


-- 
Technipelago AB, Gransbergsvägen 18, 139 73 Djurhamn, 08-57151036



--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one



--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

pledbrook
> I just updated my Grails installation to 1.3.7, and unzipped your sample
> app, and tried grails run-app on it and got:
> glaforge-2:bftest-bug-report-22022011 glaforge$ grails run-app

You need to run 'grails upgrade' first.

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Marc Palmer Local
In reply to this post by Guillaume Laforge-2

On 22 Feb 2011, at 15:50, Guillaume Laforge wrote:

> I just updated my Grails installation to 1.3.7, and unzipped your sample app, and tried grails run-app on it and got:
>

Its just missing the vanilla WEB-INF/applicationContext.xml and sitemesh.xml I imagine.

You can just grails create-app on a dummy app and copy them across.

Marc
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Marc Palmer Local
In reply to this post by Göran Ehrsson

On 22 Feb 2011, at 15:17, Goran Ehrsson wrote:

> I have a minimal test app. I will attach it to a JIRA issue within a few minutes. Stay tuned...

Thanks for doing that Göran. I had to step out (need to get the "coders hair" cut back sometimes!), otherwise I was going to do it.

Marc


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails 1.3.7 and bean-fields

Guillaume Laforge-2
In reply to this post by Marc Palmer Local
That's what I ended up doing.

Is changing the GRAILS_HOME/lib/groovy.jar the best approach for testing different groovy versions?
(I renamed them to 1.7.8)

That way it seems the problem appeared in 1.7.6, so something between 1.7.5 and 1.7.6 changed.

On Tue, Feb 22, 2011 at 16:55, Marc Palmer <[hidden email]> wrote:

On 22 Feb 2011, at 15:50, Guillaume Laforge wrote:

> I just updated my Grails installation to 1.3.7, and unzipped your sample app, and tried grails run-app on it and got:
>

Its just missing the vanilla WEB-INF/applicationContext.xml and sitemesh.xml I imagine.

You can just grails create-app on a dummy app and copy them across.

Marc
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
12