Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 91434 invoked by uid 500); 12 Jul 2002 13:48:43 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 91425 invoked from network); 12 Jul 2002 13:48:43 -0000 Importance: Normal Sensitivity: Subject: RE: DO NOT REPLY [Bug 10660] - traps Axis To: axis-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: dug@us.ibm.com Date: Fri, 12 Jul 2002 09:48:43 -0400 X-MIMETrack: Serialize by Router on D04NM204/04/M/IBM(Build M13TT_06062002 Pre-release 2|June 06, 2002) at 07/12/2002 09:48:43 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE167DFD855398f9e8a93df938690918c0ABBE167DFD85539" Content-Disposition: inline X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --0__=0ABBE167DFD855398f9e8a93df938690918c0ABBE167DFD85539 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable You'd rather throw an exception than make the user's experience with Ax= is easier? -Dug Glen Daniels on 07/12/2002 09:44:03 AM Please respond to axis-dev@xml.apache.org To: "'axis-dev@xml.apache.org'" cc: Subject: RE: DO NOT REPLY [Bug 10660] - traps Axis is valid XML too, and yet we complain (correctly) about tha= t too.=A0 Right now we're just interpreting as if the ele= ments inside it were minOccurs=3D"1", which=A0after some consideration=A0I t= hink is fine, and the WSDD schema should reflect that. Essentially I'm -0 on this.=A0 What do others think? --Glen -----Original Message----- From: dug@us.ibm.com [mailto:dug@us.ibm.com] Sent: Friday, July 12, 2002 9:37 AM To: axis-dev@xml.apache.org Subject: RE: DO NOT REPLY [Bug 10660] - traps Axis three reasons - one, is valid XML; two, we programmatically build up a response flow chain and I believe the tool= uses XMLT to do it - it generates an empty responseFlow element when there's nothing to merge - which happens sometimes if the user chooses= to not install everything; and three, its a usability issue - Axis should= try to make it as easy as possible for people to use - which means being a= s forgiving as possible (when possible and of course when it makes sense= ) and that would include removing as many roadblocks to try to create as= much of an "error free" usage of Axis as possible. Disallowing for no good reason other than "we don't want to code it= " is one of those roadblock - IMO. -Dug Please respond to axis-dev@xml.apache.org To: "'axis-dev@xml.apache.org'" cc: Subject: RE: DO NOT REPLY [Bug 10660] - traps Axis Doug: Why is this important, come to think of it? =A0Why can't we say that content-free elements are illegal? --Glen > -----Original Message----- > From: bugzilla@apache.org [mailto:bugzilla@apache.org] > Sent: Friday, July 12, 2002 8:55 AM > To: axis-dev@xml.apache.org > Subject: DO NOT REPLY [Bug 10660] - traps Axis > > > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > . > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND > INSERTED IN THE BUG DATABASE. > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3D10660 > > traps Axis > > dug@us.ibm.com changed: > > =A0 =A0 =A0 =A0 =A0 =A0What =A0 =A0|Removed =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |Added > -------------------------------------------------------------- > -------------- > =A0 =A0 =A0 =A0 =A0 =A0 =A0Status|RESOLVED =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0|REOPENED > =A0 =A0 =A0 =A0 =A0Resolution|FIXED =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | > > > > ------- Additional Comments From dug@us.ibm.com =A02002-07-12 > 12:55 ------- > Dims - while that might get rid of the NPE it doesn't solve > the problem > that an exception was being thrown in the first place. =A0If you loo= k at > the code what's happening is we notice a element and= > then try to create a chain from that. =A0The result is an empty chai= n > which is why the: > =A0 =A0if (handlers.isEmpty()) > returns true and throws a fauly. =A0But, the real solution is that w= e > should not complain about this at all - we should notice that > while there > is a element, is it empty - which should be the same= > things as no element at all. =A0If you walk back up = the > stack you'll see that we blindly assume there will always be a child= > element - which in this case isn't true. > = --0__=0ABBE167DFD855398f9e8a93df938690918c0ABBE167DFD85539 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable
You'd rather throw an exception than make the user's experience with Ax= is easier? <sigh>
-Dug

