axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Thomas (JIRA)" <>
Subject [jira] [Created] (AXIS2-5836) AxisFault class (used by MessageContextBuilder to create SOAPFault) not SOAP version-independent?
Date Mon, 06 Feb 2017 15:14:41 GMT
Jeff Thomas created AXIS2-5836:

             Summary: AxisFault class (used by MessageContextBuilder to create SOAPFault)
not SOAP version-independent?
                 Key: AXIS2-5836
             Project: Axis2
          Issue Type: Bug
          Components: kernel
    Affects Versions: 1.7.4
            Reporter: Jeff Thomas
             Fix For: 1.7.5

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.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message