> Use 1: <x:foo a="b" c="d"/>
> Use 2: <x:foo a="b"/>
.....
> 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.)
The container cannot use in "Use 2" the tag handler instance it used for
"Use 1". There is no way to return a value to "default".
In practice this should not have a significant performance impact.
Hope this helps,
- eduard/o
Shawn Bayern wrote:
>
> 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.
