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.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 > > >
