We can probably discuss/vote on this at the upcoming F2F. Myself I will vote -1 to defaulting to BP compliance, because I don't actually think it buys us much except for limiting flexibility (won't allow MTOM, RPC style, etc). However I am certainly willing to go with the majority opinion (and simply keep the "non-BP" switch on for my own projects :)) if it's the other way. Regardless, it should be easy to set a global/environment variable which controls this setting default for the entire system.

--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





Reply via email to