OK,
I'm convinced. It seems to me that there is no way for the RI to know
whether an MU=1 handler has been properly processed, so the best call it
to assume it is properly processed so long as I have a handler chain
registered for it. Unless the SOAP spec is clearer on this (and I
haven't looked at 1.2 closely enough to know), there's not much else
that can be done.
> Hmmm... that may be the version, or maybe just which tool was used. I
> was using jwsdp-1.2 and generating server code with wscompile and
> received an error. If you didn't even get a warning, that may
> be a place
> we should add in some kind of message. I'll look into it some more.
I'll also check again. I'm using the current release (1.2), and I'm sure
this was the behaviour I was seeing.
Thanks again Bobby,
Kevin Jones
Developmentor
www.develop.com
> -----Original Message-----
> From: Bobby Bissett - Javasoft [mailto:robert.bissett_at_sun.com]
> Sent: 09 October 2003 18:40
> To: users_at_jax-rpc.dev.java.net
> Subject: Re: Handling mustUnderstand Headers
>
>
> >
> >>It
> >>just may be that there are cases where doing the wrong thing in a
> >>handler (leaving "actor" header elements in the message)
> doesn't cause
> >>problems.
> >
> > Sure - seems like a bug in the RI though - it should be
> consistent. I
> > either need to detach headers or I don't.
>
> The short answer: you always need to detach headers, except when you
> don't <grin>. That's basically the contract of an intermediary and a
> header processed by it.
>
> I think the RI is consistent, though it just might be my way
> of looking
> at it. If a header comes in to a chain that should be understood but
> isn't, you get a fault. If a header comes in to a chain that
> either is
> understood or can be ignored, you don't get a fault. It works
> the same
> way with the endpoint, whether the message came through a
> chain first or
> not.
>
> Here's another way to view this idea of having the implementation do
> some checking: imagine you have a handler that declares that it
> understands a certain header, but the handleRequest() method simply
> returns true and does nothing else. Is that an error? It will be if
> there's no "contract" with someone else down the line to handle it,
> otherwise it won't be. There's no way for the runtime to know
> this kind
> of thing without adding another layer of complexity to a
> situation that
> I don't think needs it (you *do* get an error from the
> runtime -- it's
> the MustUnderstand fault from the endpoint in our original case).
>
> I can see that it would be nice to have some way to tell the
> users that
> they forgot to detach the node, as that's a small point in
> the SOAP spec
> and is something that I think everyone will forget to do at
> least once
> (I've done it), but I just don't see an easy way to produce a
> DidntDetachNodeException instead of the MU fault that can
> result instead.
>
> >
> > [...] it
> > should then say, did something process this (by detaching
> the header).
>
> Processing a header does not necessarily imply detaching it,
> since you
> can leave in a "similar" header according to the SOAP spec. So the
> concept of checking to see if headers were removed doesn't solve the
> problem. (Also, checking the messages headers after each
> handler would
> be some more overhead.)
>
> > It may be, for example, that the handler understood the
> header element
> > and not the details, it can't throw an exception because
> the actor is
> > registered for a chain *not* a single handler, so something
> further down
> > may understand this header. If nothing removes the header
> then throw and
> > exception and process the response chain.
>
> I know I'm repeating myself, but I didn't want to leave out
> your example
> here. Just as a small point, a handler can throw an exception
> any time
> it likes, so there may be cases where you declare that you
> understand a
> header element but then don't understand the data. Anyway, per your
> example, handler1 may not understand the header but can just
> ignore it
> as it goes by, and then handler2 can process it and detach
> it. But there
> may be cases where you don't want to detach it, primarily if
> there's a
> contract with the endpoint to put in a "similar header." So
> if the impl
> did a check and threw an exception for you, it would limit
> things that
> you ought to be able to do (and therefore be noncompliant
> with the SOAP
> spec). If your handler does the wrong thing, the error you get is the
> fault from the endpoint.
>
> >
> > Again we may be talking at cross-purposes but messages with
> MU=1 and an
> > actor are *not* passed to a handler chain if the chain has not
> > registered interest in those handlers (through getHeaders)
>
> Yep -- if the chain says that it plays the role of the actor
> in question
> but it can't do what the message wants it to do, then a fault
> is thrown
> and no further processing occurs. Same thing with endpoint.
>
> >
> > That's not what I'm seeing. If I have two chains defined in
> > jaxrpc-ri.xml, like this:
>
>
> Cheers,
> Bobby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net