axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d..@us.ibm.com
Subject RE: DO NOT REPLY [Bug 10660] - <responseFlow/> traps Axis
Date Fri, 12 Jul 2002 13:48:43 GMT

You'd rather throw an exception than make the user's experience with Axis
easier?  <sigh>
-Dug


Glen Daniels <gdaniels@macromedia.com> on 07/12/2002 09:44:03 AM

Please respond to axis-dev@xml.apache.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) about  that
too.  Right now we're just interpreting <responseFlow> as if the  elements
inside it were minOccurs="1", which after some  consideration I think is
fine, and the WSDD schema should reflect  that.

Essentially I'm -0 on this.  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] - <responseFlow/> traps Axis



three  reasons - one, <responseFlow/> 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 as
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
<requestFlow/> 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'"  <axis-dev@xml.apache.org>
cc:
Subject: RE: DO NOT  REPLY [Bug 10660] - <responseFlow/> traps  Axis




Doug:

Why is this  important, come to think of it?  Why can't we say that
content-free  <requestFlow/> 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] -  <responseFlow/> traps Axis
>
>
> DO NOT REPLY TO THIS  EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB  INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10660>.
>  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=10660
>
>  <responseFlow/> traps Axis
>
> dug@us.ibm.com  changed:
>
>            What     |Removed                      |Added
>  --------------------------------------------------------------
>  --------------
>               Status|RESOLVED                     |REOPENED
>           Resolution|FIXED                        |
>
>
>
> ------- Additional  Comments From dug@us.ibm.com  2002-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.   If you look at
> the code what's happening is we notice a  <responseFlow/> element and
> then try to create a chain from  that.  The result is an empty chain
> which is why the:
>     if (handlers.isEmpty())
> returns true and throws a fauly.   But, 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> element at all.  If 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.
>


Mime
View raw message