axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Graham" <sggra...@us.ibm.com>
Subject RE: Proposed Modification: AxisFault
Date Wed, 21 Feb 2001 21:39:45 GMT
Section 4 of the SOAP spec says:
"faultcode
The faultcode element is intended for use by software to provide an
algorithmic mechanism for
identifying the fault. The faultcode MUST be present in a SOAP Fault
element and the faultcode
value MUST be a qualified name as defined in [8], section 3. SOAP defines a
small set of SOAP
fault codes covering basic SOAP faults (see section 4.4.1)"

So the faultcode must be a qname.  This seems obvious from the spec, am I
missing something?

++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
Web Services Architect
Emerging Internet Technologies
++++++++


James Snell <jmsnell@intesolv.com> on 02/21/2001 02:46:46 PM

Please respond to axis-dev@xml.apache.org

To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:  RE: Proposed Modification: AxisFault



All of the examples and implementations available don't prefix the fault
codes.  The assumption then would be that only user defined fault codes
should be namespace qualified (prefixed)

- James

> -----Original Message-----
> From: MURRAY,BRYAN (HP-FtCollins,ex1) [mailto:bryan_murray@hp.com]
> Sent: Wednesday, February 21, 2001 10:40 AM
> To: 'axis-dev@xml.apache.org'
> Subject: RE: Proposed Modification: AxisFault
>
>
> James,
>
> Do the SOAP faults defined by the spec need to be written as follows:
>    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
>       <s:Body>
>          <s:Fault>
>             <faultCode>s:Server</faultCode>
>          </s:Fault>
>       </s:Body>
>    </s:Envelope>
>
> or is the namespace prefix NOT required in the value portion
> of <faultcode>?
> I have not seen any examples that include the namespace
> prefix, I think all
> of the examples in the spec use the default namespace. How
> does this extend
> to user defined faults?
>
> Bryan
>
> -----Original Message-----
> From: James Snell [mailto:jmsnell@intesolv.com]
> Sent: Wednesday, February 21, 2001 9:19 AM
> To: 'axis-dev@xml.apache.org'
> Subject: RE: Proposed Modification: AxisFault
>
>
> Doug,
>
> Comments inline:
>
> > -----Original Message-----
> > From: Doug Davis [mailto:dug@us.ibm.com]
> > Sent: Wednesday, February 21, 2001 3:51 AM
> > To: axis-dev@xml.apache.org
> > 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">
>       <Body>
>          <Fault>
>             <faultCode>B:MyError.BlahBlah</faultCode>
>          </Fault>
>       </Body>
>    </Envelope>
>
> 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: http://www.w3.org/TR/SOAP/#_Toc478383510 ]
> {emphasis added}
> <snip>
> 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
> "http://schemas.xmlsoap.org/soap/envelope/". 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
> right.
> </snip>
> -----------------------------------------------------------
>
>
> > >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
>



Mime
View raw message