axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: [Axis2]Doubt on Detail Element in SOAPFault
Date Sun, 20 Mar 2005 15:48:39 GMT
See the following messages (and the full thread) as well:
- http://groups.yahoo.com/group/soapbuilders/message/10058
- http://groups.yahoo.com/group/soapbuilders/message/10103
- http://groups.yahoo.com/group/soapbuilders/message/10057

And the talk from Nelson:
http://www.windley.com/archives/2005/03/nelson_minar_at.shtml

Yes, we should make it easy to do WS-I stuff in Axis and possibly make
it the default (if there is consensus) BUT that should not stop us
doing what is in the SOAP specs (which was the actual problem we were
talking about originally)

thanks,
dims


On Sun, 20 Mar 2005 10:00:05 -0500, Jim Murphy <jim.murphy@pobox.com> 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:davanum@gmail.com]
> > Sent: Sunday, March 20, 2005 1:31 AM
> > To: axis-dev@ws.apache.org
> > 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
> > <glen@thoughtcraft.com> 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
> > <glen@thoughtcraft.com> 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
> > > >>><chinthaka@opensource.lk> 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 <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
> > > >>>>><Ashutosh.Shahi@ca.com> 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/

Mime
View raw message