Please respond to axis-dev@xml.ap= ache.org

To: "= ;'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>=
cc:
Subject: RE:= DO NOT REPLY [Bug 10660] - <responseFlow/> traps Axis
=



<service/> is valid XML too, and yet we complain (correctly) abou= t that too.=A0 Right now we're just interpreting <responseFlow> = as if the elements inside it were minOccurs=3D"1", which=A0a= fter some consideration=A0I think is fine, and the WSDD schema should = reflect that.
=A0
Essentially I'm -0 on this.=A0 What do others think?
=A0
--Glen
-----Original Message-----
From: dug@us.ibm.com [mailto:= dug@us.ibm.com]
Sent: Friday, July 12, 2002 9:37 AM
To: axis-dev@xml.apache.org
Subject: RE: DO NOT REPLY [Bug 10660] - <responseFlow/> t= raps Axis



three reasons - one, <responseFlow/> is valid X= ML; two, we programmatically build up a response flow chain and I beli= eve the tool uses XMLT to do it - it generates an empty responseFlow e= lement when there's nothing to merge - which happens sometimes if the = user chooses to not install everything; and three, its a usability iss= ue - Axis should try to make it as easy as possible for people to use = - which means being as forgiving as possible (when possible and of cou= rse when it makes sense) and that would include removing as many roadb= locks to try to create as much of an "error free" usage of Ax= is as possible. Disallowing <requestFlow/> for no good reason ot= her than "we don't want to code it" is one of those roadbloc= k - IMO.
-Dug

Please respond to axis-dev@xml.apache.org
To: "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org&= gt;
cc:
Subject: RE: DO NOT REPLY [Bug 10660] - <responseFlow/> traps A= xis




Doug:

Why is this  important, come to think of it? = =A0Why can't we say that content-free  <requestFlow/> elemen= ts are  illegal?

--Glen

> -----Original  Message-----<= br> > From: bugzilla@apache.org [mailto:bugzilla@apache.org= ]
>  Sent: Friday, July 12, 2002 8:55 AM
> To:  axis-dev@xml.apache.org=
> Subject: DO NOT REPLY [Bug 10660] -  <= ;responseFlow/> traps Axis
>
>
> DO NOT REPLY TO THIS  EMAIL, BUT PLEASE = POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB  INTERF= ACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3D10660>.
>  ANY REPLY MADE TO THIS MESSAGE WILL NOT= BE COLLECTED AND
> INSERTED IN  THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3D10660
>
>  <responseFlow/> traps Axis=
>
> dug@us.ibm.com  changed:
= >
> =A0 =A0 =A0 =A0 =A0 =A0What =A0  =A0|Rem= oved =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0  =A0 |Added >  ---------------------------------------= -----------------------
>  --------------
> =A0 =A0 =A0 =A0 =A0 =A0  =A0Status|RESOL= VED =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0  =A0 =A0|REOPENED<= br> > =A0 =A0 =A0 =A0  =A0Resolution|FIXED =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0  =A0 =A0 =A0 |
>
>
>
> ------- Additional  Comments From dug@us= .ibm.com =A02002-07-12
> 12:55 -------
>  Dims - while that might get rid of the = NPE it doesn't solve
> the  problem
> that an exception was being thrown in the fir= st place.  =A0If you look at
> the code what's happening is we notice a &nbs= p;<responseFlow/> element and
> then try to create a chain from  that. =A0= The result is an empty chain
> which is why the:
>  =A0 =A0if (handlers.isEmpty())
> returns true and throws a fauly.  =A0But= , the real solution is that we
> should not complain about this  at all -= we should notice that
> while there
> is a  <responseFlow/> element, is = it empty - which should be the same
>  things as no <responseFlow> eleme= nt at all. =A0If you walk back up  the
> stack you'll see that we blindly assume there= will always be a  child
> element - which in this case isn't true.
>  

= --0__=0ABBE167DFD855398f9e8a93df938690918c0ABBE167DFD85539--