[
https://issues.apache.org/jira/browse/AXIS2-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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: https://issues.apache.org/jira/browse/AXIS2-5836
> 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", 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-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
