axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Thomas (JIRA)" <j...@apache.org>
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
                 URL: https://issues.apache.org/jira/browse/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.

{code}
// 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);
{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
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message