Paul King wrote:
I would guess two versions of the class loaded by two different class loaders? Can you describe what if any class loading arrangement the server might have in place?
Digging deeper I suspect that the root cause for this error may possibly be a multithreading problem in Groovy's MetaClassImpl. For me the code is not easy to understand, but as far as I can see there seems to be no synchronization involved when methods are being cached in the MetaClassImpl (MetaMethodIndex/FastArray). Could missing thread-safety explain the "ambiguous method overloading" error thrown by doChooseMostSpecificParams? -- Cheers, Alex