Handlers [was: Today's IRC log]

[Doug Davis <du...@us.ibm.com>]

But I'm missing the point about what's different?  Why make the
distinction in the first place?  Unless there's some fundamental
difference between the two handlers I don't see the point.  All we're
doing is introducing terms/concepts/confusion for the sake of
some artificial division.  Like I said, any claim that handler-type-X
should do Y needs to also be made for all other handler types.
-Dug


Glen Daniels <gd...@allaire.com> on 11/29/2000 12:56:08 PM

Please respond to soap-dev@xml.apache.org

To:   "'soap-dev@xml.apache.org'" <so...@xml.apache.org>
cc:
Subject:  RE: Today's IRC log




Sure, I can see this being optional, but if you do want to be able to do it
(and I really do think the engine should work this way by default) you
still
need a way of distinguishing header handlers from the "application"
handler(s).  This could be done in a variety of different ways:

1) Different chains, as I did.
2) A "marker" handler which tells the chain container "ok, header
processing
is now done".
3) A different type of exception which is thrown by header handlers, so it
can be caught and dealt with in a custom way.

I just want to make sure we allow this, and make it easy.

--Glen

> -----Original Message-----
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Wednesday, November 29, 2000 12:25 PM
> To: soap-dev@xml.apache.org
> Subject: RE: Today's IRC log
>
>
> > Glen Wrote:
> > The reason for splitting them out is that there is a
> different semantic
> for
> > processing the header handlers than the others.  For header
> handlers, you
> > want them ALL to run even if some of them generate Faults.
> An example
> would
> > be three orthogonal extensions, each of which wants to put
> its own Fault
> > information into the response.  If you just stopped
> processing at the
> first
> > Fault, you'd have the remote client getting a single Fault,
> fixing the
> > problem, resending the message, getting the next Fault,
> etc...  It's much
> > nicer to just let all the handlers run and combine the
> error information
> > into one response message.
>
> Shouldn't this be optional?  What if a customer really does want it to
> stop after the 1st header that faults? Any argument you make for not
> wanting
> to stop after a header fault could be made for not wanting to
> stop after
> a fault generated by the actual WebService itself  (no matter
> how silly
> we might think it is).  Likewise, I believe that any argument made for
> treating a message handler and a header handler differently
> is just going
> to introduce restrictions on how to use the system and
> ultimately what a
> customer can do.
>
> -Dug
>