That explains it. Bummer. Fortunately I acquired most of the
information I needed by including the nested class' name in the message
part of my replacement EJBException; I suppose if I need it I can always
add the entire stack trace there (or implement something more akin to
the JavaWorld article).
For anyone else interested, here's a link to the JavaWorld article:
http://www.javaworld.com/javaworld/javatips/jw-javatip91.html
Thanks,
Jeff Schnitzer
[EMAIL PROTECTED]
> -----Original Message-----
> From: wim veninga [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, September 30, 2000 9:24 AM
> To: Orion-Interest
> Subject: Re: EJBException.printStackTrace()
>
>
> Hi Jeff,
>
> This is because the stack trace is transient. So it is not
> send over the
> network (even
> in local rmi calls). For example if you have a session that call's an
> entity, and you
> catch an entity exception in the session, the stack trace doesn't hold
> state. I recall an article in javaworld (www.javaworld.com)
> from serverall
> months ago
> explaining how to make exceptions that do provide
> serializable stack trace.
>
> Greetings Wim Veninga.
>
>
>
>
>
> Jeff Schnitzer wrote:
>
> > I've noticed that the printStackTrace() method on
> EJBException doesn't
> > print the trace for the nested exception. This makes debugging
> > exceptions thrown deep within several layers of EJB's calling EJB's
> > difficult.
> >
> > Is this something I should ask the Orion team to fix? Or is it
> > something that Sun needs to take care of?
> >
> > For the moment I suppose I can rip the class file out of
> ejb.jar and add
> > my own EJBException.
> >
> > Jeff Schnitzer
> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
>
>
