I use a fault called OperationFailedFault, and set its payload to the root
exception's message:
try {
context.commitChanges();
} catch(Exception e) {
context.rollbackChanges();
throw new OperationFailedFault(e.getMessage(), "Commit failed",
e);
}
On Fri, Mar 7, 2008 at 4:05 AM, Glen Mazza <[EMAIL PROTECTED]> 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
>
>
>
