dev@jax-ws.java.net

Re: Splitting Handler processing into two pipes

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 28 Dec 2005 10:11:30 +0100

Kohsuke Kawaguchi wrote:
>
> CC-ing Roberto to clarify the close method semantics.
>
> Bobby Bissett - Javasoft wrote:
>
>>> I'm also curious what aspect of handler processing makes such
>>> splitting difficult. So if you could shed some light in this area,
>>> that would be great.
>>
>>
>> It would be a little ugly. Even without any exceptions or handlers
>> returning false, consider the client receiving a response. First the
>> soap handlers are called, then the logical handlers, then close() is
>> called again on the soap handlers, then close() is called on the logical
>> handlers. So we'd switch from one pipe to another 3 times during an
>> inbound response or inbound one-way request (which can be even more
>> complicated because we may not know that it's one-way until after the
>> handlers execute). If there are any exceptions or if a handler returns
>> false, then there are other situations where the switching occurs.
>
>
> I see, so the close method of protocol handlers need to be invoked after
> the processing of logical handlers are done?
>

That is my understanding (line 4 page 94):

- Conformance (Order of close invocations): Handlers are invoked in the
reverse order that they appear in the handler chain.


> I'm reading the relevant part of the spec, and I wonder if that's really
> a requirement. If the goal is to let handlers clean up any per-MEP
> resources, wouldn't it be OK to call the close method on protocol
> handlers at the point where we won't be calling any of them any more?
> --- namely when the processing leaves the protocol handler pipe?
>
> Unless we expect someone to write both protocol handler and logical
> handler that interacts with each other, I'm not sure why the close
> method invocation timing matters.
>

That could be a possibility. For example a logical handler could add
something to the message context that is picked up by the protocol
handler to encode/decode that someting in a protocol specific manner.

Why can't we just lump logical and protocol handlers together as one
pipe that is the first in the pipe line?

This might have the unintended consequence that the protocol handlers
are not aware of WS-* stuff. Is this a problem?

Paul.

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109