Return-Path: 
 <taglibs-dev-return-1961-apmail-jakarta-taglibs-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-taglibs-dev-archive@jakarta.apache.org
Received: (qmail 90688 invoked by uid 500); 11 May 2001 16:42:51 -0000
Mailing-List: contact taglibs-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: taglibs-dev@jakarta.apache.org
list-help: <mailto:taglibs-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:taglibs-dev@jakarta.apache.org>
Delivered-To: mailing list taglibs-dev@jakarta.apache.org
Received: (qmail 90678 invoked from network); 11 May 2001 16:42:49 -0000
Received: from patan.sun.com (192.18.98.43)
  by h31.sny.collab.net with SMTP; 11 May 2001 16:42:49 -0000
Received: from shorter.eng.sun.com ([129.144.124.35])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04555
	for <taglibs-dev@jakarta.apache.org>; Fri, 11 May 2001 09:42:49 -0700 (PDT)
Received: from eng.sun.com (d-ucup02-251-124 [129.144.251.124])
	by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id
 JAA16020
	for <taglibs-dev@jakarta.apache.org>; Fri, 11 May 2001 09:42:49 -0700 (PDT)
Message-ID: <3AFC162A.4ABB90C5@eng.sun.com>
Date: Fri, 11 May 2001 09:41:14 -0700
From: Eduardo Pelegri-Llopart <Eduardo.Pelegrillopart@Sun.COM>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: taglibs-dev@jakarta.apache.org
Subject: Re: JSP 1.2 tag pooling Bug in utility:for which may affect (many?)
 other tags...
References: <NFBBLADJEKBLEPMOLDIPGEEGCDAA.mferguson@communicopia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

Mac Ferguson wrote:

> The behaviour which results from tag instance pooling should be a
> consideration in the development and testing of all of the Jakarta
> Taglibs tags.

100% agree.

We spent a fair amount of energy in JSP 1.2 to clarify the semantics of
tag pooling because it can make a significant difference in some
applications. Also, I believe that Tomcat is about to acquire tag
pooling.

	- eduard/o 

> 
> Hi folks,
> I'm hoping to open up some discussion on an important subject. I recently
> D/L'ed the new beta of Resin servlet engine (2.0.b2), which implements a
> custom-tag instance-pooling scheme, and right away I found that some of my
> JSPs which use the utility:for tag were behaving unexpectedly. I had a test
> page which called utility:for 3 times in succession:
> 
> <util:for iterations="3" begin="0" varName="index">
>         <%= index%> : <br />
> </util:for>
> <br />
> <util:for iterations="3" begin="0" varName="index">
>         <%= index%> : <br />
> </util:for>
> <br />
> <util:for iterations="3" begin="0" varName="index">
>         <%= index%> : <br />
> </util:for>
> 
> which previously looped from 0-2 three times,  produced the following output
> under Resin:
> 
> 0
> 1
> 2
> 3
> 
> 4
> 
> 5
> 
> on examining the source for the tag and several explanations of the
> tag-pooling and spec from the creator of Resin I found the following
> problems. The tag initializes its state when it's instance variables are
> declared as follows:
> 
> public class ForTag extends BodyTagSupport {
> 
>     private int iterations;
>     private String varName = "_count";
>     private int begin = 0;
> etc...
> 
> Theoretically tags should be stateless, so these default values should be
> being assigned in the doStartTag() method not in instance variable
> declarations. Another part of the spec which was pointed out to me indicates
> that successive calls to the same tag with the same attribute values may not
> trigger the setter methods, here's the quote from the spec:
> 
> "From the spec,  JSP 10.1, "Once properly set, all properties are expected
> to be
> persistent, so that if the JSP container ascertains that a property has
> already
> been set on a given tag handler instance, it needs not set it again.""
> 
> which once again implies that if any instance-specific initialization needs
> to be done in a tag, it should be done in doStartTag() or some submethod
> which will be called on every use of the tag instance.
> 
> My first thought was that release() should be implemented to reset state,
> but the comments for the lifecycle diagram on page 165 of the spec indicate
> that release is "intended to be for relleasing long-term data" and there is
> no guarantee that properties are retained or not.
> 
> I know that this problem may seem remote and Resin-specific right now, but I
> suspect that tag pooling will show up in the next release of almost every
> servlet engine, as it is the next logical efficiency which can be optimized
> in the servlet/JSP architecture. The behaviour which results from tag
> instance pooling should be a consideration in the development and testing of
> all of the Jakarta Taglibs tags.