Johan Åbrandt wrote:
Hans Bergsten wrote:
Tim Moore wrote:
This bug seems to be submitted several times a week. Maybe an FAQ would
be in order? (or FOB -- frequently opened bugs haha)
Then again, if people don't search the bug database before submitting a
new one, then I guess they can't be expected to read the FAQ.
And on the other hand, if the spec confuses this many people, maybe that
should be fed back to the spec authors. Just adding a "reset" method to
Tag that is called before each invocation might help people understand
the difference between that and release.
I'm in the EG and we had a long discussion about this again for JSP 2.0.
The end result is that the current behavior (do _not_ call release()
between invocations) will stay. A confusing arrow from the "released"
state to the "initialized" state in the state diagram will be removed,
however. This state transition came with lots and lots of restrictions,
but it seems like some vendor (and developers) saw it as a requirement
to call release() between invocations, even though the text clearly
state that that's not the case.
This is being discussed pretty much everywhere these days and I hope
people eventually will get it. I wrote about it in an article just
after JSP 1.2 was released. Feel free to point people to it if you
get tired of rehashing the same arguments over and over ;-)
<http://www.onjava.com/pub/a/onjava/2001/11/07/jsp12.html>
Page 2, the "Tag handler life cycle and instance reuse" section
If I understand the section Hans directs to correctly, re-use of a
pooled tag is only allowed if the tags have the same set of attributes:
"A tag handler instance can only be reused for an occurrence with the
same set of attributes."
Where in the specification (JSP 1.2) is this specified? Is it derived
from section 10.3?, or is it mentioned explicitly somewhere else?
See JSP.10.1.1 in the JSP 1.2 spec:
Methods
There are two main actions: doStartTag and doEndTag. Once all
appropriate properties have been initialized, the doStartTag and
doEndTag methods can be invoked on the tag handler. Between these
invocations, the tag handler is assumed to hold a state that must
be preserved. After the doEndTag invocation, the tag handler is
available for further invocations (and it is expected to have
retained its properties).
Lifecycle
[...]
* [3] Note that since there are no guarantees on the state of the
properties, a tag handler that had some optional properties set
can only be reused if those properties are set to a new (known)
value. This means that tag handlers can only be reused within the
same "AttSet" (set of attributes that have been set).
I could have sworn it was explicitly stated somewhere else as well,
since bullet [3] is confusing; it's a description of a transition from
"released" to "initialized", which by the way comes with a few more
rules (e.g. the tag handler must recreate long-lived resources it
may have created in its constructor when reused after release()).
For JSP 2.0, however, the "same set of attributes" requirement is
explicitly stated (from an upcoming PFD2):
The JSP container may reuse classic tag handler instances for
multiple occurrences of the corresponding custom action, in the
same page or in different pages, but only if the same set of
attributes are used for all occurrences. If a tag handler is used
for more than one occurence, the container must reset all attributes
where the values differ between the custom action occurrences.
Attributes with the same value in all occurrences must not be reset.
If an attribute value is set as a request-time attribute value (using
a scripting or an EL expression), the container must reset the
attribute between all reuses of the tag handler instance.
Is this the way the Jasper tag pooling is implemented?
As far as I have seen, yes.
Hans
--
Hans Bergsten <[EMAIL PROTECTED]>
Gefion Software <http://www.gefionsoftware.com/>
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at <http://TheJSPBook.com/>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
