Jim, I am asking for a global switch that turns WS-I compliance on. We can decide even at the last minute for this to be the default. Please see the ACTUAL details of the discussions:
> >>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. I don't want our API to constrained by the fact there there *SHOULD* be only one "detail entry" element as per WS-I when SOAP clearly allows more than one. -- dims On Sun, 20 Mar 2005 10:00:05 -0500, Jim Murphy <[EMAIL PROTECTED]> wrote: > Let me make sure I'm hearing this right cause I don't believe what I'm > hearing. Seems like defaulting to the most interoperable configuration > while providing options for other approaches/optimizations is a no brainer. > > Can I ask: what is the motivation for not adopting the philosophy that if > you specify nothing you get a plain vanilla WS-I BP compliant service? > > Jim Murphy > Mindreef, Inc > > > -----Original Message----- > > From: Davanum Srinivas [mailto:[EMAIL PROTECTED] > > Sent: Sunday, March 20, 2005 1:31 AM > > To: [email protected] > > Subject: Re: [Axis2]Doubt on Detail Element in SOAPFault > > > > 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/ > > > > -- Davanum Srinivas - http://webservices.apache.org/~dims/
