You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Bharath Ganesh <bh...@apache.org> on 2008/05/06 19:44:21 UTC
Proposal: Interceptor Listeners
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?
Re: Proposal: Interceptor Listeners
Posted by Glen Mazza <gl...@verizon.net>.
-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?
Re: Proposal: Interceptor Listeners
Posted by Christian Vest Hansen <ka...@gmail.com>.
In the event that I have any say in this, if your default
implementations of these methods, say, in a
NullInterceptorChainListener, are the empty methods, then HotSpot will
be able to inline those calls and thereby optimize them out of
existence.
That said, the factory idea have a better feel to it, I think.
On 5/7/08, Daniel Kulp <dk...@apache.org> wrote:
>
> I'm not quite as against the idea as Glen is. I'm more "indifferent" as
> long as performance is completely not impacted.
>
> Also, it's more of an InterceptorChainListener as that would be the one
> calling the methods and the listener is really listening to what the
> PhaseInterceptorChain is doing. Thus, with that in mind, you probably
> would need to add methods like
>
> void interceptorAdded(Interceptor)
> void interceptorRemoved(...)
> void exceptionCaught(Throwable)
> etc....
>
> My major concern is adding a bunch more method calls on the intercepor
> chain path an what impact might that have on performance.
>
> I'm actually wondering if it might make more sense to make the creation of
> the PhaseInterceptorChain objects somehow more pluggable and allow
> subclasses or something that could do that. The default would be our
> normal implementation, but you could plugin a different
> LoggingPhaseInterceptorChain or something that could perform worse. That
> said, creating the chains via a factory or something could have just as much
> of a performance impact or something. Not really sure.
>
> I might need to think about this some more though and could easily be
> convinced one way or another.
>
>
> Dan
>
>
>
>
> On May 6, 2008, at 1:44 PM, 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?
> >
>
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Re: Proposal: Interceptor Listeners
Posted by Bharath Ganesh <bh...@gmail.com>.
Dan,
>I'm actually wondering if it might make more sense to make the creation of
the PhaseInterceptorChain objects somehow more pluggable >and allow
subclasses or something that could do that. The default would be our
normal implementation, but you could plugin a different
>LoggingPhaseInterceptorChain or something that could perform worse
Yes, that sounds good. Another option is to have methods like -
preInvokeInterceptor(Interceptor, Message)
postInvokeInterceptor(Interceptor, Message)
in the PhaseInterceptorChain / InterceptorChain. These method could me
invoked from doIntercept(Message).
Custom implementations of PhaseInterceptorChain could override just these
methods.
On Wed, May 7, 2008 at 9:18 AM, Daniel Kulp <dk...@apache.org> wrote:
>
> I'm not quite as against the idea as Glen is. I'm more "indifferent" as
> long as performance is completely not impacted.
>
> Also, it's more of an InterceptorChainListener as that would be the one
> calling the methods and the listener is really listening to what the
> PhaseInterceptorChain is doing. Thus, with that in mind, you probably
> would need to add methods like
>
> void interceptorAdded(Interceptor)
> void interceptorRemoved(...)
> void exceptionCaught(Throwable)
> etc....
>
> My major concern is adding a bunch more method calls on the intercepor
> chain path an what impact might that have on performance.
>
> I'm actually wondering if it might make more sense to make the creation of
> the PhaseInterceptorChain objects somehow more pluggable and allow
> subclasses or something that could do that. The default would be our
> normal implementation, but you could plugin a different
> LoggingPhaseInterceptorChain or something that could perform worse. That
> said, creating the chains via a factory or something could have just as much
> of a performance impact or something. Not really sure.
>
> I might need to think about this some more though and could easily be
> convinced one way or another.
>
>
> Dan
>
>
>
>
> On May 6, 2008, at 1:44 PM, 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?
> >
>
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
Re: Proposal: Interceptor Listeners
Posted by Daniel Kulp <dk...@apache.org>.
I'm not quite as against the idea as Glen is. I'm more "indifferent"
as long as performance is completely not impacted.
Also, it's more of an InterceptorChainListener as that would be the
one calling the methods and the listener is really listening to what
the PhaseInterceptorChain is doing. Thus, with that in mind, you
probably would need to add methods like
void interceptorAdded(Interceptor)
void interceptorRemoved(...)
void exceptionCaught(Throwable)
etc....
My major concern is adding a bunch more method calls on the intercepor
chain path an what impact might that have on performance.
I'm actually wondering if it might make more sense to make the
creation of the PhaseInterceptorChain objects somehow more pluggable
and allow subclasses or something that could do that. The default
would be our normal implementation, but you could plugin a different
LoggingPhaseInterceptorChain or something that could perform worse.
That said, creating the chains via a factory or something could have
just as much of a performance impact or something. Not really sure.
I might need to think about this some more though and could easily be
convinced one way or another.
Dan
On May 6, 2008, at 1:44 PM, 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?
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog