You're correct, it is a bug. It has been fixed, it should be checked in
shortly I believe.
-----Original Message-----
From: Per Bockman
To: 'JBoss-Dev'
Sent: 2/20/01 1:38 PM
Subject: RE: [jBoss-Dev] Exception and classloader issues
> > there seems to be some classloader related issues when an
> Exception is
> > thrown from a bean in one ejb-jar to a bean that's loaded
> from another
> > ejb-jar file within the same VM.
> >
> > Lets assume that we have the following two ejb-jar files deployed in
> JBoss:
> >
> > foo.jar
> > -------
> > Foo.class
> > FooHome.class
> > FooBean.class
> > FooException.class
> > META-INF/ejb-jar.xml // nothing special here...
> >
> > goo.jar
> > -------
> > Goo.class
> > GooHome.class
> > GooBean.class
> > Foo.class
> > FooHome.class
> > FooException.class
> > META-INF/ejb-jar.xml // declares an ejb-ref to the Foo EJB
> > META-INF/jboss.xml // maps the ejb-ref to the jndi-name
> >
> >
> > Consider the following scenario:
> >
> > An operation on a GooBean instance triggers an invocation
> on the FooBean
> > which throws a FooException in order to indicate some problem.
> >
> > Now the GooBean can't catch the FooException as the
> exception thrown from
> > the FooBean has bean instantiated by a different CL (the
> GooBean recevies
> a
> > java.lang.reflect.UndeclaredThrowableException).
> >
> > Is there any workarounds for this problem or do I have to
> place both the
> > FooBean and GooBean classes into the same ejb-jar file in
> order to get the
> > scenario outlined above to work.
>
> Yes, put the Exceptions into there own jar and put this jar file into
> $JBOSS_HOME/lib/ext. Maybe it will work if you put the
> Exception in both
> jars (goo.jar and foo.jar).
>
Ingo, thanks for your suggestions! After placing the exception class
into
it's own jar file and placing that file into the $JBOSS_HOME/lib/ext
directory things worked as they should (i.e. now the exception class
gets loaded from the same CL, an instance of the
javax.management.loading.MLet class, in both the FooBean and the
GooBean). However this workaround is really a non-spec-compliant hack.
Enterprise JavaBeans 2.0, Proposed Final Draft; section 22.3:
"The ejb-jar file must also contain, either by inclusion or by
reference,
the class files for all the classes and interfaces that each enterprise
bean class and the remote and home interfaces depend on, except J2EE and
J2SE classes. This includes their superclasses and superinterfaces,
dependent classes, and the classes and interfaces used as method
parameters, results, and exceptions.".
As far as I can see the "lib/ext" workaround violates section 22.3 in
the EJB spec quoted above.
Ingo's second suggestion is actually identical to the non-working
scenario
described in my initial mail (i.e. both foo.jar and goo.jar contains the
FooException class). This approach also seems to be the one that the EJB
spec tells me to use.
The problem with this approach in JBoss is that JBoss reports an
UndeclaredThrowableException and this behavior does not seem to meet one
of the high-level goals for exception handling stated in the EJB spec:
"17.1.2 Goals for exception handling
The EJB specification for exception handling is designed to meet these
high-level goals:
An application exception thrown by an enterprise bean instance should be
reported to the client precisely (i.e., the client gets the same
exception)."
Is JBoss violating the EJB spec or do I misinterpret the EJB spec?
Regards,
Per
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message and are
hearby notified that any disclosure, copying, or distribution of this
message, or the taking of any action based on it, is strictly prohibited.
