[Bug 60497] JSP custom tags returned to the tag pools to be reused without executing the doEndTag method
https://bz.apache.org/bugzilla/show_bug.cgi?id=60497 Michael Osipov <1983-01...@gmx.net> changed: What|Removed |Added CC||1983-01...@gmx.net -- 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
[Bug 60497] JSP custom tags returned to the tag pools to be reused without executing the doEndTag method
https://bz.apache.org/bugzilla/show_bug.cgi?id=60497 --- Comment #1 from Remy Maucherat --- (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 ? -- 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
[Bug 60497] JSP custom tags returned to the tag pools to be reused without executing the doEndTag method
https://bz.apache.org/bugzilla/show_bug.cgi?id=60497 --- Comment #2 from Wai-Kau Lo --- Created attachment 34534 --> https://bz.apache.org/bugzilla/attachment.cgi?id=34534&action=edit JSP Tag Lifecycle Diagram -- 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
[Bug 60497] JSP custom tags returned to the tag pools to be reused without executing the doEndTag method
https://bz.apache.org/bugzilla/show_bug.cgi?id=60497 --- Comment #3 from Wai-Kau Lo --- 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. -- 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
[Bug 60497] JSP custom tags returned to the tag pools to be reused without executing the doEndTag method
https://bz.apache.org/bugzilla/show_bug.cgi?id=60497 --- Comment #4 from Remy Maucherat --- 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. -- 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
[Bug 60497] JSP custom tags returned to the tag pools to be reused without executing the doEndTag method
https://bz.apache.org/bugzilla/show_bug.cgi?id=60497 --- Comment #5 from Wai-Kau Lo --- 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. -- 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
[Bug 55554] NoSuchMethodError on ConcurrentHashMap$KeySetView
https://bz.apache.org/bugzilla/show_bug.cgi?id=4 --- Comment #8 from Emmanuel Bourg --- This issue has been fixed in the version 8.5.9-2 of the tomcat8 package in Debian Stretch. The tomcat8 package in Debian Jessie was built with Java 7 and is not affected. The Ubuntu package is likely to be updated automatically before the release of Ubuntu 17.04. For the older releases this will require the intervention of an Ubuntu maintainer and an issue should be opened in Launchpad. -- 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
[Bug 55554] NoSuchMethodError on ConcurrentHashMap$KeySetView
https://bz.apache.org/bugzilla/show_bug.cgi?id=4 --- Comment #9 from Rossen Stoyanchev --- FWIW I do not use Ubuntu packages for Tomcat. I download it from the Tomcat download page. So something there gave me a binary with the same or similar issue. -- 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
[Bug 60490] Several improvements to the ErrorReportValve
https://bz.apache.org/bugzilla/show_bug.cgi?id=60490 --- Comment #1 from Christopher Schultz --- Some comments. - Line endings should be either be CRLF or LF. On certain systems, System.lineSeparator may return CR only which could cause some problems[1]. I'd recommend reverting that particular change, or using CRLF. - All of the various messages here need to be HTML-escaped before being dropped-into the HTML document. Specific examples: reason phrase, error message and description, root cause, and stack trace elements. You might consider this out-of-scope for your patch, which is okay. [1] http://stackoverflow.com/questions/5916340/using-only-cr-as-linebreak-inside-pre-tag-doesnt-work -- 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
[Bug 60490] Several improvements to the ErrorReportValve
https://bz.apache.org/bugzilla/show_bug.cgi?id=60490 --- Comment #2 from Michael Osipov <1983-01...@gmx.net> --- (In reply to Christopher Schultz from comment #1) > Some comments. > > - Line endings should be either be CRLF or LF. On certain systems, > System.lineSeparator may return CR only which could cause some problems[1]. > I'd recommend reverting that particular change, or using CRLF. Thanks for that, looks like an oversight from me. I will rework on Tuesday. It was previously \n. How can that method return \r? Documentation says LF on Unix, CRLF on Windows. > - All of the various messages here need to be HTML-escaped before being > dropped-into the HTML document. Specific examples: reason phrase, error > message and description, root cause, and stack trace elements. You might > consider this out-of-scope for your patch, which is okay. The messages are in our control, nothing which needs to be escaped. The stacktrace gets escaped already by RequestUtil#filter(). Why should everything but stacktrace be espaced if there is nothing unsafe for HTML? I do agree that "message" has to be escaped, yes! > [1] > http://stackoverflow.com/questions/5916340/using-only-cr-as-linebreak-inside- > pre-tag-doesnt-work -- 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
