In general, the "jaxws" way of doing this is to map the runtime exceptions to a very generic soap fault that is fault code SERVER and just the message (ex.getMessage()) is set into the fault message.
On the client side, this ends up throwing the generic SOAPFaultException (but with the correct message set). Basically, if you use a declared exception (wsdl:fault), you can have a properly typed exception on both sides. If you don't use a declared exception, you basically just get very generic stuff on the wire and on the client side. Dan On Friday 07 March 2008, Glen Mazza wrote: > Hello, I have a general question for WSDL design regarding internal > web service errors not the fault of the SOAP client request, such as > "database unavailable" or "system down" or whatever. > > For example, let's say I have a simple "GetCapital" web service that > takes a country and returns the name of its capital. One obvious > user-instigated error is providing a country name that doesn't exist. > Such a wsdl operation might be: > > <wsdl:operation name="GetCapital"> > <wsdl:input message="tns:GetCapitalRequest" /> > <wsdl:output message="tns:GetCapitalResponse" /> > <wsdl:fault message="tns:InvalidCountryNameFault" > name="InvalidCountryNameFault" /> > </wsdl:operation> > > But what about exceptions due to the internal service-side errors not > the fault of the SOAP client request (e.g., database being down, JNDI > lookup not functioning, etc.) In this case, do I add an additional > wsdl:fault (perhaps "InternalServiceErrorFault") to each > wsdl:operation or is there a generic error handling mechanism in > JAX-WS that would not require me to burden each wsdl:operation with > this additional fault? > > Thanks, > Glen -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
