On Thu, Dec 4, 2008 at 5:28 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> 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".
OK, thanks.
Aaron
> 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
>
>
