You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Eduardo Pelegri-Llopart <Ed...@Sun.COM> on 2001/05/11 18:41:14 UTC
Re: JSP 1.2 tag pooling Bug in utility:for which may affect (many?)
other tags...
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.
Re: JSP 1.2 tag pooling Bug in utility:for which may affect (many?)
other tags...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 11 May 2001, Eduardo Pelegri-Llopart wrote:
> 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.
>
Likewise. I got bit on some incorrect assumptions when Struts tags
started getting used in containers that pool tag instances as well.
> 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.
In fact, part of that clarification was some lifecycle diagrams that make
these issues much more understandable. In the JSP 1.2 PFD2 spec, check
out pages 164, 168, and 178.
> Also, I believe that Tomcat is about to acquire tag
> pooling.
It's work in progress.
>
> - eduard/o
>
Craig
> >
> > 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.
>