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=8926.
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=8926
Duplicate variable definition in generated Java source, related to custom tag
scripting variable
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2002-06-13 23:55 ---
Fixed. See email with subject [PATCH] Custom tag scripting variables sent to
tomcat-dev on 12 Jun 2002 for patch.
Patch summary:
As discussed with Kin-Man, the following patch (for Jasper2)
addresses two issues related to scripting variables exposed by
custom tags (via TagExtraInfo class or TLD):
ISSUE 1:
+++
According to the JSP spec, scripting variables with scope AT_BEGIN
or AT_END are supposed to be visible from the begin element or end
element, respectively, of the custom tag that is exposing them, all
the way to the *end* of the page. This currently is not the case.
The attached patch addresses this problem by determining the AT_BEGIN
and AT_END scripting variables of any custom tag and declaring them as
local variables of the _jspService() method.
ISSUE 2:
+++
If a custom tag exposing scripting variables is nested inside
itself, its scripting variables get declared multiple times within the
same scope of the generated code, resulting in compilation
errors. This problem has been filed as bug #8926 (Synopsis: Duplicate
variable definition in generated Java source, related to custom tag
scripting variable).
The attached patch addresses this problem by declaring AT_BEGIN and
AT_END scripting variables once (as local variables of the
_jspService() method, see above), and declaring NESTED scripting
variables only at the outermost nesting level of their custom tag,
where nesting level corresponds the number of times the custom tag is
nested inside itself.
Example:
g:h
a:b -- nesting level 0, declares NESTED scripting variables
c:d
e:f
a:b -- nesting level 1, saves scripting variables
a:b -- nesting level 2, saves scripting variables
/a:b -- restores scripting variables
/a:b -- restores scripting variables
a:b -- nesting level 1, saves scripting variables
/a:b -- restores scripting variables
/e:f
/c:d
/a:b
a:b -- nesting level 0, does not declare any NESTED scripting variables
/a:b
/g:h
If a:b exposes any NESTED scripting variables, those variables are
going to be declared only once in the generated code, namely by the
*first* a:b at nesting level 0.
Any a:b with a nesting level 0 saves (in its begin element) the
current values of all its scripting variables to locale variables (named
for the scripting variable and the custom tag's nesting level) before
synchronizing the scripting variables as defined by the JSP spec. In
its end element, the custom tag restores the original values of the
scripting variables (that is, the values the scripting variables had when
the tag's begin element was encountered).
In addition, this patch stores a custom tag's scripting variables with
the custom tag itself, so the scripting variables don't need to be
determined over and over again.
This has resulted in two new accessor methods for Node.CustomTag:
public TagVariableInfo[] getTagVariableInfos()
public VariableInfo[] getVariableInfos()
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
