"Mohan Kishore" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Hi, > > Was looking at the the JSP spec (also posted in the mailing list some time back): > > "All properties of a tag handler instance exposed as attributes will be initialized by the container using the appropriate setter methods before the instance can be used to perform the action methods. It is the responsibility of the JSP container to invoke the appropriate setter methods to initialize these properties. It is the responsability of user code, be it scriptlets, JavaBeans code, or code inside custom tags, to not invoke these setter methods, as doing otherwise would interfere with the container knowledge. > ... > 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. User code can access property information and access and modify tag handler internal state starting with the first action method (doStartTag) up until the last action method (doEndTag or doFinally for tag handlers implementing TryCatchFinally)." > > (1) Doesn't this go against the way 'nested' library is designed? At the very least, shouldn't the tags cache a snapshot of property values at the beginning of doStartTag() and restore at the end of doEndTag()?
I believe these tags are OK. (Disclaimer: I am by no means a nested tags expert!) In effect, the nested tags do cache the property values, as you suggest they should, just not in the way you might expect. The caching is being done by setProperty(), but only if that method is being called by the container, and resetting of the original value is being done as the first thing in doStartTag(). > > (2) When is the release() method supposed to be called? Not very clear from the spec. Will the instance be reused after doEndTag() or after release() has been called? The container has two options: 1) It can elect to call release() after every call to doEndTag(). In this case, it cannot make any assumptions about the state of the tag handler the next time it elects to use the same instance. This is less efficient, because all of the setters will need to be invoked the next time the instance is reused. The last time I looked, this is what Tomcat 4.x does. 2) It can elect to call release() only when it is about to destroy the tag handler instance. In this case, the container can make use of knowledge of the attributes, and their values, which were used the last time the tag handler instance was used. Resin 2.1.x works this way. > > (3) When the spec refers to the properties being 'persistent', would i be correct in assuming that container does not need to set it, only when the existing value is the same as one it would be set to, OR does it mean that once set the property values are final? The former - you are correct. I found the section on Lifecycle, on page 163 of the JSP 1.2 spec, and the accompanying diagram on page 164, very helpful when I was trying to get my head around this. -- Martin Cooper > > regards, > Mohan. > > > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]