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