Bug 42693 - JSP-Generation error with recursive tagfile structure
JSP-Generation error with recursive tagfile structure
Status: RESOLVED FIXED
Product: Tomcat 6
Classification: Unclassified
Component: Jasper
unspecified
PC Linux
: P1 critical (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-06-18 10:10 UTC by Frank Hofmann
Modified: 2009-01-14 15:27 UTC (History)
2 users (show)



Attachments
log entries from localhost.log (24.96 KB, text/plain)
2007-06-20 02:17 UTC, Frank Hofmann
Details
war file to demonstrate defect (362.00 KB, application/octet-stream)
2007-10-05 11:01 UTC, Frank Hofmann
Details
Attaching the generated file by renderFileSystemEntry.tagx (6.13 KB, text/plain)
2007-10-05 19:06 UTC, Lucas Galfaso
Details
slightly modified test application to show runtime specifica (362.71 KB, application/octet-stream)
2007-10-06 05:08 UTC, Frank Hofmann
Details
correct result from running the web app with tomcat 5.5.17 (save as HTML to view, correct MIME type was not permitted for upload by Bugzilla) (4.27 KB, text/plain)
2007-10-06 05:10 UTC, Frank Hofmann
Details
incorrect results from running web app with tomcat 6.0.13 (save as HTML to view, correct MIME type was not permitted for upload by Bugzilla) (139.31 KB, text/plain)
2007-10-06 05:11 UTC, Frank Hofmann
Details
Open the outputWriter when sure that no other process will write a file with the same name (2.47 KB, patch)
2007-10-07 13:14 UTC, Lucas Galfaso
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Hofmann 2007-06-18 10:10:02 UTC
addendum: it's Version 6.13 (not available in combobox above)

scenario:
=========
a menu is decribed by a tree structure;
rendering the menu is done by a tagfile 'render_menuitem', which renders the
current item either as a leaf item (clicking on it causes an action) or as a
node item (clicking on it opens another next-level submenu);
rendering the submenu is done by calling the tagfile again from within its body;
this worked fine with tomcat 5.0.x and 5.5.x

to make it clear see the following pseudo code (the original code is to
voluminous): 
tagfile 'render_menuitem.tagx':
<jsp:root ...>
   <jsp:directive.attribute name="menu_item"/>
   <c:choose>
      <c:when test="${menu_item.isNode}
         <div>node: ${menu_item.label}</div>
         <c:forEach var="sub_item" items="menu_item.children">
            <!-- THIS IS GOING TO CAUSE THE PROBLEM WITH TOMCAT6: -->
            <tags:render_menuitem menu_item="${sub_item}"/>
         </c:forEach>
      <c:when>
      <c:otherwise>
         <div>leaf: ${menu_item.label}</div>
      </c:otherwise>
   </c:choose>
</jsp:root>

faulty behaviour:
================
with tomcat 6.0.13, the generated Java-Source for the tagfile reveals, that the
body of the doTag() method is empty and therefore emits no html; the compilation
itself was silently done, no error or warning was shown in the logfiles.
Comment 1 Frank Hofmann 2007-06-20 02:17:44 UTC
Created attachment 20374 [details]
log entries from localhost.log

these stack traces might have something to do with the described error
Comment 2 Lucas Galfaso 2007-10-04 19:33:06 UTC
Tested with Tomcat 6.0.14 Windows XP SP2 and it works as expected.
AFAICT, there should be no differences with the Linux version.

Please attach a full test case that shows the faulty behavior.
Comment 3 Frank Hofmann 2007-10-05 11:01:23 UTC
Created attachment 20926 [details]
war file to demonstrate defect

I did describe the defect as tomcat 6 not being able any more (contrary to
tomcat 5.5.x) to process reentrant / recursive tagfiles. As far as I see, there
is an error in the algorithm to generate the java sources, because the way it
is implemented now (in version 6) assumes a static call stack for tagfiles.

The tester was a little bit lazy and didn't read my bug description properly,
so I had to spent the time to write a ready to run test case: see the test.war
file attached. It shows the jdk file structure on the machine running tomcat,
and it works with 5.5.17, but not any more with version 6.0.13!

Please process this incident more properly and timely, because it really takes
a lot of time to create such contributions! Thanks.
Comment 4 Lucas Galfaso 2007-10-05 19:06:17 UTC
Created attachment 20931 [details]
Attaching the generated file by renderFileSystemEntry.tagx

(In reply to comment #3)

Tested the attached war file with Tomcat 6.0.13 and 6.0.14 using Java 1.5_10
and Java 1.5_11 using the war file to deploy the web app and expanding the war
into a folder at TOMCAT_HOME/webapps/test.
In all eight cases, the page worked as expected, there was only a warning
saying that the file /WEB-INF/web.xml was missing.

Please specify the specific OS used and Java version that was used to perform
this test.

Please, lets try to keep this using good manners.
Comment 5 Frank Hofmann 2007-10-06 05:08:49 UTC
Created attachment 20933 [details]
slightly modified test application to show runtime specifica

just throw it into webapps dir of 
a) tomcat 5.5.x
b) tomcat 6.0.x
and request http://SERVER:8081/tomcat_bug
-- it will show different results, with the latter being wrong,
because the JSP specification doesn't disallow Tags or tagfiles (which should
transparently being transformed into equivalent Java code) to recursively call
another instance of itself. Many problems are naturally solved by recursive
algorithms.

