Hans Bergsten wrote:
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).
Ok, thanks for clarifying this.
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.
Like the last paragraph... =)
Is this the way the Jasper tag pooling is implemented?
As far as I have seen, yes.
Sorry for asking, I should have (did actually) checked myself...
Hans
__________________________________________________________________________
This message and its attachments have been found clean from known viruses with three different antivirus programs.
__________________________________________________________________________
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
