MerchantViewServiceBean does not have its own ejbRemote(), it picks it up from AbstractStatelessSessionBean (from app), which picks it up from AbstractStatelessSessionBean (from spring).
Could be a CL problem... the application is using Spring 1.1.4, which is included in the EAR. In my plan I had to add this to even get the application to init: <hidden-classes><filter>org.springframework</filter></hidden-classes> <hidden-classes><filter>antlr</filter></hidden-classes> I don't really understand what this does either. I will try again w/o the spring jars in the ear and see how that fairs... though I don't really like to have to be put into this situation, where I have to use jars outside of the ear. I personally prefer that in theory, but in practice, the more separate jars that I have to give to QA/Ops, the more chances of them *ucking it up. Anyways, I'd imagine there are a many apps out there that will include jars in their ear for deployment. G should really do the right thing with them... regardless of which is right from a theoretical perspective or not. --jason On 2/13/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > 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 >
