DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26329>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26329 Long classpath for JUnit reporter results in stack overflow and JVM crash Summary: Long classpath for JUnit reporter results in stack overflow and JVM crash Product: Ant Version: 1.5.1 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm creating a report with the JUnitReport task as so: <junitreport todir="${dir.test.reports}"> <fileset dir="${dir.test.reports}" includes="TEST-*.xml"/> <report todir="${dir.test.reports}/html"/> </junitreport> The junit-frames.xsl stylesheet converts the generated XML document to an HTML document. One of the things it does is convert '\' to '\\', presumably so JavaScript doesn't barf. Unfortunately, if the input contains a very long classpath, the recursion in the stylesheet causes the stack to get too big and I get an "Unrecoverable Stack Overflow" and the JVM crashes. For example, my input XML document contains this: <property name="prereq.classpath" value="c:\build\foo1.jar;c:\build\foo2.jar;... [LOTS more!] and the bottom of the HTML file which was written looks like this: cur['prereq.classpath'] = 'c:\\build\\foo1.jar;c:\\build\\foo2.jar;... [LOTS more, but it dies in the middle of outputting, i.e. ends with c:\\build\\] the offending XSL contains this: <xsl:template name="JS-escape"> ... <xsl:when test="contains($string,'\')"> <xsl:value-of select="substring-before($string,'\')"/>\\<xsl:call-template name="JS-escape"> <xsl:with-param name="string" select="substring-after($string,'\')"/> </xsl:call-template> </xsl:when> ... </xsl:template> It's that recursive call-template to JS-escape which is killing the processing. I am currently running on Ant 1.5.1, but the XSL document looks exactly the same in 1.6.0. It probably still fails on 1.6.0. shawn. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
