>
>>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:
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.
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