On Feb 13, 2006, at 4:43 AM, Aaron Mulder wrote:
On 2/13/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
I will look at it more... I'm not familiar with the proxy gen in G
yet... but a race condition sounds likely since this problem only
shows up in multithreaded concurrency test.
I'm not convinced it's a proxy error. I mean, clearly *something*
happened while calling the remove method, but the message is pretty
vague -- could be a classloader problem, could be something wrong with
the session bean lifecycle, could be something wrong with the test...
I'm hoping that if we look for where that message is generated it'll
suggest what might be going wrong.
This is not a proxy error at all. This is caused when calling
FastClass.invoke which is a faster version of reflection. IIRC this
error normally means that the calling code does not have access to
the target method. FWIU, regardless of using reflection or generated
byte code, the VM will prevent a caller from accessing a method it
would not normally have access to via normal Java code. If the
method is private and you attempt to use reflection to invoke it, the
VM will throw an IllegalAccessError. This enforcement code gets
weird when you attempt to call across class loaders.
Anyway, lets start with the basics. Can you post the
com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewServi
ceBean.ejbRemove () code?
BTW, I rewrote this code in OpenEJB head to use plain old reflection
(long story), so it shouldn't appear there. I am curious if you can
reproduce the problem using reflection. Regardless, this is a
problem we need to fix, since we use AbstractMethodOperation all over.
-dain
