cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <glen.ma...@verizon.net>
Subject Re: Proposal: Interceptor Listeners
Date Wed, 07 May 2008 03:18:44 GMT
-0.5, I guess, but no veto.  Interceptors seem to function similarly to
listeners, they are called when something happens, so I'm unsure of the
need for a separate listener construct.  There was a change a couple of
months back allowing for duplicate interceptors (multiple interceptors
of the same class being inserted in the chain)--might this take away the
need for listeners?

"I wanted some timing diagnostics to determine the time certain
interceptors were taking to process the message. Another use case can be
some custom logging before and after each interceptor." -- Can
interceptors before and after that interceptor do that logging for you?

Also, is there much of a risk of users putting business logic in the
listeners instead of the interceptors?  That would presumably be an
antipattern, because if you have business logic in listeners, it would
follow that you would then need to have listenerListeners for *those*
listeners, and then this might never end.  Also, how bad would the
performance impact be due to interceptors needing to check each time for
listeners whenever an interceptor is doing processing (which could add
up with lots of web service calls)?

Another idea perhaps, is to remove the Interceptor argument from the
InterceptorListener methods below.  That allows you to do your timing
without concern for business logic getting into the listeners.

Finally, CXF is Spring based--is there anything out of the box that can
be done with AOP so we don't need to come up with our own listeners?

Regards,
Glen


2008-05-06 Bharath Ganesh wrote:
> I was thinking of a way to register listeners with CXF interceptors. The use
> case I ran into was:
> I wanted some timing diagnostics to determine the time certain interceptors
> were taking to process the message. Ideally I would register a
> TimingListener with such interceptors. Another use case can be some custom
> logging before and after each interceptor.
> 
> Listener can be as simple as-
> 
> public interface InterceptorListener
> {
>     void preHandleMessage(Interceptor interceptor);
> 
>     void postHandleMessage(Interceptor interceptor);
> 
>     void preHandleFault(Interceptor interceptor);
> 
>     void postHandleFault(Interceptor interceptor);
> }
> 
> How about building such a feature into the Interceptor framework? Any
> thoughts?


Mime
View raw message