--Glen
Anne Thomas Manes wrote:
How about this approach:
We follow WS-I BP guidelines by default, but we permit users to override those defaults using switches (rather than the other way around).
In other words -- if you don't specify any extra switches, java2wsdl generates a WS-I compliant WSDL document.
Anne
On Sat, 19 Mar 2005 10:21:03 -0500, Glen Daniels <[EMAIL PROTECTED]> wrote:
Hi Anne:
Actually, both SOAP 1.1 and SOAP 1.2 *explicitly* allow zero or more "detail entry" elements inside <detail>, and Axis 2 should definitely support this (as Axis 1 does). When using a WSDL 1.1 fault binding, it is true that there should be only a single part (like there is only a single element in WSDL 2.0), but that part definition simply defines a distinguished detail entry - it doesn't prevent other ones. Axis 1 uses this facility to send things like stack traces inside the detail in parallel with the actual data-bound XML for the specific fault type.
If WS-I BP specifies a particular restriction such as "only one child", that's fine and we can put in a check for such a thing, but only when we have a "BP compliance" flag which is switched on.
Thanks, --Glen
Anne Thomas Manes wrote:
I'm talking about SOAP 1.1.
And no. The detail element may not have more than one child element. Faults do not have parameters. They must follow the rules of document/literal. Therefore the detail element may contain only one child element. That child element may have any number of attributes and/or child elements.
So this is correct:
<soap:Body xmlns:ns="urn:myFault"> <soap:Fault> <faultcode>soap:Client</faultcode> <faultstring>Something went wrong</faultstring> <detail> <ns:myFault> <ns:reasonCode>123<ns:reasonCode> <ns:moreInfo>blah blah<ns:moreInfo> </ns:myFault> </detail> </soap:Fault> </soapBody>
But this is not:
<soap:Body xmlns:ns="urn:myFault"> <soap:Fault> <faultcode>soap:Client</faultcode> <faultstring>Something went wrong</faultstring> <detail> <ns:reasonCode>123<ns:reasonCode> <ns:moreInfo>blah blah<ns:moreInfo> </detail> </soap:Fault> </soapBody>
On Sat, 19 Mar 2005 10:02:51 +0600, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
Ok. Is this what SOAPFault detail should be. (Remember current impl is still SOAP 1.1 compliant only, not SOAP 1.2).
SOAPFault MAY have only on detail element. That detail element can have any number of children.
Is that ok ?
If that's the case, I just will have to provide a method to add detail entries to detail element and change if (detailElement != null) block to return detail element.
-- Eran Chinthaka
-----Original Message----- From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] Sent: Saturday, March 19, 2005 2:02 AM To: [email protected] Subject: Re: [Axis2]Doubt on Detail Element in SOAPFault
The <detail> element should have one child element.(That element may have as many attributes and child elements as you like.) When you specify the fault message, it should have at most one part, and it should reference an element defined in your types section. Faults must be encoded using document/literal.
- Anne
On Thu, 17 Mar 2005 15:47:47 +0530, Shahi, Ashutosh <[EMAIL PROTECTED]> wrote:
Hi Guys,
Looking at the SOAPFaultImpl class of the OM implementation gives me the feeling that the fault can have only one detail entry kind
of
information. In the setDetailInformation method I see that each time we create a new detailElement and add the passed detail node as child to
it.
Also getDetailInformation assumes that detailElement has only one child
as I
see it returning a single node instead of an iterator.
The general structure in Axis 1.2 is that we have a Detail Node which
can
have > 1 detail entry element. The SOAP spec says the same. Is it that
we
are restricting the user to create only one detail entry element in OM
or am
I missing something?
Ashutosh
