axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Snell <>
Subject RE: Proposed Modification: AxisFault
Date Wed, 21 Feb 2001 17:19:14 GMT

Comments inline:

> -----Original Message-----
> From: Doug Davis []
> Sent: Wednesday, February 21, 2001 3:51 AM
> To:
> Subject: Re: Proposed Modification: AxisFault
> James wrote:
> >1. AxisFault rename to AxisException.  I'd much prefer to keep with
> >standard conventions on naming Exception classes.
> >Not that big of a deal though ;-)
> Agreed - it's not a big deal.  I think we landed on Fault 
> because that's
> the term used in the SOAP spec but either will do.

As Steve says, "a naming rant".

> >2. The current AxisFault class models the faultCode attribute as a
> >string.  I'd like to propose that we actually change this to a QName
> I don't understand this desire to make everything XMLish.  
> This sort of
> came up yesterday in the IRC when we talked about service 
> names.  These
> are just strings - yes they *can* be qualified and there's nothing
> stopping people from doing it - but why must we force a structure on
> it?  Are we going to do something with the sub-parts of the QName or
> are we going to always treat it as a string anyway? I was under the
> impression that we were going to do Fault chain searching by string
> matching,
>   ie.  MyFaultChain1 is called when AxisException="server.*"
> Yes this could be done using QName, but it just seem easier to use a
> simple string.  If we introduce this structure, what happens 
> if someone
> wants to have more than 2 parts, are we implying that they can't or
> that they then must force their multi-part names into a 2 part name?
> Unless someone can come up with a compelling reason for adding this
> complexity (IMO) other than just to be XMLish I'd like to -1 this.

Not to be "XMLish", but to support SOAP's extensible fault code mechanism.
The four SOAP Fault codes (Server, Client, MustUnderstand and
VersionMismatch) belong to the SOAP Envelope namespace, however, SOAP allows
for new top level fault codes to be defined within other namespaces.  In
other words, something like this would be legal (at least in my
interpretation of the SOAP specification)

   <Envelope xmlns:B="urn:MyNamespace">

Now, we could do it so that everything is done with Strings, but then how do
we avoid conflicts?  
My goal here is 100% support of the SOAP specification.

[Reference: ]
{emphasis added}
The faultcode values defined in this section MUST be used in the faultcode
element when describing faults defined by this specification. The namespace
identifier for these faultcode values is
"". Use of this space IS
RECOMMENDED (BUT NOT REQUIRED) in the specification of methods defined
outside of the present specification. 
The default SOAP faultcode values are defined in an extensible manner that
allows for new SOAP faultcode values to be defined while maintaining
backwards compatibility with existing faultcode values. The mechanism used
is very similar to the 1xx, 2xx, 3xx etc basic status classes classes
defined in HTTP (see [5] section 10). However, instead of integers, THEY ARE
DEFINED AS XML QUALIFIED NAMES (see [8] section 3). The character "." (dot)
is used as a separator of faultcode values indicating that what is to the
left of the dot is a more generic fault code value than the value to the

> >3. We remove all reference to DOM in the AxisFault class.  
> This would mean
> >nix'ing the
> >getAsDOM method and the Details attribute would need to be Object[]
> >instead of
> >Element[] .
> Would we replace it with getAsString instead?  Who's going to 
> convert the
> Exception into XML?  And if we do have a getAsString, wouldn't it be
> faster to just have it return the XML directly instead of as a string
> and then have to parse it to get it as XML?  I'm ok with removing the
> DOM stuff from it but it has to perform.  How did you see 
> this working?

Later this week I will be posting my proposal for the Message API, part of
which has mechanisms for transforming AxisFault information into a protocol
implementation specific representation of the Fault.  Basically, it will be
the job of the MessageWriter to package the fault information into XML or
whatever the packaging protocol in use requires. 

> -Dug

- James

View raw message