This is easily reproducible on EAP 5.1.0 and EAP 5.0.1 (JBossWS Native 3.1.2) - Using Sun's WS Stack the exception is returned correctly by the client. Create a client that returns a String value "\uffff" - the client stub will have null. See attached file.

The workaround is to add a client side handler. If the issue is with the fact that you want to differentiate between an error (invalid SOAP response) and a null (valid response) then this workaround is fine because an additional exception is thrown by the handler when trying to read the SOAP message. If it is invalid you will get the error "Cannot convert exception to fault message".

When a JBoss Web Services (WS) client sent a response containing an invalid character, it returned null rather than raising an exception. The expected behaviour was that the client stub throw the following exception: <computeroutput>javax.xml.ws.WebServiceException</computeroutput>. The only error reported, logged to <systemitem>stderr</systemitem>, was as follows: <screen> ERROR [STDERR] [Fatal Error] :2:1462: An invalid XML character (Unicode: 0xffff) was found in the element content of the document. </screen> A system property <parameter>org.jboss.ws.IgnoreParseError</parameter> can now be set on the client side using JBossWS to allow exceptions to be propagated back to the client instead of returning <computeroutput>null</computeroutput>. If this property is not set then <computeroutput>null</computeroutput> as it was previously.