Hi Aaron,

>From a technical perspective it would be completely valid expectation to
be able to return the details of the nested exception.
However, from a service orientation point of view, wouldn't it be
preferable to not provide system-specific information/stack trace of you
java packaging etc?

An approach (from a service isolation) would be to log details
-cause/stack trace within the service boundary and return a more service
friendly custom fault?
This is purely from a contract-first (WSDL) approach wherein you might
not want to expose details of underlying implementation? Java or .Net? 

Thanks,
Sameer


-----Original Message-----
From: Daniel Kulp [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 03, 2008 4:07 PM
To: [email protected]
Cc: Aaron Mulder
Subject: Re: Exceptions over SOAP

On Tuesday 02 December 2008 11:34:22 am Aaron Mulder wrote:
> So we have a method that throws a checked Exception, and that one has
> a nested Exception.  I haven't been able to find a way to configure
> things so that the nested Exception is passed to the client (the
> generated schema for the main Exception just does not include any
> elements for the nested Exception).  I've tried setting the cause on
> the main exception, adding a brand new property to hold the nested
> exception, using @XmlSeeAlso to ensure the class of the nested
> Exception class is seen, and none of these work (the generated schema
> just ignores the nested Exception property).  Other properties added
> to the main Exception do show up as expected.
>
> I'm wondering if there's some part of the JAXB or JAX-WS spec that
> says nested exceptions shouldn't be propagated?  Or is there some
> other reason why this behavior is expected?

Well, the jaxws spec does specifically say:  (section 3.7)

The getCause, getLocalizedMessage and getStackTrace getters from 
java.lang.Throwable and the getClass getter from java.lang.Object are 
excluded from the list of getters to be mapped.


Also, JAX-WS kind of overloads the "cause" a bit.   When you throw and 
exception, if the cause is a SOAPFaultException, certain things are
pulled 
from there instead of using defaults.   Things like the fault code,
fault 
string, actor, etc...  will come from that.


-- 
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog

Reply via email to