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=13132>. 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=13132 missing declaration of variable [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From [EMAIL PROTECTED] 2002-09-30 23:07 ------- Not a bug. The goal of the current Jasper is to implement scoping of scripting variables in the most spec-compliant way. This means that AT_END variables (which the <i18n:message> tag in your JSP code fragment exposes) are declared only after the call to the handler's doEndTag() method, when they are synchronized, and not any earlier than that. The benefit of this approach is best explained with an example. Assume this JSP code fragment: <mytags:X> <mytags:Y/> </mytags:X> with this TLD: <tag> <name>X</name> <tag-class>mytags.MyTagSupport</tag-class> <variable> <name-given>someEnd</name-given> <variable-class>java.lang.Integer</variable-class> <scope>AT_END</scope> </variable> </tag> <tag> <name>Y</name> <tag-class>mytags.MyTagSupport</tag-class> <variable> <name-given>someEnd</name-given> <variable-class>java.util.Vector</variable-class> <scope>AT_END</scope> </variable> </tag> that is, both X and Y tags declare an AT_END variable of the same name ("someEnd"), but with different types. With Jasper's current strategy of declaring AT_END variables right after the call to doEndTag(), the page generated from the above JSP fragment will compile just fine: The nested <mytags:Y> will declare a variable named "someEnd" of type java.util.Vector, whereas the enclosing <mytags:X> will declare a variable with the same name but of different type (java.lang.Integer). However, if Jasper declared AT_END variables at the beginning of the tag or method (as it used to), the above won't work. Of course, the above example won't compile if AT_END were replaced with AT_BEGIN, but that would be expected. As a workaround to your problem, specify a different value for the 'id' attribute in your second invocation of <i18n:message>. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
