DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17270>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17270 Patch to serialize custom exceptions into the detail element of a soap fault Summary: Patch to serialize custom exceptions into the detail element of a soap fault Product: Axis Version: 1.1RC1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Serialization/Deserialization AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Attached is a patch to allow axis to serialize a custom exception into the detail element of a soap fault if there is a registered serializer for it. For example, if you had the following custom exception: class MyException extends Exception { public String getMyContent() { return "blah"; } } with a bean mapping defined for it: <beanMapping languageSpecificType="java:MyException" qname="ex:MyException" xmlns:ex="http://example.com/exceptions"/> then it would be serailzed to the soap fault detail as: ... <detail> <ns1:MyException xmlns:ns1="http://example.com/exceptions";> <myContent xsi:type="xsd:string">blah</myContent> </ns1:MyException> </detail> ... This allows users send custom exceptions over the wire without having to deal with AxisFault directly, as they would have to today. The patch is pretty straightforward. When serializing the detail element of a fault, it checks the detail property of the AxisFault to see if it is wrapping a user's exception. If there is a wrapped exception, then it attempts to look up a serializer for that wrapped exception; if it finds one, it serializes the wrapped exception using it. If there is either no registered serailizer for the wrapped exception, or just no wrapped exception at all, it falls back to the "old way" of serializing the fault detail. Also included in the patch is a one line change to AxisServlet that fixes a bug that I found while testing the patch. The handling of a fault when the servlet was invoked from doGet() was missing a check of the MessageContext before creating a new response message object. The change makes the fault handling in doGet() identical to the (already correct) doPost() behavior.
