cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: best practice for setting order constraints among interceptors
Date Wed, 17 Aug 2011 09:42:58 GMT
Hi Dan,
thanks for the very good explanation about its history and its evolution theory.
regards, aki

2011/8/16 Daniel Kulp <>:
> For the most part, I don't think it really matters.  There used to be some
> performance issues adding interceptors that had a bunch of befores and afters,
> but those were pretty much resolved. Also, with the chain caching we do, such
> interceptors aren't added very ofter.
> THAT said, if you start seeing a lot of interceptors with a bunch of
> addBefore/Afters, etc... that may be a good indication that we should split
> the phase into two phases.   The PRE_PROTOCOL phase got really bad at one
> point and for 2.4, we split it to ease the issues.    With the number of
> interceptors in PRE_STREAM, that may be a good indication that we should add a
> phase in there.  Maybe add a TRANSFORM_STREAM phase where StaxOut and others
> that "transform" the stream from InputStream type things to XMLStreamWriter
> things would live.   (FIStax, TransformOut, etc....)
> Dan
> On Tuesday, August 16, 2011 6:51:19 PM Aki Yoshida wrote:
>> Hi,
>> If you have two interceptors A and B that go into the same phase and
>> additionally you want to make sure A must precede B, you can either
>> write
>> addBefore(B) in A's constructor
>> or
>> addAfter(A) in B's constructor.
>> But is there a good rule for deciding which one to choose?
>> The concrete case that I have is for LoggingOutInterceptor and
>> TransformOutInterceptor.
>> They both go into PRE_STREAM..
>> LoggingOI should wrap the output stream before anyone start using it,
>> so it must precede any Stax based interceptors. That means we have the
>> order:
>> LoggingOI < TransformOI < StaxOI
>> Initially, I added this constraint in the constructor of TransformOI
>> as I was fixing another issue of this class.
>> addBefore(StaxOI)
>> addAfter(LoggingOI).
>> But later I thought, it might have been more readable to put this
>> constraint in the LoggingOI as
>> addBefore(StaxOI)
>> addBefore(TransformOI).
>> to indicate LoggingOI must precede any known Stax based interceptors.
>> Maybe, this is a stupid question. But if someone has a strong opinion
>> in one way or the other. I am interested in hearing it.
>> Thanks.
>> regards, aki
> --
> Daniel Kulp
> Talend -

View raw message