https://issues.apache.org/bugzilla/show_bug.cgi?id=48616
--- Comment #17 from agharta <agha...@interfree.it> 2010-02-15 08:03:57 UTC ---
(In reply to comment #15)
> Reviewing the fix to this issue,
> I cannot find any provision in the JSP specification to support the requested
> behaviour.
>
> The question is, when we are requested to declare a Java variable whether we
> should try to reuse existing declaration, or we should always declare it anew.
>
> I cannot find anything in the spec that says about reusing existing
> declaration. The only place relevant is chapter JSP.9.4.4 "Actions", and it
> says that when we do a custom action, it is translated into Java code as
>
> declare AT_BEGIN variables
> {
> declare NESTED variables
> transformation of foo
> }
> declare AT_END variables
>
> It just says "declare".
>
>
> Looking at the example provided in Comment 2:
>
> In struts 1.2.8 the bean:define tag is a BodyTag, which in its *Tei class
> declares a variable with the scope of VariableInfo.AT_END
>
> See
> http://svn.apache.org/viewvc/struts/struts1/tags/STRUTS_1_2_8/src/share/org/apache/struts/taglib/bean/DefineTag.java?view=markup
>
> http://svn.apache.org/viewvc/struts/struts1/tags/STRUTS_1_2_8/src/share/org/apache/struts/taglib/bean/DefineTei.java?view=markup
>
>
> The OP's problem is that such a tag defines both a scoped variable and a Java
> variable ("scripting variable"). It is OK to put a value into pageContext
> under
> the same name, but duplicate Java variables are not allowed.
>
> To be able to implement behaviour, requested in Comment 2, Tomcat would have
> to
> track which Java variables were declared. So, to not define a variable when it
> is created by the second time. But, consider the following example of mixing
> scriptlets and those tags:
>
> <% { %>
>
> <bean:define id="configurationExists" toScope="request" value="0"/>
>
> <% } { %>
>
> <bean:define id="configurationExists" toScope="request" value="1"/>
>
> <% } %>
>
> There is no way to reliably tell the difference between the above example and
> the one in Comment 2.
>
>
> To conclude, I would recommend the OP to use the following construct (using
> the
> JSTL tag library). I think, that it should be safe:
>
> <c:if test="${true}">
> <bean:define id="configurationExists" toScope="request" value="0"/>
> </c:if>
> <c:if test="${true}">
> <bean:define id="configurationExists" toScope="request" value="1"/>
> </c:if>
>
> Or, use <c:set /> from the same JSTL library.
>
>
> Thus, I think that this issue should be closed either as WONTFIX, or as
> INVALID.
Hi Mr,
Thanks for reply,
Sorry, but i'm not right with you (IMHO, i'm an end user of tomcat).
First, why previous versions of tomcat works right (6.0.20 and prior)?
Second, i don't use JSTL, i use the <logic:notEmpty> and <logic:notEqual>
strut's tags.....and your solution (transated in struts) does not work.
//example using notEmpty tag
<logic:notEmpty name="myVar" scope="request">
<bean:define id="configurationExists" toScope="request" value="0"/>
</logic:notEmpty>
<logic:notEmpty name="myVar" scope="request">
<bean:define id="configurationExists" toScope="request" value="1"/>
</logic:notEmpty>
<logic:notEmpty name="myVar" scope="request">
<bean:define id="configurationExists" toScope="request" value="2"/>
</logic:notEmpty>
To confirm it, please download and run the attached example, it contains this
code (in pages/Welcome.jsp) as the test case (it uses notEqual tag):
<%-- HERE THE INCRIMINATED CODE --%>
<bean:define id="configurationExists" toScope="request" value="0"/>
<logic:notEqual name="configurationExists" value="1">
<bean:define id="configurationExists" toScope="request" value="1"/>
</logic:notEqual>
<logic:notEqual name="configurationExists" value="2">
<bean:define id="configurationExists" toScope="request" value="2"/>
</logic:notEqual>
<%-- END --%>
I think that this code could appear in many projects.
......i think that exists many other projects that still using stuts 1.2.x.
This is only my opinion, in my world and in my case.
Please correct me if i am wrong.
Regards,
Agharta
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
