This post gives a solution that has been given in numerous other locations and the solution is even fairly obvious, but I needed a location to record it, so here it is.

Recently Gerard Davison at Oracle UK detailed the JAX-WS @SchemaValidation tag.

The default behaviour of Oracle's WebLogic Server 10.3 on receiving a SOAP payload that doesn't conform to the WSDL/XSDs in a JAX-WS endpoint method with the @SchemaValidation annotation is to throw a SOAP fault.

Under SOAP 1.1 the SOAP fault payload returned to the client includes a faultcode, faultstring, faultactor (optional) and detail (optional) component.

Under SOAP 1.2 the SOAP fault includes a Code, Reason, Node (optional), Role (optional) and Detail (optional) component.

Assuming SOAP v1.2, given the @SchemaValidation annotation and invalid SOAP payload, we may see the following SOAP result from our JAX-WS web service:


(Click the picture to expand it)

As you can see the SOAP 1.2 fault includes the Code, Reason and Detail components. As can also been seen the Detail component includes the full Java stack trace(I've snipped the stack trace for brevity).

It may be undesirable to return the complete Java stack trace in the SOAP fault and you may wish to turn this off. If you look closely at the error message the answer in how to do this is revealed. Effectively we need to configure the WLS server to include the following option on startup:

-Dcom.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace=false

For WLS 10.3 this entry should be included in your startWebLogic.cmd file.

For a standalone WLS this file is found under:

<WLS_HOME>/user_projects/domains/<YOUR_DOMAIN>/bin

For the integrated WLS within JDeveloper 11g it's found under:

<JDEV_HOME>\system\system11.1.1.0.31.51.88\DefaultDomain\bin

Locate the following entry in the startWebLogic.cmd file:

set JAVA_OPTIONS=%SAVE_JAVA_OPTIONS%

..and change it to:

set JAVA_OPTIONS=-Dcom.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace=false %SAVE_JAVA_OPTIONS%

On restarting the WLS server, and reinvoking the web service with an invalid SOAP payload, the SOAP fault will now look like: