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 dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
