Dispatching on SOAPBodyElement vs SOAPAction

[Sam Ruby <ru...@us.ibm.com>]

IIRC, dispatching exclusively on SOAPAction was a temporary solution to
prove the concept.

What I would like to do for the moment is to switch this back to the
namespace and localpart of the SOAPBodyElement, just like xml-soap does.
Ultimately we can provide flexibility to route based on either or the value
of HttpServletRequest.getServletPath() or whatever, but for now, I would
like to keep this simple and compatible.

The immediate problem I am trying to solve is to allow decoding to take
place despite the presence of handlers (e.g., the DebugHandler) being
placed in the chain prior to the HTTPAction handler.

Any objections?

- Sam Ruby

Re: Dispatching on SOAPBodyElement vs SOAPAction

[Rob Jellinghaus <ro...@unrealities.com>]

At 08:31 AM 5/21/2001 -0400, Sam Ruby wrote:
>What I would like to do for the moment is to switch this back to the
>namespace and localpart of the SOAPBodyElement, just like xml-soap does.
...
>Any objections?

No, please do.  There may, though, be no namespace on the SOAPBodyElement,
so be ready for that.  (It is allowed for there to be no specified
SOAPBodyElement namespace -- Glen and I looked at this this weekend.  I
imagine in that case the best thing is simply to dispatch on the localpart.)

>The immediate problem I am trying to solve is to allow decoding to take
>place despite the presence of handlers (e.g., the DebugHandler) being
>placed in the chain prior to the HTTPAction handler.

I ran into this when implementing my TCPActionHandler, which basically
filled out the target service by "peeking ahead" at the body element.  The
TCPActionHandler would wind up causing the whole message to be parsed
(clearly the wrong thing but it worked as a temporary solution).  However,
a subsequent handler (namely, the DebugHandler!) would die because there
was nothing left to parse.

The incredibly ugly workaround was to add a gratuitous 
    String test = (String)msgContext.getRequestMessage().getAs("String");
at the end of my handler.  This more or less reset the message to allow
subsequent handlers to reparse.  It is also unbelievably ugly.

Last week's IRC chat had a lot of discussion about how to pass a SAX stream
down the handler chain.  I know Glen has been thinking a lot about that.
Seems like that's the next sticky issue....

(and I'm keeping my nose out of that one :-)
Cheers,
Rob