[Axis2] Mapping SOAP faults to Axis Fault

[Thilina Gunarathne <cs...@gmail.com>]

 Hi Devs,
What is the way to Map a SOAP 1.2 fault to an Axis Fault. In Kandula 2
implementation we use a exception hierarchy which has the ability to capture
the SOAP 1.2 fault details like FaultCode ,FaultSubcode, FaultReason and
FaultDetail. But when I try to map these in to AxisFualt I found that it
cannot contain anything except for FaultDetail and FaultCode.
 Can't we come with an API like the following (ofcourse with setters) for
the AxisFualt so that we'll be able to map the SOAP fault much
cleanly.Justa suggestion....
public abstract String getFaultCode();

public abstract String getFaultSubcode();

public abstract String getFaultReason();

public String getFaultDetail()

Thanks and regards,

~Thilina


--
"May the SourcE be with u"
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/ http://www.bloglines.com/blog/Thilina

Re: [Axis2] Mapping SOAP faults to Axis Fault

[Steve Loughran <st...@apache.org>]

Thilina Gunarathne wrote:
>  Hi Devs,
> What is the way to Map a SOAP 1.2 fault to an Axis Fault. In Kandula 2
> implementation we use a exception hierarchy which has the ability to capture
> the SOAP 1.2 fault details like FaultCode ,FaultSubcode, FaultReason and
> FaultDetail. But when I try to map these in to AxisFualt I found that it
> cannot contain anything except for FaultDetail and FaultCode.
>  Can't we come with an API like the following (ofcourse with setters) for
> the AxisFualt so that we'll be able to map the SOAP fault much
> cleanly.Justa suggestion....

> public abstract String getFaultCode();

  -may be a qname

> 
> public abstract String getFaultSubcode();

-this is a recursive value/subcode where value is definately a wname

> 
> public abstract String getFaultReason();

multiple text strings w/ language tags

> public String getFaultDetail()

surely this should be abitrary XML

I'm looking at the faults and want to stick something in there myself, 
with the SOAP1.2 sample faults being what I'd run through it as a unit 
test, like this one 
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#faultcodes

If any of this information is lost or cannot be created in source, then 
something is wrong.

   <env:Fault>
    <env:Code>
      <env:Value>env:Sender</env:Value>
      <env:Subcode>
       <env:Value>m:MessageTimeout</env:Value>
      </env:Subcode>
    </env:Code>
    <env:Reason>
      <env:Text xml:lang="en">Sender Timeout</env:Text>
    </env:Reason>
    <env:Detail>
      <m:MaxTime>P5M</m:MaxTime>
    </env:Detail>
   </env:Fault>
  </env:Body>


SOAP1.2 faults are mildly complex, and then there is the problem of 
headers too. If we were soap1.2 only, then I'd just reuse some of the 
datatypes in there and instead of a mapping from axisfault to a 
soapfault, have AxisFault be a SOAPFault. But its harder than that as 
(a) we need to think about SOAP1.1, and (b) a lot of the elements I'd 
create dont like being created without a parents.

Thus I'm looking more at having a set of types that map 1:1 with the 
SOAPFault types

  fault.Subcode  //can be used for subcode
  fault.Code extends Subcode //subcode with different value restrictions
  fault.ReasonEntry   //text+language

AxisFault needs to suppport these, arbitrary XML in the detail and a set 
of headers. That leaves conversion to/from SOAPFault1.1/1.2.

Header support is important so that axis2 can generate proper 
notUnderstood faults, or ws-a bad-address ones. e.g.

<?xml version="1.0" ?>
<env:Envelope xmlns:env='http://www.w3.org/2003/05/soap-envelope'
               xmlns:xml='http://www.w3.org/XML/1998/namespace'>
  <env:Header>
   <env:NotUnderstood qname='abc:Extension1'
                    xmlns:abc='http://example.org/2001/06/ext' />
   <env:NotUnderstood qname='def:Extension2'
                    xmlns:def='http://example.com/stuff' />
  </env:Header>
  <env:Body>
   <env:Fault>
    <env:Code><env:Value>env:MustUnderstand</env:Value></env:Code>
    <env:Reason>
      <env:Text xml:lang='en'>One or more mandatory
        SOAP header blocks not understood
      </env:Text>
    </env:Reason>
   </env:Fault>
  </env:Body>
</env:Envelope>

Again, SOAP versions cause trouble. Should the code raising a 
not-understood fault have to know which soap version the caller used? 
right now, they probably do have to

This is a background task to me; I really want WS-BaseFault handling and 
enhancing Axis2 faulting is a precursor. I'll see how far I have got 
this week.  The key point is this: SOAP1.2 faults are complex and full 
of useful info we don't want to lose.

-Steve

Incidentally, what should happens if we recieve a fault on a SOAP1.2 
call and turn it into an AxisFault and then try and rethrow it on a 
SOAP1.1 connection?