| Summary: | JSP custom tags returned to the tag pools to be reused without executing the doEndTag method | ||
|---|---|---|---|
| Product: | Tomcat 8 | Reporter: | Wai-Kau Lo <wklo> |
| Component: | Jasper | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | michaelo |
| Priority: | P2 | ||
| Version: | 8.5.5 | ||
| Target Milestone: | ---- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Attachments: |
JSP Tag Lifecycle Diagram
Change reuse logic Test web application Reuse exclusion and try/finally for simple tags |
||
(In reply to Wai-Kau Lo from comment #0) > This violates the JSP specification that specifies > that JSP tags should never be reused in case of an exception. Can you provide the spec language which states this ? Created attachment 34534 [details]
JSP Tag Lifecycle Diagram
Page 2-54 of the JavaServer Pages Specification version 2.0 describes the lifecycle of a JSP tag instance using a state transition diagram, which I have uploaded to this bug as an attachment (named JSP Tag Lifecycle Diagram) for ease of reference. The state transitions are described as follows: •[1] This transition is intended to be for releasing long-term data. no guarantees are assumed on whether any properties have been retained or not. •[2] This transition happens if and only if the tag ends normally without raising an exception •[3] Some setters may be called again before a tag handler is reused. For instance, setParent() is called if it’s reused within the same page but at a different level, setPageContext() is called if it’s used in another page, and attribute setters are called if the values differ or are expressed as request-time attribute values. Label [2] corresponds to the state transition caused by the execution of the doEndTag method, after the doStartTag method is execution. This implies that the doEndTag method should not be executed if the doStartTag method execution raises an exception. Since the doEndTag method is not executed, the tag instance will not be in a proper state for the next execution of the doStartTag, implying that we should never reuse the tag instance if the doStartTag method raises an exception during its execution. I didn't find anything that was very clear either, which is why I asked. I'd recommend you disable tag pooling for now, it's probably not that useful anymore. I think the JSP spec clearly states that we should not reuse a JSP tag instance if its doStartTag method execution raises an exception, as I explained in my previous comment. Also, this is clearly a regression issue introduced by changset set 1754112 in Tomcat 8.5.5, which fortunately has not been ported back to the Tomcat 9.0 release branch. I am hoping we can roll back this changeset in the Tomcat 8.5 release branch. Finally, JSP Custom Tag Pooling has been highlighted in the "Jasper 2 JSP Engine How To" section as a significant performance booster. JSP Custom Tag Pooling - The java objects instantiated for JSP Custom Tags can now be pooled and reused. This significantly boosts the performance of JSP pages which use custom tags. Since our application depends heavily on custom tags, I am just hesitant to simply turn off tag pooling with conducting some performance tests first. In the meantime, I guess the only recourse is to compile my own Jasper engine. Created attachment 34540 [details]
Change reuse logic
I'm not convinced by the explanation. Adding some more complexity to the generated code if the issue is found to be legitimate. And for review too.
Created attachment 34543 [details] Test web application Attached is a self-contained web application that can be used to replicate the issue. After deploying the test.war file on a Tomcat Server of version 8.5.5 (or higher up to 8.5.9), access the following two URLs in sequence: 1) http://localhost:8080/test/test/page1.jsp You will receive a NullPointerException from page2.jsp as expected. java.lang.NullPointerException org.apache.jsp.test.page2_jsp._jspService(page2_jsp.java:151) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) ........................ 2) http://localhost:8080/test/test/page1.jsp?childName=name Instead of the expected response shown below Parent Name: Parent1 Child Name: name contains 4 characters you will receive the following JspException: javax.servlet.jsp.JspException: No getter method for property: "children" of bean: "form" org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:987) org.apache.struts.taglib.logic.IterateTag.doStartTag(IterateTag.java:232) org.apache.struts.taglib.nested.logic.NestedIterateTag.doStartTag(NestedIterateTag.java:73) org.apache.jsp.test.page2_jsp._jspService(page2_jsp.java:135) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) .............. This is caused by the "corrupted" nested:iterate tag instance cached in the tag pool after processing the first URL. Created attachment 34544 [details]
Reuse exclusion and try/finally for simple tags
I applied the patch and it will be included in 9M16, 8.5.10, 8.0.40, 7.0.74 and 6.0.49. It is possible the new behavior gets reintroduced in 8.5 and 9 after it is reviewed. Hello, We would like to go for TC 8.5.14 or 8.5.15. Will this patch be available there? |
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".