DO NOT REPLY [Bug 17173] New: - FormTag lookup() method not reliable due to release() method specification

[bu...@apache.org]

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=17173>.
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=17173

FormTag lookup() method not reliable due to release() method specification

           Summary: FormTag lookup() method not reliable due to release()
                    method specification
           Product: Struts
           Version: 1.1 Beta 3
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Custom Tags
        AssignedTo: struts-dev@jakarta.apache.org
        ReportedBy: kdean@datadevelopment.com


The FormTag lookup() method includes the following code:

// Were the required values already specified?
if (name != null) {
  ...
}

The purpose of this check is to use any values specified in the JSP over and 
above values specified in the deployment descriptor.  The "name" property is 
reset in the release() method, which is expected to be run prior to the next 
invocation of doStartTag(), which calls the lookup() method.

The documentation of the release() method states otherwise, however:

public void release()

Called on a Tag handler to release state. The page compiler guarantees that 
JSP page implementation objects will invoke this method on all tag handlers, 
but there may be multiple invocations on doStartTag and doEndTag in between.

In other words, the tag developer CANNOT rely on the internal properties being 
reset before the next invocation of doStartTag().

This bug manifested itself using Struts 1.0 (not 1.1) with the Tomcat 4.1 
engine integrated into Borland Enterprise Server 5.2; a page with three form 
tags ended up reusing the form tags in such a way that the third form ended up 
with properties from the second.  Struts 1.1 has rewritten the form tag so 
that this problem is less likely to manifest itself by separating the "name" 
property from the internal "beanName" variable used to instantiate the form 
bean, but it should be possible to reproduce this problem as follows:

- create a JSP with a number of html:form instances, some with a "name" 
property specified, some without;
- view the JSP in a browser and check the generated source code.

What you should find is that the generated form "name" property is sometimes 
one of the values from the previous forms.

Other release() methods within the Struts library have NOT been investigated 
for similar behaviour, but the assumption that the release() method will be 
called prior to every doStartTag() call is a common one (one that I myself am 
guilty of so I have a long week of debugging ahead of me).  While some 
versions of Tomcat act in this manner, it is clear that not all do; this bug 
is critical as it can lead to unpredictable and hard-to-duplicate behaviour.

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org