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 16:45:40 GMT
Thanks.  I'll ask Chris about the error.


On Feb 13, 2006, at 9:39 PM, Jason Dillon wrote:

> This did appear to fix the problem.... No more IAE.
> --jason
> -----Original Message-----
> From: Dain Sundstrom <>
> Date: Mon, 13 Feb 2006 17:04:01
> 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 <> 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.MerchantView 
>>>> S
>>>> 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