Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@cxf.apache.org
Cc: Aki Yoshida <elakito@googlemail.com>
Subject: Re: best practice for setting order constraints among interceptors
Date: Tue, 16 Aug 2011 13:14:14 -0400
Message-ID: <1446809.7tvjxkcG3q@dilbert.dankulp.com>
User-Agent: KMail/4.7.0  (Linux/3.0.0; KDE/4.7.0; x86_64; ; )
In-Reply-To: 
 <CAF8t5XsBhZtEW1Qu-pvsVR1-Hv7NGP+iBus084y0+TBjUvQ6tg@mail.gmail.com>
References: 
 <CAF8t5XsBhZtEW1Qu-pvsVR1-Hv7NGP+iBus084y0+TBjUvQ6tg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"


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