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=17836>. 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=17836 bean:write could possibly fail with taglib pooling Summary: bean:write could possibly fail with taglib pooling Product: Struts Version: 1.1 RC1 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] First: "release() is not necessarily called between invocations, which means that tag logic should not count on private invocation-specific state being reset by release()" from: http://jakarta.apache.org/taglibs/guidelines.html (There is a more detailed description of a tag's life cycle at: http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/jsp/tagext/Tag.html ) Looking at the source to WriteTag.java: http://cvs.apache.org/viewcvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java?rev=1.22&content-type=text/vnd.viewcvs-markup You'll see that there are only 3 places where the field "formatStr" is assigned a value, at initilization, setFormat(String), and release(). This potentially becomes a problem when you use the bean:write with taglib pooling in the following way: <bean:write name="someDate" format="EEE MM/dd"/> [... and then later on ...] <bean:write name="someDate" formatKey="someDateKey"/> Because in the formatValue(Object) method there is the following statements: String formatString = formatStr; if( ( formatString==null ) && ( formatKey!=null ) ) [....] and in the case of the same taglib being pooled in the second usage formatStr could retain it's old value of "EEE MM/dd" which will prevent the expression from evaluating to true which will prevent the formatKey from being used to look up the desired format. The fix that takes the least amount of effort is to call relase at the end of doEndTag() but this could break classes that subclass WriteTag and implement their own doEndTag() method. I can't come up with a fix that guarentees correct behavior and for sure won't break subclasses. // One way to get the desired behavior, // but could cause unexpected behavior for subclasses public int doEndTag() throws JspException { int r = super.doEndTag(); release(); return r; } Looking at NestedWriteTag.java I'm sure the above code sample could cause problems. You could set formatStr to null when formatKey has been set to a value and vice versa. Skimming the source to a bunch of taglibs I think any taglib that has a property and the a property that is a key to look up a value could have this problem with pooling. The most common being the use of alt/altKey and title/titleKey in the html taglib package. I haven't checked page/pageKey and src/srcKey but they look suspect too. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
