axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: [Axis2] Mapping SOAP faults to Axis Fault
Date Mon, 31 Oct 2005 10:50:07 GMT
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

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

      <env:Text xml:lang="en">Sender Timeout</env:Text>

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=''
   <env:NotUnderstood qname='abc:Extension1'
                    xmlns:abc='' />
   <env:NotUnderstood qname='def:Extension2'
                    xmlns:def='' />
      <env:Text xml:lang='en'>One or more mandatory
        SOAP header blocks not understood

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.


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?

View raw message