This did appear to fix the problem.... No more IAE. --jason
-----Original Message----- From: Dain Sundstrom <[EMAIL PROTECTED]> Date: Mon, 13 Feb 2006 17:04:01 To:dev@geronimo.apache.org Subject: Re: Strange IllegalAccessError w/FastClassByCGLIB class Jason, can you try adding an ejbRemove method directly to the class and see if the problem goes away? -dain On Feb 13, 2006, at 4:56 PM, Aaron Mulder wrote: > It may be the inheritance causing problems rather than the CL, as > well. You know, maybe we try calling ejbRemove on your bean class > even though it's declared on the superclass or something. If the CL > manipulations don't work out, we can follow that path. > > As far as the hidden classes, we unfortunately seem to have Spring > (and I guess Antlr?) on the Server classpath (I think something > related to clustering, which I'm hoping we can extract). If you load > that version of Spring, it can't see your bean classes because they're > in a child class loader. With the hidden classes filter, you're > saying that any classes beginning with those substrings shouldn't be > loaded from the parent class loader, so they'll always be loaded from > the version in your application, and therefore the Spring classes will > be able to see your bean classes. > > Aaron > > On 2/13/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> 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.MerchantViewS >>> ervi >>> 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 >>> >>
