Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.7.4
-
None
-
None
Description
Not sure if this is a "bug" or if our implementation approach was incorrect.
The AxisFault class (I assume) was originally constructed as a SOAP version-independent container for fault-information.
The MessageContextBuilder, based upon the MessageContext should use the correct SOAPFactory implementation (1.1 or 1.2) to assemble the SOAPFault body from the generic fault-information.
The SOAP 1.1 Standard says that SOAPFaults may have a user-defined primary fault-code and contains no sub-codes.
The SOAP 1.2 Standard says that SOAPFaults may only have one of 5 pre-defined primary fault-codes and that the application-specific fault-codes are to be assigned as sub-codes.
The problem is, for this code to work correctly today I must know which SOAP Version I am targeting when I set the fault-code (and optionally sub-codes) on the new AxisFault object. As such the AxisFault class is no longer truly SOAP version-independent.
// SOAP 1.1 AxisFault axisFault = new AxisFault(APPL_QNAME, "reason", ex); // SOAP 1.2 AxisFault axisFault = new AxisFault(SOAP12Constants.QNAME_RECEIVER_FAULTCODE, "reason", ex); axisFault.setFaultSubCodes(Arrays.asList(APPL_QNAME);
If all of our exception-classes extend AxisFault and we don't have the MessageContext available at the point at which we throw the exception, then we are not in a position to decide whether or not the current operation is SOAP 1.1 or 1.2.
We currently have a "workaround" (hack?") which always sets the fault-code of our exceptions to QNAME_RECEIVER_FAULTCODE and in the MessageContextBuilder a custom patch that assumes that if the operation context is SOAP 1.1 and subcodes are set on the AxisFault, that the first subcode is the real application fault-code and all others subcodes are discarded. However, I am pretty sure this is not the correct approach.
My feeling is that the AxisFault class is no longer as version-independent as it needs to be with the introduction of SOAP 1.2 special-handling. However, looking at the code, I am not sure if it even possible to generically achieve this.
Alternatively I am not sure if the decision to extend AxisFault for our custom exceptions was the correct choice or if we should have rather caught our custom exceptions in the service-call (where we have the MessageContext) and then build the appropriate generic AxisFault based on whether or not the call is for SOAP 1.1 or 1.2.