https://bz.apache.org/bugzilla/show_bug.cgi?id=60497

            Bug ID: 60497
           Summary: JSP custom tags returned to the tag pools to be reused
                    without executing the doEndTag method
           Product: Tomcat 8
           Version: 8.5.5
          Hardware: PC
                OS: All
            Status: NEW
          Severity: critical
          Priority: P2
         Component: Jasper
          Assignee: dev@tomcat.apache.org
          Reporter: w...@destinysolutions.com
  Target Milestone: ----

As a result of the modification made in the change set "1754112 Improve the
error handling for custom tags to ensure that the tag is returned to the pool
or released and destroyed once used", Tomcat server version 8.5.5 (or higher up
to 8.5.9) will return a JSP custom tag instance back to the tag pool for reuse,
even after the execution of the tag's doStartTag method throws an exception. 
This violates the JSP specification that specifies that JSP tags should never
be reused in case of an exception.

We ran into a problem when running a Struts 1 application that makes use of the
Struts Nested tag library under Tomcat 8.5.5. (We have similar problems for the
DisplayTag as well.) Here is a simplified example to illustrate the problem.
Consider the following three simple Java classes, namely, Form.java,
Parent.java, and Child.java:

public class Form {

    private List<Parent> parents;

    public List<Parent> getParents() {
        return parents;
    }

    public void setParents(List<Parent> parents) {
        this.parents = parents;
    }
}


public class Parent {
    private String name;
    private List<Child> children;

    public Parent(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public List<Child> getChildren() {
        return children;
    }

    public void setChildren(List<Child> children) {
        this.children = children;
    }
}



public class Child {
    private String name;
    private Parent parent;

    public Child(String name){
        this.name = name;
    }


    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Parent getParent() {
        return parent;
    }

    public void setParent(Parent parent) {
        this.parent = parent;
    }
}


Suppose we have two JSPs, say page1.jsp and page2.jsp, such that page1.jsp
includes page2.jsp and that both page1.jsp and page2.jsp include a
nested:iterate tag for rendering information contained in a Form instance.

page1.jsp
---------
<nested:iterate id="parent" name="form" property="parents" indexId="id">
   <jsp:include page="/page2.jsp"/>
</nested:iterate>


page2.jsp
---------
<nested:iterate id="child" property="children" indexId="id">
   ... code that makes use of child ....
</nested:iterate>

Based on the current tag pool implementation, Tomcat will maintain two distinct
tag pools for the nested:iterate tag, one for page1.jsp and the other for
page2.jsp.
Under normal execution, i.e., without exception, the object referenced by the
nested:iterate tag defined on page2.jsp from which the "children" property will
be retrieved is a Parent instance, which is initialized by the nested:iterate
tag defined on page1.jsp. However, if the execution of the nested:iterate tag's
body defined on page2.jsp throws an exception, the name property of the tag
instance will be incorrectly and permanently set to be "form", after the tag
instance is returned back to the pool (associated with page2.jsp) to be reused.
 As a result, all subsequent executions of page2.jsp that make use of the
corrupted nested:iterate tag instance will throw an exception, since the
Form.java class does not contain a property named "children".

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to