So I am trying the two paths, 1) using WebFault, 2) using AbstractSoapInterceptor to create custom SoapOutInterceptor (for my SEI) and a SoapInInterceptor for clients.
Utilizing #2, I can successfully modify the content in the standard Soap Fault and attach details to that Fault. One the Client side my SoapInInterceptor is part of the unmarshal phase and I can get the original details. My question is, maybe the unmarshal phase is not good, but my SoapInInterceptor (for my service clients) is configured as an inFaultInterceptor, and I notice that if I throw a (custom) RuntimeException out of this Interceptor, it appears to the client as a Soap Fault Exception and not my custom RuntimeException. If I was going down this route, is there a different phase I should use? Or should I register this as a standard inInterceptor as opposed to a inFaultInterceptor so that my custom RuntimeException doesn't get rethrown as a Fault. Thanks for your help and info...it is really beneficial. Jay -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-and-WebFault-Basic-Exception-Question-tp3406924p3408334.html Sent from the cxf-user mailing list archive at Nabble.com.
