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 <[EMAIL PROTECTED]> 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
> [EMAIL PROTECTED]
> http://www.dankulp.com/blog
>
>
>
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