Please watch the 2 html files attached hereafter, where the evidence is
documented for the 2 machines/configurations I currently have access to. They
definitively differ.
Comment 6 Frank Hofmann 2007-10-06 05:10:03 UTC
Created attachment 20934 [details]
correct result from running the web app with tomcat 5.5.17 (save as HTML to view, correct MIME type was not permitted for upload by Bugzilla)
Comment 7 Frank Hofmann 2007-10-06 05:11:14 UTC
Created attachment 20935 [details]
incorrect results from running web app with tomcat 6.0.13 (save as HTML to view, correct MIME type was not permitted for upload by Bugzilla)
Comment 8 Lucas Galfaso 2007-10-07 13:14:53 UTC
Created attachment 20940 [details]
Open the outputWriter when sure that no other process will write a file with the same name

This patch fixes the following situation, when a .tagx file needs to be
compiled, and by any form of dependency it depends on itself, be sure that the
output .java file is opened after the prototype file is generated compiled and
closed.
Comment 9 Lucas Galfaso 2007-10-07 13:21:39 UTC
(In reply to comment #8)

Mmm.. I think that a better description would be:

Open the outputWriter when positive that this same process will not open a
compilation context to generate a prototype of this same class.

This patch fixes the following situation, when a .tagx file needs to be
compiled, and by any form of dependency it depends on itself, be sure that the
output .java file is opened after the prototype .java file is generated,
compiled and closed.

Comment 10 Tim Funk 2007-12-26 17:48:24 UTC
The patch looks to be applied against tomcat trunk as well as 6.0 HEAD.

Can this be verified?
Comment 11 Przemek Dyk 2008-10-24 12:48:44 UTC
if you invoke recursive twice tag the bug still occurs

example:

index.jsp
-------------------------------------------------------------
<%@ taglib prefix="u" tagdir="/WEB-INF/tags" %>
<html>
<head><title>taglib test</title></head>
<body>
<u:seq arg="5" max="12"/>
</body>
</html>


seq.tag
-------------------------------------------------------------
<%@ attribute 
    name="arg"
    required="true"
    type="java.lang.Integer"
%>
<%@ attribute
    name="max"
    required="true"
    type="java.lang.Integer"
%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="n" tagdir="/WEB-INF/tags" %>

<p><c:out value="${arg}"/></p>
<c:if test="${arg lt max}">
  <n:seq arg="${arg + 1}" max="${max}"/>
  <n:seq arg="${arg + 1}" max="${max}"/>
</c:if>


jdk: 1.6.0_07
tomcat: 6.0.18
os: Windows XP and Ubuntu 8.04.1
Comment 12 Mark Thomas 2008-11-23 13:28:32 UTC
I have committed a fix to trunk. After a little more testing I'll propose it for 6.0.x.
Comment 13 Mark Thomas 2008-12-23 05:24:11 UTC
This has now been proposed for 6.0.x
Comment 14 Mark Thomas 2009-01-14 15:27:06 UTC
This has been fixed in 6.0.x and will be included in 6.0.19 onwards.