We tried this. It seems the only way to get exceptions to fire as expected within a client is to:
1. Add @WebFault to the declared Exception subclass 2. Add a simple POJO containing a String message that gets passed in to the custom Exception subclass as we throw that Exception This seems awfully painful given the client stubs actually came out with the expected result before the above was implemented. I also suppose that with a web interface that is both JAX-WS and JAX-RS compliant, the above JAX-WS overhead is required and thus the JAX-RS exception mapping providers must detect and map the POJO into a Response to avoid losing that inner message content held by the exception. Ugly. It does not help that in certain sections of the Internet the @WebFault is being referred to as no longer necessary. I wasn't aware that 2.6 of CXF was overly old so am surprised this has come up. On 15 July 2013 17:39, Mark Streit <[email protected]> wrote: > There is a good article by Eben Hewitt that covers how to get the "business > exception" back "over the wire" here: > > > http://io.typepad.com/eben_hewitt_on_java/2009/07/using-soap-faults-and-exceptions-in-java-jaxws-web-services.html > > > Perhaps that could be of help. > > Mark > > > On Mon, Jul 15, 2013 at 12:27 PM, James Green <[email protected] > >wrote: > > > We have a CXF-based SOAP client here that's started logging errors as a > > result of a catch (Throwable ...) block. > > > > Trouble is, the stack trace shows the error as coming from a business > > exception issued by the server. We're wondering why the catch > > (BusinessException ...) block isn't firing? > > > > Server side we have 2.6.8, client is 2.7.2. The server class is pretty > much > > just a POJO annotated with @WebService and the business exceptions are > pure > > POJOs - I understand CXF these days wraps them up automatically. > > > > Any ideas for investigation welcomed. > > > > Thanks, > > > > James > > >
