Re: Jasper2: serious problem with tag declarations
Costin, - I have a bean:define id=a name=foo/ The generated code is: a = (java.lang.Object) pageContext.findAttribute(a); a = (java.lang.Object) pageContext.findAttribute(a); a = (java.lang.Object) pageContext.findAttribute(a); ( i.e. 3 times the same line ). Not a bug, but strange. this turned out to be a bug inherited from the old jasper, which did not synchronize scripting variables at the appropriate places (as outlined in the Synchronization Protocol section in JSP.10.5.9). I've just committed a fix for this, which should make jasper2 comply with the spec. Jan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
On Thu, 27 Jun 2002, Jan Luehe wrote: Costin, - I have a bean:define id=a name=foo/ The generated code is: a = (java.lang.Object) pageContext.findAttribute(a); a = (java.lang.Object) pageContext.findAttribute(a); a = (java.lang.Object) pageContext.findAttribute(a); ( i.e. 3 times the same line ). Not a bug, but strange. this turned out to be a bug inherited from the old jasper, which did not synchronize scripting variables at the appropriate places (as outlined in the Synchronization Protocol section in JSP.10.5.9). I've just committed a fix for this, which should make jasper2 comply with the spec. This particular problem wasn't a 'compliance' problem - the result was still correct, even if computed 3 times. The real compliance problem that worries me is the AT_END variables that get generated at the beginning of the file. I'm pretty sure it's quite easy to run into problems with tags that declare typed variables, and I'm pretty sure existing applications will brake ( mine did - I had to change some variable names ). And I would bet most jsp implementations in use are doing exactly what jasper1 is doing - and changing this will create big problems ( while still beeing non-compiant with the spec, and completely counterintuitive ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
Costin,
- I have a
bean:define id=a name=foo/
The generated code is:
a = (java.lang.Object) pageContext.findAttribute(a);
a = (java.lang.Object) pageContext.findAttribute(a);
a = (java.lang.Object) pageContext.findAttribute(a);
( i.e. 3 times the same line ).
Not a bug, but strange.
this turned out to be a bug inherited from the old jasper,
which did not synchronize scripting variables at the appropriate
places (as outlined in the Synchronization Protocol section
in JSP.10.5.9).
I've just committed a fix for this, which should make jasper2
comply with the spec.
This particular problem wasn't a 'compliance' problem - the result
was still correct, even if computed 3 times.
actually, it has been a compliance problem.
For instance, AT_BEGIN variables used to be synchronized always after
doStartTag(), regardless of whether the tag handler implemented
BodyTag (according to the spec, those variables are supposed to be
synchronized after doStartTag() only if the tag handler does not
implement BodyTag).
Furthermore, AT_BEGIN variables were not synchronized after
doEndTag(), where they should have.
In addition, AT_BEGIN (and NESTED) variables are supposed to be
synchronized after doAfterBody() (if the tag handler implements
BodyTag). In the previous jasper, this requirement was not implemented
correctly (synchronization took place only once):
do {
...
} while (tagHandlerVar.doAfterBody() ==
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
}
// Synchronize AT_BEGIN variables
In jasper2, the synchronization is done after each call to
doAfterBody(), like this:
do {
...
int evalDoAfterBody = tagHandlerVar.doAfterBody();
// Synchronize AT_BEGIN and NESTED scripting variables
if (evalDoAfterBody != javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN)
break;
} while (true);
The real compliance problem that worries me is the AT_END variables
that get generated at the beginning of the file. I'm pretty sure
it's quite easy to run into problems with tags that declare typed
variables, and I'm pretty sure existing applications will brake
( mine did - I had to change some variable names ).
And I would bet most jsp implementations in use are doing exactly
what jasper1 is doing - and changing this will create big problems
( while still beeing non-compiant with the spec, and completely
counterintuitive )
But there also could be applications that expect (based on the spec)
to have access to an AT_END variable where they currently don't (with jasper1).
Those apps will (rightfully) complain that jasper does not follow the spec.
In my opinion the whole scoping issue of scripting variables
is not carefully thought out in JSP 1.2, and it is up to us
to balance conflicting requirements. If there is large consensus
that jasper2 should treat AT_END scripting variables the way jasper1
did, I won't object.
Jan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
On Thu, 27 Jun 2002, Jan Luehe wrote: And I would bet most jsp implementations in use are doing exactly what jasper1 is doing - and changing this will create big problems ( while still beeing non-compiant with the spec, and completely counterintuitive ) But there also could be applications that expect (based on the spec) to have access to an AT_END variable where they currently don't (with jasper1). Those apps will (rightfully) complain that jasper does not follow the spec. If most containers are consitently implementing the spec the way jasper1 did - then we should continue to do so. I don't think ant application will expect AT_END vars to be declared at the beggining ( before AT_BEGIN and NESTED ). And I don't think anyone with some programing experience will ever expect that a variable declared in a nexted scope iterate declare /iterate will be visible after that ( even if the spec sugests it should ). In my opinion the whole scoping issue of scripting variables is not carefully thought out in JSP 1.2, and it is up to us to balance conflicting requirements. If there is large consensus I agree with this - there are conflicting requirements. But backward compatibility and consistency are extremely important. Other opinions ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
I tried again, and it worked. There is still one error ( i.e. a page that worked before but no longer does ), but that may be legitimate. 2 more problems: - I have a bean:define id=a name=foo/ The generated code is: a = (java.lang.Object) pageContext.findAttribute(a); a = (java.lang.Object) pageContext.findAttribute(a); a = (java.lang.Object) pageContext.findAttribute(a); ( i.e. 3 times the same line ). Not a bug, but strange. - in the same case, the 'a' variable is declared at the top of the file, even if it is AT_END. That brakes previous iterate that used the 'a' id. I believe this is a bug. Costin On Tue, 25 Jun 2002, Jan Luehe wrote: Costin, On Mon, 24 Jun 2002, Kin-Man Chung wrote: With the Jan's patch last Friday, jasper 2 should handle those cases that used to work for japser1, as well as those those that cannot be handled by jasper1. If this is not the case, please let me know. The current failing case is ( used to work fine in jasper1 ): The original problem with 2 nested iterate is solved, thanks Jan. %@ page language=java % %@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % logic:iterate id=a name=foo property=bar /logic:iterate logic:present name=b logic:iterate id=a name=foo property=bar /logic:iterate /logic:present Costin Correct me if I'm wrong, but the above compiles fine for me with Friday's patch. In fact, I had tested the above example to make sure the patch worked. Attached is the generated servlet. What is the error message you are getting? Jan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
On Wed, 26 Jun 2002, Jan Luehe wrote: - in the same case, the 'a' variable is declared at the top of the file, even if it is AT_END. That brakes previous iterate that used the 'a' id. I believe this is a bug. According to the spec, the scope of an AT_END variable spans from the end element of the tag exposing it to the end of the page. The previous jasper did not implement this correctly: If the tag exposing the AT_END variable was nested, the previous jasper would declare the variable at its nesting level, limiting its visibility. I think this was in violation of the spec. However the current jasper exposes it from the beginning of the service() method - which is also in violation of the spec. ( i.e. AT_END is before AT_BEGIN and anything else ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
- in the same case, the 'a' variable is declared at the top of the file, even if it is AT_END. That brakes previous iterate that used the 'a' id. I believe this is a bug. According to the spec, the scope of an AT_END variable spans from the end element of the tag exposing it to the end of the page. The previous jasper did not implement this correctly: If the tag exposing the AT_END variable was nested, the previous jasper would declare the variable at its nesting level, limiting its visibility. I think this was in violation of the spec. However the current jasper exposes it from the beginning of the service() method - which is also in violation of the spec. ( i.e. AT_END is before AT_BEGIN and anything else ). Costin That's true, but the value of those variables are still synchronized with the corresponding pageContext attributes at the locations specified by the spec, so using these variables before they are synchronized is meaningless. The spec as is today really cannot be implemented correctly in Java. What we are doing is let pages that conform to the spec (e.g. referencing an AT_END variable after end of tag) be compiled and run correctly, but does not prevent people from writing page that is not spec conformant (e.g. referencing an AT_END variables in the body). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
Costin,
On Fri, 21 Jun 2002, Kin-Man Chung wrote:
Use of scripting varibles in nested tag never work before, so obviously
no body uses it much. I think the whole scripting variable in JSP1.2 is
poorly designed, and not well understood.
The failures are from an app that worked perfectly fine with
jasper1, and with jasper2 ( up to 4.1.4 ).
And IMHO are very elementary use cases - 2 iterates and one
condition is not that infrequent.
jasper1 and old jasper2 implements scripting variables by declaring them
when a tag handler is instantiated, inside a block of its own, like
{
String x; // variable x defined here
...
}
This implementation has 2 problems.
1) Nested tags with same variable does not work
mytag:foo
mytag:foo
/mytag:foo
/mytag:foo
because you cannot have two varibles of the same name in Java, even if
they are in blocks nested within one another.
2) The variables are out of scope when the tag ends, but for variables
with AT_BEGIN scope, spec says they should be accessable until the
end of the page.
How do we deal with nested tags of different type ? I don't have
a test case, but I assume someone may have a NESTED tag
'foo' in 2 different tags, with different declared types ( String and
Integer ). The current generator seems to not create { },
and I'm not sure how this will work.
( no test case - but I'm sure you can find such tags )
That would not work, and would never be made to work, not only for
nested case, but also for non-nested tags with AT_BEGIN scopes.
I tend to think this falls into the user's reponsibility if she uses
the same variable name for two different types, somewhat analogous to
declaring two variables of the same name two different types in Java.
I'm lost here - wasn't NESTED supposed to define a lexical scoping ?
I don't see why this wouldn't work - are you saying it doesn't
work with jasper2, it didn't worked with jasper1, or is not
required by the spec ?
You cannot have
{
String x;
{
String x;
}
}
in Java, so we are implementing scripting variables with nested scopes as
{
String x;
{
String temp = x;
...
}
x = temp;
}
You can see why we'll have problems if two variables nesting with one
anothers have the same name but different types.
Hopefully, there won't be a need for scripting variables anymore when
expression language becomes available in JSP2.0.
:-)
Unfortunately JSP1.x will be around for a while, and jasper must support
it.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
On Mon, 24 Jun 2002, Kin-Man Chung wrote:
Use of scripting varibles in nested tag never work before, so obviously
no body uses it much. I think the whole scripting variable in JSP1.2 is
poorly designed, and not well understood.
The failures are from an app that worked perfectly fine with
jasper1, and with jasper2 ( up to 4.1.4 ).
And IMHO are very elementary use cases - 2 iterates and one
condition is not that infrequent.
jasper1 and old jasper2 implements scripting variables by declaring them
when a tag handler is instantiated, inside a block of its own, like
My problem is that code that worked with jasper1 no longer works with
jasper2.
And I believe the use case is valid and within the spec, and quite
common.
The latest failure is just 2 iterate tags and a condition tag -
I think it should work.
Costin
{
String x; // variable x defined here
...
}
This implementation has 2 problems.
1) Nested tags with same variable does not work
mytag:foo
mytag:foo
/mytag:foo
/mytag:foo
because you cannot have two varibles of the same name in Java, even if
they are in blocks nested within one another.
2) The variables are out of scope when the tag ends, but for variables
with AT_BEGIN scope, spec says they should be accessable until the
end of the page.
How do we deal with nested tags of different type ? I don't have
a test case, but I assume someone may have a NESTED tag
'foo' in 2 different tags, with different declared types ( String and
Integer ). The current generator seems to not create { },
and I'm not sure how this will work.
( no test case - but I'm sure you can find such tags )
That would not work, and would never be made to work, not only for
nested case, but also for non-nested tags with AT_BEGIN scopes.
I tend to think this falls into the user's reponsibility if she uses
the same variable name for two different types, somewhat analogous to
declaring two variables of the same name two different types in Java.
I'm lost here - wasn't NESTED supposed to define a lexical scoping ?
I don't see why this wouldn't work - are you saying it doesn't
work with jasper2, it didn't worked with jasper1, or is not
required by the spec ?
You cannot have
{
String x;
{
String x;
}
}
in Java, so we are implementing scripting variables with nested scopes as
{
String x;
{
String temp = x;
...
}
x = temp;
}
You can see why we'll have problems if two variables nesting with one
anothers have the same name but different types.
Hopefully, there won't be a need for scripting variables anymore when
expression language becomes available in JSP2.0.
:-)
Unfortunately JSP1.x will be around for a while, and jasper must support
it.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
My problem is that code that worked with jasper1 no longer works with jasper2. And I believe the use case is valid and within the spec, and quite common. The latest failure is just 2 iterate tags and a condition tag - I think it should work. Costin With the Jan's patch last Friday, jasper 2 should handle those cases that used to work for japser1, as well as those those that cannot be handled by jasper1. If this is not the case, please let me know. - Kin-man -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
On Mon, 24 Jun 2002, Kin-Man Chung wrote: With the Jan's patch last Friday, jasper 2 should handle those cases that used to work for japser1, as well as those those that cannot be handled by jasper1. If this is not the case, please let me know. The current failing case is ( used to work fine in jasper1 ): The original problem with 2 nested iterate is solved, thanks Jan. %@ page language=java % %@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % logic:iterate id=a name=foo property=bar /logic:iterate logic:present name=b logic:iterate id=a name=foo property=bar /logic:iterate /logic:present Costin - Kin-man -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
Costin,
If those variable declaration problems are fixed, I'll release a new
4.1.6 milestone as soon as I can fix the JNDI problems.
Not yet...
I attached the failed jsp.
Costin
[...]
%@ page language=java %
%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
logic:iterate id=a name=foo property=bar
/logic:iterate
logic:present name=b
logic:iterate id=a name=foo property=bar
/logic:iterate
/logic:present
last and final attempt! :)
The attached patch should fix the last issue you brought up.
Since I am still waiting for my commit privileges, Kin-Man
has again volunteered to apply the patch. Thanks Kin-Man!
Jan
Executing ssh-askpass to query the password...
Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on
the server side.
? build
? build.properties
cvs server: Diffing .
cvs server: Diffing doc
cvs server: Diffing src
cvs server: Diffing src/bin
cvs server: Diffing src/share
cvs server: Diffing src/share/org
cvs server: Diffing src/share/org/apache
cvs server: Diffing src/share/org/apache/jasper
cvs server: Diffing src/share/org/apache/jasper/compiler
Index: src/share/org/apache/jasper/compiler/Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.32
diff -u -r1.32 Generator.java
--- src/share/org/apache/jasper/compiler/Generator.java 21 Jun 2002 00:59:56 -
1.32
+++ src/share/org/apache/jasper/compiler/Generator.java 21 Jun 2002 22:23:17 -
@@ -543,15 +543,6 @@
private MethodsBuffer methodsBuffer;
private int methodNesting;
- /*
-* Maps temporary scripting variable to parent of custom tag that
-* declared it
-*/
- private Hashtable tmpVars;
-
- // Maps NESTED scripting var to parent of custom tag that declared it
- private Hashtable nestedVars;
-
/**
* Constructor.
*/
@@ -561,8 +552,6 @@
methodNesting = 0;
handlerInfos = new Hashtable();
tagVarNumbers = new Hashtable();
- tmpVars = new Hashtable();
- nestedVars = new Hashtable();
}
/**
@@ -1306,20 +1295,20 @@
out.printin(/* );
out.print(n.getName());
out.println( */);
+ out.printil({);
+ out.pushIndent();
boolean implementsTryCatchFinally =
TryCatchFinally.class.isAssignableFrom(tagHandlerClass);
- /*
-* Declare variables where current contents of scripting variables
-* will be temporarily saved
-*/
- declareTemporaryScriptingVariables(n);
-
// Declare scripting variables with NESTED scope
declareNestedScriptingVariables(n);
- // Save current value of scripting variables if required
+ /*
+* Save current values of scripting variables, so that the
+* scripting variables may be synchronized without affecting their
+* original values
+*/
saveScriptingVariables(n);
out.printin(tagHandlerClass.getName());
@@ -1464,6 +1453,8 @@
syncScriptingVariables(n, VariableInfo.AT_END);
restoreScriptingVariables(n);
+ out.popIndent();
+ out.printil(});
n.setEndJavaLine(out.getJavaLine());
}
@@ -1502,14 +1493,10 @@
if ((varInfos[i].getScope() == VariableInfo.NESTED)
varInfos[i].getDeclare()) {
String name = varInfos[i].getVarName();
- Node parent = (Node) nestedVars.get(name);
- if (parent == null || parent != n.getParent()) {
- out.printin(varInfos[i].getClassName());
- out.print( );
- out.print(name);
- out.println(;);
- nestedVars.put(name, n.getParent());
- }
+ out.printin(varInfos[i].getClassName());
+ out.print( );
+ out.print(name);
+ out.println(;);
}
}
} else {
@@ -1522,14 +1509,11 @@
if ((varInfos[i].getScope() == VariableInfo.NESTED)
varInfos[i].getDeclare()) {
String name = varInfos[i].getVarName();
- Node parent = (Node) nestedVars.get(name);
- if ((parent == null || parent != n.getParent())
-
RE: Jasper2: serious problem with tag declarations
Hi Costin,
But there is still a problem - now if you have:
logic:iterate id='i'
/logic:iterate
logic:iterate id='i'
/logic:iterate
( i.e. the same variable name ), it will fail with duplicated declaration,
the code will be:
Object i;
...
Object i;
( id is nested ).
The above code fragment compiles fine for me.
I've attached the generated servlet code.
Can you send me the exact page you are trying to run?
If you could provide the generated code, that would help, too.
Thanks,
Jan
package org.apache.jsp;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import org.apache.jasper.runtime.*;
public class test1$jsp extends HttpJspBase {
private static java.util.Vector _jspx_includes;
private org.apache.jasper.runtime.TagHandlerPool _jspx_tagPool_logic_iterate_id;
public test1$jsp() {
_jspx_tagPool_logic_iterate_id = new org.apache.jasper.runtime.TagHandlerPool();
}
public java.util.List getIncludes() {
return _jspx_includes;
}
public void jspDestroy() {
_jspx_tagPool_logic_iterate_id.release();
}
public void _jspService(HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException, ServletException {
JspFactory _jspxFactory = null;
javax.servlet.jsp.PageContext pageContext = null;
HttpSession session = null;
ServletContext application = null;
ServletConfig config = null;
JspWriter out = null;
Object page = this;
JspWriter _jspx_out = null;
try {
_jspxFactory = JspFactory.getDefaultFactory();
response.setContentType(text/html;ISO-8859-1);
pageContext = _jspxFactory.getPageContext(this, request, response,
null, true, 8192, true);
application = pageContext.getServletContext();
config = pageContext.getServletConfig();
session = pageContext.getSession();
out = pageContext.getOut();
_jspx_out = out;
out.write(\n\n);
/* logic:iterate */
java.lang.Object i;
org.apache.struts.taglib.logic.IterateTag _jspx_th_logic_iterate_0 =
(org.apache.struts.taglib.logic.IterateTag)
_jspx_tagPool_logic_iterate_id.get(org.apache.struts.taglib.logic.IterateTag.class);
_jspx_th_logic_iterate_0.setPageContext(pageContext);
_jspx_th_logic_iterate_0.setParent(null);
_jspx_th_logic_iterate_0.setId(i);
int _jspx_eval_logic_iterate_0 = _jspx_th_logic_iterate_0.doStartTag();
if (_jspx_eval_logic_iterate_0 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
if (_jspx_eval_logic_iterate_0 !=
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {
javax.servlet.jsp.tagext.BodyContent _bc = pageContext.pushBody();
_bc.clear();
out = _bc;
_jspx_th_logic_iterate_0.setBodyContent(_bc);
_jspx_th_logic_iterate_0.doInitBody();
}
do {
i = (java.lang.Object) pageContext.findAttribute(i);
out.write( \n);
} while (_jspx_th_logic_iterate_0.doAfterBody() ==
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
if (_jspx_eval_logic_iterate_0 !=
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE)
out = pageContext.popBody();
}
if (_jspx_th_logic_iterate_0.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
_jspx_tagPool_logic_iterate_id.reuse(_jspx_th_logic_iterate_0);
out.write(\n\n);
/* logic:iterate */
org.apache.struts.taglib.logic.IterateTag _jspx_th_logic_iterate_1 =
(org.apache.struts.taglib.logic.IterateTag)
_jspx_tagPool_logic_iterate_id.get(org.apache.struts.taglib.logic.IterateTag.class);
_jspx_th_logic_iterate_1.setPageContext(pageContext);
_jspx_th_logic_iterate_1.setParent(null);
_jspx_th_logic_iterate_1.setId(i);
int _jspx_eval_logic_iterate_1 = _jspx_th_logic_iterate_1.doStartTag();
if (_jspx_eval_logic_iterate_1 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
if (_jspx_eval_logic_iterate_1 !=
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {
javax.servlet.jsp.tagext.BodyContent _bc = pageContext.pushBody();
_bc.clear();
out = _bc;
_jspx_th_logic_iterate_1.setBodyContent(_bc);
_jspx_th_logic_iterate_1.doInitBody();
}
do {
i = (java.lang.Object) pageContext.findAttribute(i);
out.write(\n);
} while (_jspx_th_logic_iterate_1.doAfterBody() ==
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
if (_jspx_eval_logic_iterate_1 !=
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE)
out = pageContext.popBody();
}
if (_jspx_th_logic_iterate_1.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
_jspx_tagPool_logic_iterate_id.reuse(_jspx_th_logic_iterate_1);
out.write(\n\n);
} catch (Throwable t) {
out = _jspx_out;
if (out != null out.getBufferSize() != 0)
Re: Jasper2: serious problem with tag declarations
Jan Luehe wrote: Hi Costin, But there is still a problem - now if you have: logic:iterate id='i' /logic:iterate logic:iterate id='i' /logic:iterate ( i.e. the same variable name ), it will fail with duplicated declaration, the code will be: Object i; ... Object i; ( id is nested ). The above code fragment compiles fine for me. I've attached the generated servlet code. Can you send me the exact page you are trying to run? If you could provide the generated code, that would help, too. If those variable declaration problems are fixed, I'll release a new 4.1.6 milestone as soon as I can fix the JNDI problems. Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
On Fri, 21 Jun 2002, Remy Maucherat wrote:
If those variable declaration problems are fixed, I'll release a new
4.1.6 milestone as soon as I can fix the JNDI problems.
Not yet...
I attached the failed jsp.
Costin
package JspServ;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import org.apache.jasper.runtime.*;
public class b$jsp extends HttpJspBase {
private static java.util.Vector _jspx_includes;
private org.apache.jasper.runtime.TagHandlerPool
_jspx_tagPool_logic_iterate_property_name_id;
private org.apache.jasper.runtime.TagHandlerPool _jspx_tagPool_logic_present_name;
public b$jsp() {
_jspx_tagPool_logic_iterate_property_name_id = new
org.apache.jasper.runtime.TagHandlerPool();
_jspx_tagPool_logic_present_name = new org.apache.jasper.runtime.TagHandlerPool();
}
public java.util.List getIncludes() {
return _jspx_includes;
}
public void jspDestroy() {
_jspx_tagPool_logic_iterate_property_name_id.release();
_jspx_tagPool_logic_present_name.release();
}
public void _jspService(HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException, ServletException {
JspFactory _jspxFactory = null;
javax.servlet.jsp.PageContext pageContext = null;
HttpSession session = null;
ServletContext application = null;
ServletConfig config = null;
JspWriter out = null;
Object page = this;
JspWriter _jspx_out = null;
try {
_jspxFactory = JspFactory.getDefaultFactory();
response.setContentType(text/html;ISO-8859-1);
pageContext = _jspxFactory.getPageContext(this, request, response,
null, true, 8192, true);
application = pageContext.getServletContext();
config = pageContext.getServletConfig();
session = pageContext.getSession();
out = pageContext.getOut();
_jspx_out = out;
out.write(\n);
out.write(\n\n);
/* logic:iterate */
java.lang.Object a;
org.apache.struts.taglib.logic.IterateTag _jspx_th_logic_iterate_0 =
(org.apache.struts.taglib.logic.IterateTag)
_jspx_tagPool_logic_iterate_property_name_id.get(org.apache.struts.taglib.logic.IterateTag.class);
_jspx_th_logic_iterate_0.setPageContext(pageContext);
_jspx_th_logic_iterate_0.setParent(null);
_jspx_th_logic_iterate_0.setId(a);
_jspx_th_logic_iterate_0.setName(foo);
_jspx_th_logic_iterate_0.setProperty(bar);
int _jspx_eval_logic_iterate_0 = _jspx_th_logic_iterate_0.doStartTag();
if (_jspx_eval_logic_iterate_0 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
if (_jspx_eval_logic_iterate_0 !=
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {
javax.servlet.jsp.tagext.BodyContent _bc = pageContext.pushBody();
_bc.clear();
out = _bc;
_jspx_th_logic_iterate_0.setBodyContent(_bc);
_jspx_th_logic_iterate_0.doInitBody();
}
do {
a = (java.lang.Object) pageContext.findAttribute(a);
out.write(\n);
} while (_jspx_th_logic_iterate_0.doAfterBody() ==
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
if (_jspx_eval_logic_iterate_0 !=
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE)
out = pageContext.popBody();
}
if (_jspx_th_logic_iterate_0.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
_jspx_tagPool_logic_iterate_property_name_id.reuse(_jspx_th_logic_iterate_0);
out.write(\n\n);
/* logic:present */
org.apache.struts.taglib.logic.PresentTag _jspx_th_logic_present_0 =
(org.apache.struts.taglib.logic.PresentTag)
_jspx_tagPool_logic_present_name.get(org.apache.struts.taglib.logic.PresentTag.class);
_jspx_th_logic_present_0.setPageContext(pageContext);
_jspx_th_logic_present_0.setParent(null);
_jspx_th_logic_present_0.setName(b);
int _jspx_eval_logic_present_0 = _jspx_th_logic_present_0.doStartTag();
if (_jspx_eval_logic_present_0 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
do {
out.write(\n);
/* logic:iterate */
java.lang.Object a;
org.apache.struts.taglib.logic.IterateTag _jspx_th_logic_iterate_1 =
(org.apache.struts.taglib.logic.IterateTag)
_jspx_tagPool_logic_iterate_property_name_id.get(org.apache.struts.taglib.logic.IterateTag.class);
_jspx_th_logic_iterate_1.setPageContext(pageContext);
_jspx_th_logic_iterate_1.setParent(_jspx_th_logic_present_0);
_jspx_th_logic_iterate_1.setId(a);
_jspx_th_logic_iterate_1.setName(foo);
_jspx_th_logic_iterate_1.setProperty(bar);
int _jspx_eval_logic_iterate_1 = _jspx_th_logic_iterate_1.doStartTag();
if (_jspx_eval_logic_iterate_1 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
if
Re: Jasper2: serious problem with tag declarations
Thanks, I'll try it out.
I'm a bit worried here - most of the stuff is pretty basic and
common use of tags. Watchdog and the test suite was supposed
to detect that withou any problems.
I'll vote for 'alpha' status for the next build,
and I hope more people will check their apps against it -
I like the changes that are going on, but we need a bit
more testing.
How do we deal with nested tags of different type ? I don't have
a test case, but I assume someone may have a NESTED tag
'foo' in 2 different tags, with different declared types ( String and
Integer ). The current generator seems to not create { },
and I'm not sure how this will work.
( no test case - but I'm sure you can find such tags )
Costin
On Fri, 21 Jun 2002, Jan Luehe wrote:
Costin,
If those variable declaration problems are fixed, I'll release a new
4.1.6 milestone as soon as I can fix the JNDI problems.
Not yet...
I attached the failed jsp.
Costin
[...]
%@ page language=java %
%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
logic:iterate id=a name=foo property=bar
/logic:iterate
logic:present name=b
logic:iterate id=a name=foo property=bar
/logic:iterate
/logic:present
last and final attempt! :)
The attached patch should fix the last issue you brought up.
Since I am still waiting for my commit privileges, Kin-Man
has again volunteered to apply the patch. Thanks Kin-Man!
Jan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
Costin,
I'm a bit worried here - most of the stuff is pretty basic and
common use of tags. Watchdog and the test suite was supposed
to detect that withou any problems.
Use of scripting varibles in nested tag never work before, so obviously
no body uses it much. I think the whole scripting variable in JSP1.2 is
poorly designed, and not well understood.
I am also surprised that how much watchdog *does not* test!
I'll vote for 'alpha' status for the next build,
and I hope more people will check their apps against it -
I like the changes that are going on, but we need a bit
more testing.
How do we deal with nested tags of different type ? I don't have
a test case, but I assume someone may have a NESTED tag
'foo' in 2 different tags, with different declared types ( String and
Integer ). The current generator seems to not create { },
and I'm not sure how this will work.
( no test case - but I'm sure you can find such tags )
That would not work, and would never be made to work, not only for
nested case, but also for non-nested tags with AT_BEGIN scopes.
I tend to think this falls into the user's reponsibility if she uses
the same variable name for two different types, somewhat analogous to
declaring two variables of the same name two different types in Java.
Hopefully, there won't be a need for scripting variables anymore when
expression language becomes available in JSP2.0.
-Kin-man
Costin
On Fri, 21 Jun 2002, Jan Luehe wrote:
Costin,
If those variable declaration problems are fixed, I'll release a
new
4.1.6 milestone as soon as I can fix the JNDI problems.
Not yet...
I attached the failed jsp.
Costin
[...]
%@ page language=java %
%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
logic:iterate id=a name=foo property=bar
/logic:iterate
logic:present name=b
logic:iterate id=a name=foo property=bar
/logic:iterate
/logic:present
last and final attempt! :)
The attached patch should fix the last issue you brought up.
Since I am still waiting for my commit privileges, Kin-Man
has again volunteered to apply the patch. Thanks Kin-Man!
Jan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
On Fri, 21 Jun 2002, Kin-Man Chung wrote:
Use of scripting varibles in nested tag never work before, so obviously
no body uses it much. I think the whole scripting variable in JSP1.2 is
poorly designed, and not well understood.
The failures are from an app that worked perfectly fine with
jasper1, and with jasper2 ( up to 4.1.4 ).
And IMHO are very elementary use cases - 2 iterates and one
condition is not that infrequent.
How do we deal with nested tags of different type ? I don't have
a test case, but I assume someone may have a NESTED tag
'foo' in 2 different tags, with different declared types ( String and
Integer ). The current generator seems to not create { },
and I'm not sure how this will work.
( no test case - but I'm sure you can find such tags )
That would not work, and would never be made to work, not only for
nested case, but also for non-nested tags with AT_BEGIN scopes.
I tend to think this falls into the user's reponsibility if she uses
the same variable name for two different types, somewhat analogous to
declaring two variables of the same name two different types in Java.
I'm lost here - wasn't NESTED supposed to define a lexical scoping ?
I don't see why this wouldn't work - are you saying it doesn't
work with jasper2, it didn't worked with jasper1, or is not
required by the spec ?
Hopefully, there won't be a need for scripting variables anymore when
expression language becomes available in JSP2.0.
:-)
Unfortunately JSP1.x will be around for a while, and jasper must support
it.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
On Fri, 21 Jun 2002, Jan Luehe wrote:
the current approach should be able to handle a NESTED 'foo' in 2
different tags, with different declared types, as long as one tag
isn't nested inside the other. The current approach will generate code
like this:
{
Integer foo;
}
{
String foo;
}
However, the current approach will not work if one such tag is nested
inside the other. Because of the nesting, 'foo' may be declared only
by the encapsulating tag, and would have to be declared as of type
Object to accommodate the different types, but this could break
scripting code expecting the more specific type.
Of course it won't work for nesting. But if not nested - I think
it should work.
Looking at the generated code, I don't see any generated { },
that's why I was worried. I'll try this with the new patch,
maybe it's fixed now.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jasper2: serious problem with tag declarations
Hi Costin,
More info:
The page is:
%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
logic:iterate id=id1 name=name1 property=prop1
logic:iterate id=id2 name=name2 property=prop2
Foo
/logic:iterate
/logic:iterate
I get:
a$jsp.java:75:25:75:25: Error: No entity named id2 was found in this
environment.
And the generated code is:
.
/* logic:iterate */
java.lang.Object _jspx_id2_1;
_jspx_id2_1 = id2;
org.apache.struts.taglib.logic.IterateTag
_jspx_th_logic_iterate_1 = (org.apache.struts.taglib.logic.IterateTag)
_jspx_tagPool_logic_iterate_property_name_id.get(org.apache.struts.taglib.logic.
IterateTag.class);
No 'id2' is ever declared.
I was unable to reproduce the problem where a scripting variable is being
declared multiple times. That used to be a bug with Jasper, which we
fixed in Jasper2.
However, I was able to reproduce the above problem with nested
logic:iterate tags where 'id2' is never declared.
The nested logic:iterate did not declare any of its NESTED scripting
variables, since it assumed that those had already been declared by the
encapsulating logic:iterate. This approach did not take into account
the case where a tag's TEI determines the name of a scripting
variable from the tag's id attribute.
Attached is a patch that fixes the problem. Kin-Man has volunteered
to apply it. I still don't seem to have commit privileges for tomcat.
Let me know if you still run into any problems.
Thanks,
Jan
Executing ssh-askpass to query the password...
Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on
the server side.
? build
? build.properties
cvs server: Diffing .
cvs server: Diffing doc
cvs server: Diffing src
cvs server: Diffing src/bin
cvs server: Diffing src/share
cvs server: Diffing src/share/org
cvs server: Diffing src/share/org/apache
cvs server: Diffing src/share/org/apache/jasper
cvs server: Diffing src/share/org/apache/jasper/compiler
Index: src/share/org/apache/jasper/compiler/Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.30
diff -u -r1.30 Generator.java
--- src/share/org/apache/jasper/compiler/Generator.java 13 Jun 2002 22:56:11 -
1.30
+++ src/share/org/apache/jasper/compiler/Generator.java 21 Jun 2002 00:20:17 -
@@ -1467,14 +1467,21 @@
/*
* Declares any NESTED scripting variables of the given custom tag,
* if the given custom tag is not nested inside itself (i.e, has a
-* nesting level of zero). In addition, a NESTED scripting variable is
-* declared only if it has not already been declared in the same scope
-* in the generated code, that is, if this custom tag's parent is
+* nesting level of zero). If the custom tag does have a custom nesting
+* level greater than 0, this method declares a scripting variable
+* derived from the tag's id attribute (if present), only if its
+* scope is NESTED and it does not match the id attribute of any of
+* the enclosing tags of the same (custom) type.
+*
+* Additionally, a NESTED scripting variable is declared only if it
+* has not already been declared in the same Java
+* scope of the generated code, that is, if this custom tag's parent is
* different from the parent of the custom tag that may already have
* declared this variable.
*/
private void declareNestedScriptingVariables(Node.CustomTag n) {
- if (n.getCustomNestingLevel() 0) {
+
+ if (n.getCustomNestingLevel() 0 !n.hasUnnestedIdAttribute()) {
return;
}
@@ -1485,17 +1492,42 @@
}
if (varInfos != null) {
- for (int i=0; ivarInfos.length; i++) {
- if ((varInfos[i].getScope() == VariableInfo.NESTED)
-varInfos[i].getDeclare()) {
- String name = varInfos[i].getVarName();
- Node parent = (Node) nestedVars.get(name);
- if ((parent == null) || (parent != n.getParent())) {
- out.printin(varInfos[i].getClassName());
- out.print( );
- out.print(name);
- out.println(;);
- nestedVars.put(name, n.getParent());
+ if (n.getCustomNestingLevel() == 0) {
+ // Declare *any* scripting variables with NESTED scope
+ for (int i=0; ivarInfos.length; i++) {
+ if ((varInfos[i].getScope() == VariableInfo.NESTED)
+varInfos[i].getDeclare()) {
+
RE: Jasper2: serious problem with tag declarations
Many thanks Jan and Kin-Man. But there is still a problem - now if you have: logic:iterate id='i' /logic:iterate logic:iterate id='i' /logic:iterate ( i.e. the same variable name ), it will fail with duplicated declaration, the code will be: Object i; ... Object i; ( id is nested ). As I mentioned, the 4.1.4 milestone doesn't have this problem ( it has others, but easier to get around ). Costin On Thu, 20 Jun 2002, Jan Luehe wrote: Hi Costin, More info: The page is: %@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % logic:iterate id=id1 name=name1 property=prop1 logic:iterate id=id2 name=name2 property=prop2 Foo /logic:iterate /logic:iterate I get: a$jsp.java:75:25:75:25: Error: No entity named id2 was found in this environment. And the generated code is: . /* logic:iterate */ java.lang.Object _jspx_id2_1; _jspx_id2_1 = id2; org.apache.struts.taglib.logic.IterateTag _jspx_th_logic_iterate_1 = (org.apache.struts.taglib.logic.IterateTag) _jspx_tagPool_logic_iterate_property_name_id.get(org.apache.struts.taglib.logic. IterateTag.class); No 'id2' is ever declared. I was unable to reproduce the problem where a scripting variable is being declared multiple times. That used to be a bug with Jasper, which we fixed in Jasper2. However, I was able to reproduce the above problem with nested logic:iterate tags where 'id2' is never declared. The nested logic:iterate did not declare any of its NESTED scripting variables, since it assumed that those had already been declared by the encapsulating logic:iterate. This approach did not take into account the case where a tag's TEI determines the name of a scripting variable from the tag's id attribute. Attached is a patch that fixes the problem. Kin-Man has volunteered to apply it. I still don't seem to have commit privileges for tomcat. Let me know if you still run into any problems. Thanks, Jan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jasper2: serious problem with tag declarations
The scope of scripting variables from tags is specified in the Tag. From the 1.1 spec:
The defined values for scope are:
· NESTED, if the scripting variable is available between the start tag and the end tag
of the
action that defines it.
· AT_BEGIN, if the scripting variable is available from the start tag of the action
that
defines it until the end of the page.
· AT_END, if the scripting variable is available after the end tag of the action that
defines
it until the end of the page.
The scope value for a variable implies what methods may affect its value...
So while declaring two id's the same is an error IMO, the specific tag logic:iterate
should probably be NESTED rather than AT_BEGIN (which is what's happening).
Checking the struts code (org.apache.struts.taglib.logic.IterateTei), it is indeed
declared as NESTED. Looks like a Jasper 2 bug then. Time for a few extra {}'s?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 18 June 2002 06:44
To: Tomcat Developers List; Kin-Man Chung
Subject: Re: Jasper2: serious problem with tag declarations
On Mon, 17 Jun 2002, Kin-Man Chung wrote:
Costin,
I am not aware that id attribute is handled differently in a tag.
Can you give a test case for this? I can look into it more. Thanks.
I'll try to extract a test case.
There is nothing special about 'id' - just 2 consecutive struts
logic:iterate id='foo' . This generates a variable 'foo'
( via TLD/TagInfo/etc ), and the problem is that the variable foo is
declared twice ( there are 2 'Object foo;' in the same scope ).
I'm not very familiar with struts ( but you may find some
experts on this list :-), but unless I'm doing something very
stupid in the page, this issue may be serious.
Costin
- Kin-man
Date: Mon, 17 Jun 2002 10:41:07 -0700 (PDT)
From: [EMAIL PROTECTED]
Subject: Jasper2: serious problem with tag declarations
X-X-Sender: [EMAIL PROTECTED]
To: List Tomcat-Dev [EMAIL PROTECTED]
MIME-version: 1.0
Delivered-to: mailing list [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
X-Antivirus: nagoya (v4198 created Apr 24 2002)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Authentication-warning: costinm.sfo.covalent.net: costin owned process doing
-bs
List-Post: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
I see some errors, not sure yet if it's an error in the taglibs or
jasper but seems serious. ( the taglibs are from struts ).
There are few logic:iterate id=foo tags in the page, using the
same id, and the generated code has:
Object foo;
Object foo;
...
That obviously doesn't compile.
I don't know too much about struts, but I suppose it is valid to use
the same value in 2 tag attributes, couldn't find any reference on
the contrary in the spec.
It workes fine with older jasper.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jasper2: serious problem with tag declarations
Date: Tue, 18 Jun 2002 11:04:10 +0100
From: [EMAIL PROTECTED]
Subject: RE: Jasper2: serious problem with tag declarations
To: [EMAIL PROTECTED]
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3
Content-transfer-encoding: quoted-printable
Content-class: urn:content-classes:message
Delivered-to: mailing list [EMAIL PROTECTED]
Thread-topic: Jasper2: serious problem with tag declarations
Thread-index: AcIWizWxrE/eTDHgQNOcNern1B02QQAIq6BA
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
X-Antivirus: nagoya (v4198 created Apr 24 2002)
X-WDR-Disclaimer: Version $Revision: 1.15 $
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
List-Post: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
X-OriginalArrivalTime: 18 Jun 2002 10:04:11.0284 (UTC)
FILETIME=[7E3D7540:01C216AF]
The scope of scripting variables from tags is specified in the Tag. From the
1.1 spec:
The defined values for scope are:
· NESTED, if the scripting variable is available between the start tag and the
end tag of the
action that defines it.
· AT_BEGIN, if the scripting variable is available from the start tag of the
action that
defines it until the end of the page.
· AT_END, if the scripting variable is available after the end tag of the
action that defines
it until the end of the page.
The scope value for a variable implies what methods may affect its value...
So while declaring two id's the same is an error IMO, the specific tag
logic:iterate should probably be NESTED rather than AT_BEGIN (which is what's
happening).
Checking the struts code (org.apache.struts.taglib.logic.IterateTei), it is
indeed declared as NESTED. Looks like a Jasper 2 bug then. Time for a few extra
{}'s?
Having extra {}'s is not going to work, because it's not legal java to
have variables of the same name in a method, even if one is in the block
nested with another block containing the other.
There was a problem with scripting variables when a tag is nested in
the same tag, because of the above problem. But that has been fixed
recently in jasper2. If costin's page works in old jasper, but not
in jasper2, then it must be something else.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 18 June 2002 06:44
To: Tomcat Developers List; Kin-Man Chung
Subject: Re: Jasper2: serious problem with tag declarations
On Mon, 17 Jun 2002, Kin-Man Chung wrote:
Costin,
I am not aware that id attribute is handled differently in a tag.
Can you give a test case for this? I can look into it more. Thanks.
I'll try to extract a test case.
There is nothing special about 'id' - just 2 consecutive struts
logic:iterate id='foo' . This generates a variable 'foo'
( via TLD/TagInfo/etc ), and the problem is that the variable foo is
declared twice ( there are 2 'Object foo;' in the same scope ).
I'm not very familiar with struts ( but you may find some
experts on this list :-), but unless I'm doing something very
stupid in the page, this issue may be serious.
Costin
- Kin-man
Date: Mon, 17 Jun 2002 10:41:07 -0700 (PDT)
From: [EMAIL PROTECTED]
Subject: Jasper2: serious problem with tag declarations
X-X-Sender: [EMAIL PROTECTED]
To: List Tomcat-Dev [EMAIL PROTECTED]
MIME-version: 1.0
Delivered-to: mailing list [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
X-Antivirus: nagoya (v4198 created Apr 24 2002)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Authentication-warning: costinm.sfo.covalent.net: costin owned process
doing
-bs
List-Post: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
I see some errors, not sure yet if it's an error in the taglibs or
jasper but seems serious. ( the taglibs are from struts ).
There are few logic:iterate id=foo tags in the page, using the
same id, and the generated code has:
Object foo;
Object foo;
...
That obviously doesn't compile.
I don't know too much about struts, but I suppose it is valid to use
the same value in 2 tag attributes, couldn't find any reference on
the contrary in the spec.
It workes fine with older jasper.
Costin
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto
RE: Jasper2: serious problem with tag declarations
On Tue, 18 Jun 2002, Kin-Man Chung wrote:
Having extra {}'s is not going to work, because it's not legal java to
have variables of the same name in a method, even if one is in the block
nested with another block containing the other.
There was a problem with scripting variables when a tag is nested in
the same tag, because of the above problem. But that has been fixed
recently in jasper2. If costin's page works in old jasper, but not
in jasper2, then it must be something else.
I think it's exactly that, a NESTED which doesn't nest.
I have few other problems to solve first, sorry for not getting back.
Are there any tests with nested in watchdog ? I could work on one
and try to reproduce ( or find what's going wrong ).
BTW, I noticed that the .tlds and are parsed on every page
compilation. Can I add an option to allow bad developers to disable
at least validation ? ( I know a good developer will validate the xml
as many times as possible, to be sure :-). I also have a small patch that
caches the trees ( well, if I had more time I would get rid of
the whole DOM-tree duplication and use dom directly ).
Costin
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 18 June 2002 06:44
To: Tomcat Developers List; Kin-Man Chung
Subject: Re: Jasper2: serious problem with tag declarations
On Mon, 17 Jun 2002, Kin-Man Chung wrote:
Costin,
I am not aware that id attribute is handled differently in a tag.
Can you give a test case for this? I can look into it more. Thanks.
I'll try to extract a test case.
There is nothing special about 'id' - just 2 consecutive struts
logic:iterate id='foo' . This generates a variable 'foo'
( via TLD/TagInfo/etc ), and the problem is that the variable foo is
declared twice ( there are 2 'Object foo;' in the same scope ).
I'm not very familiar with struts ( but you may find some
experts on this list :-), but unless I'm doing something very
stupid in the page, this issue may be serious.
Costin
- Kin-man
Date: Mon, 17 Jun 2002 10:41:07 -0700 (PDT)
From: [EMAIL PROTECTED]
Subject: Jasper2: serious problem with tag declarations
X-X-Sender: [EMAIL PROTECTED]
To: List Tomcat-Dev [EMAIL PROTECTED]
MIME-version: 1.0
Delivered-to: mailing list [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
X-Antivirus: nagoya (v4198 created Apr 24 2002)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Authentication-warning: costinm.sfo.covalent.net: costin owned process
doing
-bs
List-Post: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
I see some errors, not sure yet if it's an error in the taglibs or
jasper but seems serious. ( the taglibs are from struts ).
There are few logic:iterate id=foo tags in the page, using the
same id, and the generated code has:
Object foo;
Object foo;
...
That obviously doesn't compile.
I don't know too much about struts, but I suppose it is valid to use
the same value in 2 tag attributes, couldn't find any reference on
the contrary in the spec.
It workes fine with older jasper.
Costin
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL
