See JspServlet lines 302-304: // JSP specified via <jsp-file> in <servlet> declaration and supplied through //custom servlet container code jspUri = (String) request.getAttribute(Constants.JSP_FILE); The comment here implies that the container uses this method to identify a servlet that is declared with a jsp-file attribute. However, tomcat actually uses the init-param "jspFile" on a copy of the JspServlet with the name of the target jsp instead. If a container sets this attribute as per the comment, it can cause stack overflow when jsp including is used: a.jsp is defined in a jsp-file on a servlet in web.xml a.jsp includes b.jsp When a.jsp is serviced it does an include dispatch to b.jsp. When the JspServlet is called for b.jsp, it sees that the request attribute with a.jsp is set, so processes it again ... which does an include dispatch for b.jsp ... which causes a.jsp to be processed again .... and then rinse and repeat. Note that Glassfish nulls out this attribute after it has been detected: if (jspFile != null) { // JSP is specified via <jsp-file> in <servlet> declaration jspUri = jspFile; request.removeAttribute(Constants.JSP_FILE); } else { Jan
A little svn archeology discovered r1003589 where the use of this attribute was removed. I'll apply the suggested fix and deprecate this attribute so it can be removed in 9.0.x.
This has been fixed in 8.0.x and 8.0.13 onwards and in 7.0.x for 7.0.56 onwards.