axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <>
Subject [jira] [Updated] (AXIS2-5836) AxisFault class (used by MessageContextBuilder to create SOAPFault) not SOAP version-independent?
Date Sun, 23 Apr 2017 14:04:04 GMT


Andreas Veithen updated AXIS2-5836:
    Fix Version/s:     (was: 1.7.5)

> AxisFault class (used by MessageContextBuilder to create SOAPFault) not SOAP version-independent?
> -------------------------------------------------------------------------------------------------
>                 Key: AXIS2-5836
>                 URL:
>             Project: Axis2
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.7.4
>            Reporter: Jeff Thomas
> 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.
> {code}
> // SOAP 1.1
> AxisFault axisFault = new AxisFault(APPL_QNAME, "reason", ex);
> // SOAP 1.2
> AxisFault axisFault = new AxisFault(SOAP12Constants.QNAME_RECEIVER_FAULTCODE, "reason",
> axisFault.setFaultSubCodes(Arrays.asList(APPL_QNAME);
> {code}
> 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