geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Strange IllegalAccessError w/FastClassByCGLIB class
Date Tue, 14 Feb 2006 00:49:08 GMT
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:


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.


On 2/13/06, Dain Sundstrom <> wrote:
> On Feb 13, 2006, at 4:43 AM, Aaron Mulder wrote:
> > On 2/13/06, Jason Dillon <> 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

View raw message