> if
> the attribute is left out of the message, then it is intended for the
> ultimate recipient as you wrote. If actors are left out of the config
> files when generating handlers, then the "next" actor is
> assumed for the
> handlers.
Right, this is what I understood from our previous emails
> Really, you should detach those elements as well according to the SOAP
> spec if they're targeted at a header that says it understands them.
Agreed
> 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.
It seems to me that the RI gets things right in the case of the
non-actor headers - it checks just before calling the endpoint that the
headers have been understood, this means the endpoint doesn't execute.
With actor and MU=1 the RI gets things half right. It days, has
something registered an interest in this, if not throw an exception, it
should then say, did something process this (by detaching the header).
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.
> > Except that again the processing of 'actor' headers is
> different from
> > 'next' headers. 'Actor' headers never even get into the processing
> > chain if I have no handler declared as processing them.
>
> Yes, my mistake about the targetting was confusing. "Actor" headers,
> including headers targetted at the "next" actor, will
> definitely cause a
> check to see if they are understood or not (when MU=1), but the whole
> message is still sent into the handler chain. So even if nothing is
> targeted at a handler chain, the message will still go
> through it
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)
> A header element is explicitly targetted at some role, including the
> "next" role, and it has mustUnderstand=1. If the chain includes this
> role, and it does not understand this header type, then an fault is
> thrown. If any of those conditions is not met, then the message is
> processed.
That's what I'm seeing
> Yes, *logically* speaking that is correct. Of course, the
> implementation
> would throw an error that you have two chains on the server
> (I just want
> to be explicit about that!), but setting the roles to "foo"
> would be the
> same as setting them to both "foo" and "next" for the handler.
That's not what I'm seeing. If I have two chains defined in
jaxrpc-ri.xml, like this:
<handlerChains>
<chain runAt="server" roles="
http://kevinj.develop.com urn:uri" >
<handler className="com.develop.SimpleHandler"/>
</chain>
<chain runAt="server" >
<handler className="com.develop.SimpleHandler"/>
</chain>
</handlerChain>
only the second chain is processed. There is *no* indication that two
chains have been (wrongly) defined.
> You may be right that the schema could be more correct, but the error
> checking is done at the actual parsing stage instead of validating
> against the schema. Though documented, the schema is still really more
> of an internal document.
It was the only documentation I could find though :)
Thanks again for looking at this.
I need to go back and play with the 'next' role to confirm that I
understand what I think I understand :)
Kevin Jones
Developmentor
www.develop.com