Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 92257 invoked from network); 8 Jan 2003 02:19:21 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 8 Jan 2003 02:19:21 -0000 Received: (qmail 24962 invoked by uid 97); 8 Jan 2003 02:20:39 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 24942 invoked by uid 97); 8 Jan 2003 02:20:38 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 24926 invoked by uid 98); 8 Jan 2003 02:20:38 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) From: "Dimitry Ivanov" To: "'Jan Luehe'" Cc: Subject: RE: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag Date: Wed, 8 Jan 2003 05:24:12 +0300 Message-ID: <001301c2b6bd$0892ae60$077a0a0a@juliet> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200301080108.h0818AM04675@ha1sca-mail1.SFBay.Sun.COM> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Jan, I'm not agree. :) In accordance to spec JSP.10.2.2 (BodyTag): "If EVAL_BODY_INCLUDE is returned, then evaluation happens as in IterationTag." The scripting variable synchronization is part of evaluation, isn't it? I think, if container doesn't synchronize scripting variables it explicitly conflicts with quoted requirement. On the other hand, if container synchronizes scripting variables after skipped invoke to doInitBody, it doesn't conflict with spec. Substantiation: Again JSP.10.2.2: "If EVAL_BODY_INCLUDE is returned, setBodyContent() is not invoked, doInitBody() is not invoked, the body is evaluated and "passed through" to the current out, doAfterBody() is invoked and then, after zero or more iterations, doEndTag() is invoked." There is nothing about skipping variable synchronization. And JSP.10.5.9: "The scope value for a variable implies what methods may affect its value and thus where synchronization is needed: - for NESTED, after doInitBody and doAfterBody for a tag handler implementing BodyTag, and after doStartTag otherwise. - for AT_BEGIN, after doInitBody, doAfterBody, and doEndTag for a tag handler implementing BodyTag, and doStartTag and doEndTag otherwise." There is nothing about synchronization *only* when doInitBody has *invoked*. I think it means the *state* not the action. When call to doInitBody skipped (doStartTag returned EVAL_BODY_INCLUDE) "After doInitBody" *state* comes just after doStartTag call. Dimitry -- P.S. Excuse me for my not ideal English. :( -----Original Message----- From: Jan Luehe [mailto:Jan.Luehe@Sun.COM] Sent: Wednesday, January 08, 2003 4:08 AM To: dimitry@dimitry.ru Cc: tomcat-dev@jakarta.apache.org Subject: Re: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag Dimitry: I still believe your patch is invalid, as it would amount to synchronizing AT_BEGIN and NESTED variables after calling doStartTag(). However, the spec explicitly mentions that for tag handlers implementing BodyTag, those variables must not be synchronized after doStartTag(), *only* after doInitBody(). When I run your example (without applying your patch), I get this result: doStartTag returns EVAL_BODY_INCLUDE null 2nd 3rd doStartTag returns EVAL_BODY_BUFFERED 1st 2nd 3rd The reason your are getting "null" in the case of doStartTag() returning EVAL_BODY_INCLUDE is that in this case, doInitBody() is not called, hence no synchronization. However, if doStartTag() returns EVAL_BODY_BUFFERED, doInitBody() is being called, and therefore synchronization does take place. Please let me know if you disagree. Jan -- To unsubscribe, e-mail: For additional commands, e-mail: