The first thing that pops into my head when I see the Pipeline pattern (and read Craig's [PROPOSAL] Tomcat 4.0-beta API Change: Valve APIs post), is something along the lines of the psuedocode at the end of the message.
The semantics are subtly different from the current StandardPipeline, but I think only in bizarre cases like if a Valve spawned a thread and then both threads tried to call invokeNext on the same ValveContext. It's not like the existing code is exactly broken, but the use of ThreadLocal is certainly a little unexpected. It violates the "avoid suprising code" rule. (Well, it suprised me, anyway) Do the semantics differ in some other way that makes the implementation below incorrect? (Ignore bugs, you get the idea) If not, would whoever's responsible for that code be willing to accept a patch to get rid of the ThreadLocal? class ValveContext { Pipeline p; int i; public void invokeNext(req, rsp) { if (i==p.valves.length) if (p.basic) v = p.basic; else v = p.valves[i++]; if (!v) throw exception; v.invoke(req, rsp, this); } } class StandardPipeline { Vector valves = new Vector(); Valve basic; public void invoke(req, rsp) { ctx = new ValveContext(0, this); ctx.invokeNext(req, rsp); } } -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>