Prompted by Mac's comments, I conducted an informal code review and
realized quite how widespread tag-lifecycle misconceptions are. Most tag
developers I know, including myself, have handled things incorrectly at
one point or another. Even the excellent Tag Libraries Tutorial on Sun's
site (http://java.sun.com/products/jsp/tutorial/TagLibrariesTOC.html) has,
in its example of an iteration tag, what seems to be a bug that most
developers have made at least once:
public void setGroup(Collection members) {
if(members.size() > 0)
iterator = members.iterator();
}
This morning, to respond to the problem, I've compiled a short list of
guidelines for tag-handler lifecycle management which I'd like to include
in the Jakarta-Taglibs Tutorial. Here's a first draft. It contains
nothing original, but it attempts to target particular misconceptions and
organize the info from the 1.2 spec that's useful for tag developers.
Any comments?
Shawn
-----
Guidelines for tag lifecycle management:
1) Properties are expected to remain consistent. This means that:
- no user code should call a setXXX() accessor of a tag handler
- the tag handler's code itself should not modify properties that are
set by a setXXX() method
- tag handlers should not perform invocation-specific logic in a
setXXX() method. That is, the setting of a property should
have no side effects.
2) Private, invocation-specific state must be managed manually.
Implications include that:
- release() is not necessarily called between invocations, which
means that tag logic should not count on private invocation-
specific state being reset by release()
- doEndTag() is not necessarily called at the end of every invocation
(in cases of abnormal termination -- e.g., an exception thrown inside
a tag's body or by one of its methods)
- private invocation-specific state is thus best initialized in
doStartTag()
- doFinally() *is* always called for tag handlers that implement
TryCatchFinally, so this method should be used if any invocation-
specific resources need to be released
- release() *is* always called at least once for a tag handler before
it is garbage-collected, so this method can and should be used to
release any long-term resources
Examples:
a) Suppose you have a tag that accepts some sort of expression that you
need to resolve, e.g.:
<show value="$my-expression$"/>
"$my-expression$" should be stored by setValue() and evaluated in
doStartTag(). For the behavior that's almost always desired, it should
NOT be evaluated in setValue().
Similarly, Iterators and Enumarations should not be extracted in a
setXXX() method. setXXX() methods are meant to be "idempotent";
write them so that they can be called multiple times with no
side effects (and, conversely, only once instead of multiple times
if the argument passed is the same).
b) Private state that's kept for each invocation should typically be
reset in doStartTag(), not in release(). If you have an iteration
index controlling the behavior of a loop, doStartTag() is the
appropriate method from which to initialize it.
c) If a tag needs to open a new database connection (or file, or other
external resource) for every invocation, the tag handler should
implement TryCatchFilnally and close the database connection (or
other resource) in doFinally(). doEndTag() might not be called,
and release() might not be called until long after you expect it to be.