Created attachment 37908 [details] Minimum Sample We make heavy use of JSP-Taglibs, both java-based and tag-file-based. Since Version 9.0.48 there is a Problem when using a combination of the following: * A java-based tagfile which implements "javax.servlet.jsp.tagext.TryCatchFinally" * A regular tag-file with "scriptless" body content * A JSP-Include directive With the minimum sample provided, Jasper generates an inner class "Helper" which uses wrong variable names. We have noticed, that Jasper 9.0.48 adds a suffix to many variables, which 9.0.46 does not. This is most likely the cause. The attached minimum sample compiles with Jasper 9.0.46 und ist broken with 9.0.48. I have also attached the generated java-files for quick comparison of the generated code. ======= The error is: [...]Failing_jsp.java:254: error: cannot find symbol if (_jspx_meth_st_005ftagwithbody_005f1(_jspx_parent, _jspx_page_context, _jspx_push_body_count_st_005fwrapper_005f0)) ^ symbol: variable _jspx_push_body_count_st_005fwrapper_005f0 location: class Failing_jsp.Helper
*** This bug has been marked as a duplicate of bug 65387 ***
Can't be a duplicate as this impacts 9.0.x and the change that triggered 65387 was not back-ported to 9.0.x.
(In reply to Mark Thomas from comment #2) > Can't be a duplicate as this impacts 9.0.x and the change that triggered > 65387 was not back-ported to 9.0.x. Good catch, I mostly stopped reading after TryCatchFinally since I was looking at it at the same time. I haven't found the root cause of this issue yet however.
This is the problematic commit https://github.com/apache/tomcat/commit/9f2d78449 I've reviewed the reason the code as removed and it was removed (by me) in error. I'll restore the code shortly.
Thanks for the report and especially for the test case. A working test case makes it so much easier to track down the root cause. Fixed in: - 10.1.x for 10.1.0-M2 onwards - 10.0.x for 10.0.8 onwards - 9.0.x for 9.0.49 onwards - 8.5.x for 8.5.69 onwards
Just following up in this as we'd really like to catch regressions like this in the ~3 working day window between the release candidate being available and the release vote concluding. It is great that you are using the latest Tomcat release as soon as it as available but what would we, the Tomcat team, need to do for you to be able to test the release candidate as soon as it as available rather than you waiting for the release?
Hallo Mark, first I’d like to thank you for your very fast response on our bug report :) We use tomcat-embedded and pull it from a maven repository. If you made your release candidates available via a public maven repository which always hosted the current release or upcoming patch, e.g. "org.apache.tomcat:tomcat-catalina:9.0.next_or_rc" our nightly could pick that up. Of course you’d need to do that for all artifacts. Tank you!
If you are willing to update your nightly build then that could provide us with valuable feedback. You have a couple of choices: Snapshots that are updated with each CI build are available at: https://repository.apache.org/content/repositories/snapshots/ Staging that is updated when we create a release candidate is available at: https://repository.apache.org/content/groups/staging/ Either option would enable us to catch issues before a formal release. Obviously the snapshot repo would catch issues earlier but with the risk that the snapshots are not quite as stable (if the build compiles, the snapshot gets uploaded whether the test suite passes or not).
*** Bug 65407 has been marked as a duplicate of this bug. ***
Note that release candidate binaries are available for Tomcat 10.1.0-M2, 10.0.8, 9.0.50, and 8.5.69. See "[VOTE]" threads on the dev@ mailing list for links. https://tomcat.apache.org/lists.html#tomcat-dev
Thank you for pointing us to those repositories! Our nightlies have been adjusted and I can confirm, that the fix provided with upcoming 9.0.50 works for all our JSPs :)
*** Bug 65413 has been marked as a duplicate of this bug. ***
*** Bug 65414 has been marked as a duplicate of this bug. ***