geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Strange IllegalAccessError w/FastClassByCGLIB class
Date Tue, 14 Feb 2006 16:45:40 GMT
Thanks.  I'll ask Chris about the error.

-dain

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 <dain@iq80.com>
> 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 <jason@planet57.com> 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 <dain@iq80.com> wrote:
>>>> On Feb 13, 2006, at 4:43 AM, Aaron Mulder wrote:
>>>>
>>>>> On 2/13/06, Jason Dillon <jason@planet57.com> 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
>>>>
>>>


Mime
View raw message