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 01:04:01 GMT
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.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
>>>
>>


Mime
View raw message