You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2004/10/13 13:05:47 UTC

DO NOT REPLY [Bug 31382] - Stack overflow at JspServlet with self referencing JSP tag files.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31382>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31382

Stack overflow at JspServlet with self referencing JSP tag files.

acm@tweakers.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acm@tweakers.net
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |



------- Additional Comments From acm@tweakers.net  2004-10-13 11:05 -------
I sent this e-mail earlier to Dominik, since I disagree with his choice to mark
this as not-a-bug. But since I didn't receive a reply yet, I'll post it as a
comment here.

Hi Dominik,

In bug-report http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31382 you seem
to be missing the point of the bug. It actually IS a tomcat-bug, imho. I'll
describe what happens more clearly, perhaps you agree with me afterwards:

The tag I displayed there is a recursive tag, indeed. And yes, there seems to be
unbound recursion... But not when executing the tag, the unbound recursion is at
tag-recompile-time. When the tag is first created, and there are no
class/java-files for it, everything goes fine (including executing the tag).
But when the tag changes, the COMPILER goes into the recursion. My guess is that
the tag is reparsed, but that the compiler/parser/whatever notices it depends on
a certain tag (itself) and notices that that dependency is also changed (doh)...
That dependency is reparsed/recompiled and the compiler notices a dependency
(itself again...), of course the dependency has changed so that needs
recompilation/reparsing... And again, again, again etc.

The above does not happen for new tags, nor when you remove the
.class/.java-files for the specific tag. Why this only fails when a tag changes,
I don't know. There is probably some save-guard or another order of compilation
when a new tag is used.

Please see for yourself using the test.jsp and test.tag I displayed there. That
should not run into unbound recursion, since it is only allowed 5 steps... (I
tested it)

Best regards,

Arjen van der Meijden

PS, my guess is that this may also fail when there are more tags involved in the
recursion. But I haven't tested that.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org