I think i lean towards glen on this one. -- dims
On Sat, 19 Mar 2005 17:26:48 -0500, Glen Daniels <[EMAIL PROTECTED]> wrote: > 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 > >>>>>> > >>>>>> > >>>> > >>>> > > > -- Davanum Srinivas - http://webservices.apache.org/~dims/
