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.
Created attachment 20374 [details] log entries from localhost.log these stack traces might have something to do with the described error
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.
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.
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.
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.
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)
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)
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.
(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.
The patch looks to be applied against tomcat trunk as well as 6.0 HEAD. Can this be verified?
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
I have committed a fix to trunk. After a little more testing I'll propose it for 6.0.x.
This has now been proposed for 6.0.x
This has been fixed in 6.0.x and will be included in 6.0.19 onwards.