cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unreal Jiang <sinbad_...@yahoo.com>
Subject RE: When should we close the handlers in CXF?
Date Thu, 18 Jan 2007 11:43:47 GMT
Hi Eoghan,
  I think those two approach are work fine.
  
  The first approach is only for handlers process,
  The second approach can do some clean-up works not only for handlers  but interceptors,
 but if we use runnable object for  TerminalAction,  the order of handlers or interceptors
will be  hard to ensure.
  
  So I incline to  the second approach, but we should use some other way to instead of runnable
object.
  
  Regards
  Unreal

"Liu, Jervis" <jliu@iona.com> wrote:I  would vote for the second approach. When its
there, we can probably use  the similiar approach to remove the sub-chain (interceptor chain
 reentrance) wherever it is possible. 

________________________________

From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
Sent: Wed 1/17/2007 9:42 PM
To: cxf-dev@incubator.apache.org
Subject: RE: When should we close the handlers in CXF?





> -----Original Message-----
> From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> Sent: 17 January 2007 12:34
> To: cxf-dev@incubator.apache.org
> Subject: RE: When should we close the handlers in CXF?
>
>
> Hi Unreal,
>
> One point to note is that all the other JAX-WS Handler touch
> points are driven through a set of interceptors, each
> wrapping a chain of a particular Handler type (logical,
> protocol etc.).
>
> So for example the SOAPHanderInterceptor takes care of calling the
> handleMessage/Fault() methods of any SOAPHandlers in the chain.
> Similarly there's a *separate* LogicalHandlerInterceptor that
> traverses the chain of LogicalHandlers. I'm guessing you
> already know all this ...
>
> But the point is that it would be a good idea to maintain the
> pattern of wrapper-interceptor calling out to JAX-WS Handler,
> and obviously it would be badness to for example put this
> JAXWS-specific logic into the ClientImpl code.
>
> However, because Handler.close() should only be called at the
> very *end* of the interceptor chain tarversal, and because we
> currently have
> *multiple* interceptors wrapping the JAX-WS Handler chains of
> various types, the close() call should not be made from
> within the existing wrapper interceptors. Otherwise we'd end
> up with for example close() called prematurely on the
> SOAPHandlers *before* the LogicalHandlers have even been
> traversed (inbound on the client-side).
>
> So we'd need a *single* new wrapper interceptor, positioned
> at the end of the in & fault-in interceptor chains, that's
> responsible for calling
> close() on all types of handler. This could be driven via a
> pattern similar to the
> LogicalHandlerInterceptor.onCompletion() method (e.g. the new
> interceptor walks back along the chain to find the
> LogicalHandlerInterceptor & SOAPHandlerInterceptor and calls
> onCompletion() on these).

On second thoughts, maybe a cleaner may of doing this would be allow an
interceptor to register some sort of terminal action with the
InterceptorChain to be executed when the chain traversal is complete,
e.g.

public interface InterceptorChain {
    void addTerminalAction(Runnable r);

    //...
}

Or alternatively take the Runnable as a return value from
Interceptor.handleMessage/Fault().

Then in the InterceptorChain impl, run all the TerminalAction(s) from a
finally block, e.g.

public class PhaseInterceptorChain {
   public boolean doIntercept(Message m) {
       try {
           while (interceptorIterator.hasNext()) {
               interceptorIterator.next().handleMessage(m);
           }
       } finally {
           for (Runnable r : terminalActions) {
               r.run();
           }
       }
   }
}

Then for example the LogicalHandlerInterceptor.handleMessage() would end
with some logic like:

   if (isRequestor(message) && (isOneway(message) ||
!isOutbound(message))) {
      message.getInterceptorChain().addTerminalAction(new Runnable() {
          public void run() {
              getInvoker(message).mepComplete(message);
          }
      }
   }

Similarly for SOAPHandlerInterceptor etc.

Cheers,
Eoghan




 
---------------------------------
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message