|Summary:||Exception not passed to c:catch in custom jsp tag|
|Product:||Tomcat 8||Reporter:||Jan Bartel <janb>|
|Component:||Jasper||Assignee:||Tomcat Developers Mailing List <dev>|
|Attachments:||Project demonstrating the problem|
Description Jan Bartel 2015-07-24 10:00:56 UTC
Created attachment 32935 [details] Project demonstrating the problem If a custom tag uses the jstl <catch> tag, then the exception is saved into the page attributes, but is not actually available to other tags via EL expressions. If, however, the <catch> tag is used directly in a jsp page, then the exception is propagated into the var and visible to subsequent El expressions. I'm attaching a small project that contains a taglib that demonstrates the problem. The project contains 2 jsps: 1. no-tagtest.jsp that uses the <catch> and other jstl tags directly in the jsp 2. tagtest.jsp that references a custom tag that uses the <catch> and other jstl tags. The problem seems to be that when a custom tag uses any other tags, then the page context is an instance of JspContextWrapper. When resolving el expressions, the JspContextWrapper.getElContext() returns an ELContext for the rootContext, rather than the page context. In this example, the <catch> tag saves the exception as an attribute named "error" in the page context attributes (the page context will be an instance of JspContextWrapper). However, when the "error" variable is referenced later in an EL expression, the EL mechanism has a page context that is the root context of the JspContextWrapper and thus can't resolve that variable.
Comment 1 Mark Thomas 2015-08-04 16:54:53 UTC
There is also a similar issue with EL and imports. The page context issue should be fixable by wrapping the root ELContext. I'm not sure that the imports issue is as easy to fix. It might end up needed a new ELContext per tag instance that uses EL and that is going to get expensive (i.e. slow down JSP pages). More thought required.
Comment 2 Mark Thomas 2015-08-06 10:15:45 UTC
I've dug into this a little more and I think this is fixable for both the reported use case and the import use case by wrapping the ELContext. I'm working on some test cases and a fix.
Comment 3 Mark Thomas 2015-08-06 15:27:45 UTC
The PageContext part of this has been fixed in trunk, 8.0.x (for 8.0.25 onwards) and 7.0.x (for 7.0.64 onwards). The import part of this only affects 8.0.x onwards.
Comment 4 Mark Thomas 2015-08-06 18:27:40 UTC
Import part fixed in trunk and 8.0.x (for 8.0.25 onwards).
Comment 5 prashant 2015-10-09 07:15:45 UTC
Hello Mark, Is there way to patch the fix to 8.0.23? Could you please let us know the class/java files need to replaced in 8.0.23 to make this work?
Comment 6 Mark Thomas 2015-10-09 07:23:31 UTC
The patches for 8.0.x are r1694503 and r1694548. I would not recommend copying class files from one version to another. If you really want to patch this in 8.0.23 then you need to checkout the 8.0.23 tag, apply the two patches above and then build your patched version of 8.0.23 from source. I'd recommend not pathcing and upgrading to 8.0.latest instead.
Comment 7 Mark Thomas 2017-03-07 10:56:19 UTC
See also http://tomcat.markmail.org/thread/cnqkckysilwhpyip for a discussion on a follow-up issue and r1785823, r1785826 and r1785827