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

Reply via email to