Uploaded image for project: 'Axis2'
  1. Axis2
  2. AXIS2-5836

AxisFault class (used by MessageContextBuilder to create SOAPFault) not SOAP version-independent?



    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 1.7.4
    • None
    • kernel
    • None


      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);

      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.




            Unassigned Unassigned
            JWT007 Jeff Thomas
            0 Vote for this issue
            1 Start watching this issue