Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 18780 invoked from network); 20 Mar 2005 01:57:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Mar 2005 01:57:53 -0000 Received: (qmail 906 invoked by uid 500); 20 Mar 2005 01:57:42 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 872 invoked by uid 500); 20 Mar 2005 01:57:42 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 858 invoked by uid 99); 20 Mar 2005 01:57:41 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from eero.baz.org (HELO eero.baz.org) (12.130.29.202) by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 19 Mar 2005 17:57:40 -0800 Received: by eero.baz.org (Postfix, from userid 1017) id 3E01F36F17; Sat, 19 Mar 2005 17:26:48 -0500 (EST) Received: from [192.168.0.5] (psc.progress.com [192.233.92.200]) by eero (tmda-ofmipd) with ESMTP; Sat, 19 Mar 2005 17:26:46 -0500 (EST) Message-ID: <423CA728.9050903@thoughtcraft.com> Date: Sat, 19 Mar 2005 17:26:48 -0500 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: axis-dev@ws.apache.org Subject: Re: [Axis2]Doubt on Detail Element in SOAPFault References: <200503190409.j2J49dgQ025167@squid.cmb.ac.lk> <423C435F.2060101@thoughtcraft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Glen Daniels X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 wrote: > >>Hi Anne: >> >>Actually, both SOAP 1.1 and SOAP 1.2 *explicitly* allow zero or more >>"detail entry" elements inside , 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:Client >>> Something went wrong >>> >>> >>> 123 >>> blah blah >>> >>> >>> >>> >>> >>>But this is not: >>> >>> >>> >>> soap:Client >>> Something went wrong >>> >>> 123 >>> blah blah >>> >>> >>> >>> >>> >>>On Sat, 19 Mar 2005 10:02:51 +0600, Eran Chinthaka >>> 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:atmanes@gmail.com] >>>>>Sent: Saturday, March 19, 2005 2:02 AM >>>>>To: axis-dev@ws.apache.org >>>>>Subject: Re: [Axis2]Doubt on Detail Element in SOAPFault >>>>> >>>>>The 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 >>>>> 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 >>>>>> >>>>>> >>>> >>>> >