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]>
