cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@googlemail.com>
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 <dkulp@apache.org>:
>
> 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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>

Mime
View raw message