[groovy-user] Crazy exception??

[Rob West]

Can anyone help me figure out this exception??

It has got me perplexed.  How can a method that takes an Object not be a valid choice for a call with a LinkedHashMap??

groovy.lang.MissingMethodException: No signature of method: static com.gmongo.internal.Patcher._converAllCharSeqToString() is applicable for argument types: (java.util.LinkedHashMap) values: [[subscription:5783]]

Possible solutions: _converAllCharSeqToString(java.lang.Object)

at groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1357)

at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1343)

at groovy.lang.ExpandoMetaClass.invokeStaticMethod(ExpandoMetaClass.java:1082)

at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.callStatic(StaticMetaClassSite.java:62)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:173)

at com.gmongo.internal.Patcher._convert(Patcher.groovy:71)

at com.gmongo.internal.Patcher$_convert.callStatic(Unknown Source)

at com.gmongo.internal.Patcher$__patchInternal_closure1.doCall(Patcher.groovy:32)

at sun.reflect.GeneratedMethodAccessor119.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)

at org.codehaus.groovy.runtime.metaclass.ClosureMetaMethod.invoke(ClosureMetaMethod.java:80)

at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1068)

at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)

at org.codehaus.groovy.runtime.callsite.PerInstancePojoMetaClassSite.call(PerInstancePojoMetaClassSite.java:35)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)

<snip>

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

at java.util.concurrent.FutureTask.run(FutureTask.java:138)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:662)

We are using grails 1.3.7, which seems to be using groovy 1.7.8.

Thanks!

Rob

[Roshan Dawrani]

Since you have showed no code, here is a guess : "Don't call instance methods statically"

--
Roshan

http://roshandawrani.wordpress.com/

[Rob West]

Sorry, you're right. I should have given more information. We are
using gmongo version 0.9.5. The code calling
_converAllCharSeqToString is
https://github.com/poiati/gmongo/blob/master/src/main/groovy/com/gmongo/internal/Patcher.groovy#L71

We are doing the following that is causing that to be called:

public class EtlRevisionPollingWorker implements Runnable {
<snip>
long subscription
<snip>
TenantService tenantService
<snip>
Map context
static COLLECTION_NAME = "subscription_context"
<snip>
private void saveContext() {
if(this.context == [:]) {
tenantService.getDB().getCollection(COLLECTION_NAME).remove("subscription":
this.subscription)
} else {
<snip>

The TenantService is a GMongo proxy. It is adding nothing when not in
the test environment. The exception happened in a trial production
run.

Thanks for any help!

-- Rob

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

http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Am 07.09.2012 07:17, schrieb Roshan Dawrani:
> Since you have showed no code, here is a guess : "Don't call instance

> methods statically <http://groovyconsole.appspot.com/script/745001>"

Roshan, what do you think, should we maybe improve the error reporting
to show only the static methods in case of a static method call? Or
should we try analyzing if there was a fitting method, but the method
was non static? Something like that? Because it seems even though the
message is much better than what we had in early times, it is still not
good enough

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org

[Rob West]

+1 for even better error reporting

In this case it is a static (trying) to call a static. The called method's parameter and return value are dynamically typed.

Since the code in question is GMongo, which has been around and stable for a long time, I expect that the trigger for the problem is in our environment.

What is the difference between the search for a matching method on dispatch and the search for possibilities on exception? Other than the obvious of requiring a exact match rather than one that is close.

Is it possible that a bug could have messed up the data structure used to dispatch but not affect the ability for the error reporting to see the match?

Thanks,
Rob

Sent from my iPhone

[Jochen Theodorou]

Am 08.09.2012 18:01, schrieb Rob West:
> +1 for even better error reporting
>
> In this case it is a static (trying) to call a static. The called
> method's parameter and return value are dynamically typed.

Yes, I could verify that method is static... currently I see no reason
why the call should fail. Is it possible for you to try a newer 1.7?
http://dist.groovy.codehaus.org/distributions/groovy-binary-1.7.11.zip

I currently don't remember a method selection bug in a late 1.7, but
well, 1.7.8 has been released quite a while ago already.

> Since the code in question is GMongo, which has been around and
> stable for a long time, I expect that the trigger for the problem is
> in our environment.

still, from what I see the call should just work

> What is the difference between the search for a matching method on
> dispatch and the search for possibilities on exception? Other than
> the obvious of requiring a exact match rather than one that is
> close.

well, they are two completely different algorithms. The method selection
for invocation does an exact match on the name and then a match on
compatible types, to later determine, what is the closest matching
method to your request. The exception part does just get a list of
methods and makes an unsharp match on the name based on Levenshtein. The
intend is to let the user see a list of alternatives in case he
misspelled the method name of forgot a parameter.

> Is it possible that a bug could have messed up the data structure
> used to dispatch but not affect the ability for the error reporting
> to see the match?

that is indeed possible. I only wonder how to get this resolved in
another way than really debugging the application on the meta class level.

[Rob West]

Thanks for the responses!

I'm wondering if the bug that the following commit fixed in 1.7.11
could be the issue:

http://git.codehaus.org/gitweb.cgi?p=groovy-git.git;a=commitdiff;h=8527ac3720e87e95fb601ea8cf5d7409471e4cbf

We did have at least 5 threads running.

-- Rob

[Jochen Theodorou]

Am 11.09.2012 06:47, schrieb Rob West:
> Thanks for the responses!
>
> I'm wondering if the bug that the following commit fixed in 1.7.11
> could be the issue:
>
> http://git.codehaus.org/gitweb.cgi?p=groovy-git.git;a=commitdiff;h=8527ac3720e87e95fb601ea8cf5d7409471e4cbf
>
> We did have at least 5 threads running.

now that might be. Can you test 1.7.11?

[Paulo Gabriel Poiati]

Hello Guys,

Sorry, I only saw this thread now. I am behind GMongo, version 0.9.5 is only compatible with Groovy 1.8.x and version 1.0 with Groovy 2.x.

If you can't upgrade the Groovy / Grails versions I recommend the version 0.9.2.

Cheers.

[]'s
Paulo Poiati

blog.paulopoiati.com

[Rob West]

Thanks, we're going to upgrade to Grails 2.1.1 as soon as possible, which supports Groovy 1.8.8.

However, I don't understand why GMongo 0.9.5 doesn't support Groovy 1.7 in addition to 1.8.  Even more so, why doesn't GMongo 1.0 support Groovy 1.8 in addition to 2.0, especially since Grails 2.1.1 was just released and it doesn't support 2.0 yet.  Otherwise, in our Grails project, we can't use both GMongo and the latest version of the Mongo Java driver since it is only supported by GMongo 1.0.

Cheers,

Rob

[Paulo Gabriel Poiati]

You are right Rob.

Actually Groovy 2.0 is recommended for GMongo 1.0 but it also should run fine with Groovy 1.8.x.

 

About the backward compatibility with 1.7.x, I really don't know why it's broken, I think it's something related to static methods, maybe the core team can help us.

[]'s
Paulo Poiati

blog.paulopoiati.com