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=23523>. 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=23523 Improper use of release() method in custom tags (e.g. <logic:messagesPresent>) Summary: Improper use of release() method in custom tags (e.g. <logic:messagesPresent>) Product: Struts Version: 1.1 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] There are many implementations of the release() method on the various custom tags that are delivered with Struts. We have reason to believe that they are meant to reset the state of a tag after it has been used. However, the release() method "can and should be used to release any long-term resources" [jakarta.apache.org/taglibs/guidelines.html] and is not guaranteed to be called between invocations of the custom tag. See also http://nagoya. apache.org/bugzilla/show_bug.cgi?id=16001 for a discussion on release() in the JSP specification. The following JSP reproduces the problem with the <logic:messagesPresent> tag <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %> <%@ page import="org.apache.struts.action.ActionErrors, org.apache.struts.action.ActionError, org.apache.struts.Globals" %> <% ActionErrors errors = new ActionErrors(); errors.add("password", new ActionError("error.password.required")); request.setAttribute(Globals.ERROR_KEY, errors); %> <html> <body> <logic:messagesPresent message="false"> 1. invocation </logic:messagesPresent> <logic:messagesPresent message="true"> 2. invocation </logic:messagesPresent> </body> </html> To test this you of course need to add the error.password.required key to the ApplicationResources.properties file and make sure this resource bundle is loaded before you call the above JSP. First time this JSP is called (we've tested it with Tomcat 4.1.24 and 4.1.27) it will correctly display "1. invocation". Second time however it won't display anything! The reason is that Tomcat is pooling custom tags (from what we could tell only tag invocations that use the same attributes will share an instance) and the release() method is not called between invocations. This is the code where it fails: protected boolean condition(boolean desired) throws JspException { ActionMessages am = null; if (message != null && "true".equalsIgnoreCase(message)) name = Globals.MESSAGE_KEY; ... This would fix the problem (other than disabling pooling in Tomcat): protected boolean condition(boolean desired) throws JspException { ActionMessages am = null; if (message != null) { if ("true".equalsIgnoreCase(message)) { name = Globals.MESSAGE_KEY; } else { name = Globals.ERROR_KEY; } } ... However, the member field 'name' is defined in the super class ConditionalTagBase and thus the problem should be fixed there - the resetting should probably happen in the doEnd() method. As mentioned in the beginning this seems to be caused by a general misunderstanding of when the release() method is called so there probably are implications for many other tags as well. The problem persits in the current nightly build. Regards Klaus & Jan www.aragost.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]