DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16808>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16808 Jasper makes calls to tag setters that 1.2 spec says it doesn't have to Summary: Jasper makes calls to tag setters that 1.2 spec says it doesn't have to Product: Tomcat 4 Version: 4.1.8 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The JSP 1.2 specification, in section JSP.10.1, titled "Simple Tag Handlers", in a subsection titled "Properties", has the following statement: 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). I've discoverered Tomcat is not taking advantage of the fact that it doesn't need to call the setter method again on the reused tag handler. Following this is a simple excerpt from my test case, using Struts and Struts-EL. I find that the "setValue()" method is called on the first iteration, which is expected, but it is also called on the second iteration, which is not necessary. <logic-el:iterate collection="${testbean.stringArray}" id="foo" indexId="ctr"> <td> <html-el:text name="testbean" property="stringIndexed" value="${foo}" indexed="true"/> </td> </logic-el:iterate> This might be considered just an optimization issue, but the lack of this optimization led me down an unfortunate road, due to a mistake I made. I wrote all of the tag classes in the Struts-EL library under the mistaken assumption that I could safely modify attribute values. Making this assumption made it very convenient, as I could subclass from the Struts tag classes, and just use the getter/setter methods for the attributes in the base class, without having to add redundant attributes to the derived class. After the container calls the setter on the attribute (say with a value of "${foo}"), in the "doStartTag()" of the Struts-EL tags, I use the JSTL EL engine to evaluate the attribute value and send it back to the setter method of the attribute. This works fine in Tomcat, which made me confident that I had followed all the rules, as I know that Tomcat is the reference implementation of the specification. Unfortunately, the Resin web container takes advantage of this optimization, so that reused tag handlers won't get the setter methods called, so the attribute values will be the same as what I got from running the EL engine on the initial instance, making the page and tag library quite broken. I know how to fix this in my tag library, but it will require a lot of straightforward coding. >From one point of view, this should only be considered an enhancement, but I think this is a little different from other optimization opportunities. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
