On Wednesday 03 December 2008 6:10:25 pm Aaron Mulder wrote:
> On Wed, Dec 3, 2008 at 5:07 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> > 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.
>
> Aha!  That's the spec reference I was unable to find!  Thanks! :)  It
> does seem to extend a bit beyond that, though -- I tried defining a
> separate property get/setNestedException of type Exception (in
> addition to the Cause of type Throwable), and that seemed to be
> omitted too.  Oh, well.

Well, that's also because the objects for all the things that get mapped must 
be objects that JAXB can handle.   JAXB cannot handle "Exception".

About the only thing you can do is create a little JAXB object that would 
capture the data you want.  Something like:

class NestedException {
    String className;
    String message;
    List<String> stackTrace;
    NestedException nested;
....
}

and add a method to your Exception that would do:

public NestedException getNestedException() {
     NestedException n = new NestedException();
     n.setMessage(getCause().getMessage());
     .....
     return n;
}

JAXB can handle that so the data could get mapped.  (will need a setter as 
well, but the setter could do nothing)

Dan


> On Wed, Dec 3, 2008 at 5:18 PM, Rao, Sameer V <[EMAIL PROTECTED]> wrote:
> > 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?
>
> As it happens, all the usage of this particular service is within one
> company.  And when something goes wrong, the service developers want
> the consumers elsewhere within the company to be able to give them a
> stack trace or other information directly, rather than just "please go
> look in your logs around 3 PM" or whatever.  Plus it seems to help
> with debugging during development.  So in this case, those concerns
> outweigh the pureness of service orientation.  I guess you might argue
> they should attach an e-mail appender to their log system...  Not sure
> how that would be received.  :)
>
> Thanks,
>       Aaron



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

Reply via email to