geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Strange IllegalAccessError w/FastClassByCGLIB class
Date Tue, 14 Feb 2006 01:04:01 GMT
Jason, can you try adding an ejbRemove method directly to the class  
and see if the problem goes away?


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

View raw message