Mac,
These are all excellent points. There are various levels of potential
errors, including a failure to release() in the first place, or more
subtly, an incorrect assumption that release() will be called between
doEndTag() and a subsequent doStartTag().
The spec makes very clear that properties don't have to be set to the same
value twice consecutively on the same Tag instance. A key implementation
principle that follows from this is that tags should treat their
properties as logically "read only" -- that is, doStartTag() should copy
properties if it plans to modify them, since there is no guarantee that
those properties will be reset before the next doStartTag():
a container may implement different pooling stratgies to minimize
creation cost, or may hoist setting of properties to reduce cost
when a tag handler is inside another iterative tag (p. 161)
However, I'm not clear what's supposed to happen when a tag instance is
re-used and the prior invocation needed to specify a property that the
more recent invocation doesn't specify. E.g.,
Use 1: <x:foo a="b" c="d"/>
Use 2: <x:foo a="b"/>
The spec says pretty clearly clearly that
Unspecified attributes/properties should not be set (using a
setter method) (p. 161)
but then how is an instance to know that one of its properties needs to be
"reset"? That is, what's the state of property 'c' in Use 2 above?
(Clearly, whatever happens to be "left over" in an instance from an
arbitrary prior use shouldn't be the default.)
Is this clarified in the spec? (I can't find a clarification, but I have
have missed it.)
Shawn
On Fri, 11 May 2001, Mac Ferguson wrote:
> 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.
