Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <3C2EE81A.E3BB6D76@distributopia.com>
Date: Sun, 30 Dec 2001 04:10:34 -0600
From: "Christopher K. St. John" <cks@distributopia.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: StandardPipeline and ThreadLocal
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


 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 cks@distributopia.com
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>