You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ru...@us.ibm.com on 2000/07/02 16:15:51 UTC
3.2 beta status update
I've uploaded a 3.2 beta to
http://jakarta.apache.org/builds/tomcat/release/v3.2-beta-1/ in case
anybody wants to pound on it with me prior to wider availaiblity. I have
not uploaded any Linux or Windows specific binaries.
I've also created a branch for tomcat_32. Place any changes which you feel
*must* go into the release there. Business as usual can continue on the
main branch.
- Sam Ruby
Re: 3.2 beta status update
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Hans Bergsten wrote:
> [...]
> 2) Cookies, and likely any other header, can not be set in a JSP page
> if the page redirects. This looks like a problem discussed earlier
> that I thought was fixed already.
I tracked down this problem. The call trace goes like this:
HttpServletResponseFacade.sendRedirect()
HttpServletResponseFacade.sendError()
ContextManager.handleStatus()
ResponseImpl.reset()
In reset(), all cookies except session cookies are removed, and
all other headers are removed unless the servlet is called
through include().
That was the easy part. The hard part is to decide how this should
be fixed. The reset() method seems to be doing what the name implies,
but maybe it shouldn't be called from handleStatus()? How about calling
ResponseImpl.resetBuffer() instead? It clears the response body but
leaves all headers alone.
If no one objects, I will make this change later today when I have
tracked down the other problems.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: Incorrect code for custom actions [Was: Re: 3.2 beta status update]
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Danno Ferrin wrote:
>
> Here is a quick fix that should solve the problem in a single threaded
> environment. And you are right on about the race conditions, where multiple
> paralell compilations could cause a race, but there is a lock in JspServlet
> where it locks on "this" that solves most races, but in the case where a
> pool of servlet instances services the JspServlet there could be a
> colission. IIRC such pooling is not barred by the spec, (and there are
> other ways to induce that race) so synching on TagGeneratorBase.class in
> lines 178-183 of .../jasper/compiler/Compiler.java should end that race, it
> appears to me to be the best gate point around the JspParseEventListener
> class, which is the only class to use instances of TagGeneratorBase
> sub-classes and classes. A better long-term solution would be to move the
> services provided by those static classes into the JspCompliationContext
> class (which would require an API change which instantly makes it a 3.3
> target)
>
> But I digress, here is a patch you can try.
> [...]
Thanks for your help. I had already started to fix it in a different way
when I got your mail, see the commit message. If you see any problems
with my solution, please let me know.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: Incorrect code for custom actions [Was: Re: 3.2 beta status update]
Posted by Danno Ferrin <sh...@earthlink.net>.
Here is a quick fix that should solve the problem in a single threaded
environment. And you are right on about the race conditions, where multiple
paralell compilations could cause a race, but there is a lock in JspServlet
where it locks on "this" that solves most races, but in the case where a
pool of servlet instances services the JspServlet there could be a
colission. IIRC such pooling is not barred by the spec, (and there are
other ways to induce that race) so synching on TagGeneratorBase.class in
lines 178-183 of .../jasper/compiler/Compiler.java should end that race, it
appears to me to be the best gate point around the JspParseEventListener
class, which is the only class to use instances of TagGeneratorBase
sub-classes and classes. A better long-term solution would be to move the
services provided by those static classes into the JspCompliationContext
class (which would require an API change which instantly makes it a 3.3
target)
But I digress, here is a patch you can try.
Index: TagBeginGenerator.java
===================================================================
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagBegin
Generator.java,v
retrieving revision 1.14
diff -U3 -r1.14 TagBeginGenerator.java
--- TagBeginGenerator.java 2000/06/14 22:51:52 1.14
+++ TagBeginGenerator.java 2000/07/03 05:46:16
@@ -199,11 +199,13 @@
String attrName = attributes[i].getName();
Method m = tc.getSetterMethod(attrName);
- if (m == null)
+ if (m == null) {
+ tagEnd();
throw new CompileException
(start, Constants.getString
("jsp.error.unable.to_find_method",
new Object[] { attrName }));
+ }
writer.println(thVarName+"."+m.getName()+"("+attrValue+");");
}
----- Original Message -----
From: "Hans Bergsten" <ha...@gefionsoftware.com>
To: <to...@jakarta.apache.org>
Sent: Sunday, July 02, 2000 9:56 PM
Subject: Incorrect code for custom actions [Was: Re: 3.2 beta status update]
> Hans Bergsten wrote:
> > [...]
> > I've tested the 3.2 beta with two tag libraries that were working fine
with
> > Tomcat 3.1, using JDK 1.3 and JDK 1.2.2 on Windows NT. I noticed the
> > following problems:
> > [...]
> > 3) Incorrect code generated for some custom actions.
>
> Okay, I believe I have tracked down this problem now. But since the code
for
> generating the JSP implementation class is far from obvious, I would
appreciate
> if someone who's familiar with the code can confirm my findings.
>
> The problem occurs in this scenario. First, the generation of the JSP
> implementation
> class for one page fails, due to a missing setter method for a custom
action
> attribute. This results in a CompileException being thrown by the
> TagBeginGenerator
> generateSetters() method. This is the expected behavior.
>
> After this failure, though, processing of *any* page containing a custom
action
> results in invalid code being generated. Example:
>
> com.ora.jsp.tags.counter.IncrementCounterTag
_jspx_th_ora_incrementCounter_0 =
> new com.ora.jsp.tags.counter.IncrementCounterTag();
> _jspx_th_ora_incrementCounter_0.setPageContext(pageContext);
> _jspx_th_ora_incrementCounter_0.setParent(_jspx_th_iob_dbStore_0);
>
> The _jspx_th_iob_dbStore_0 variable refers to the tag handler in the first
page,
> i.e. the one with the missing setter method; it's not defined at all in
this
> page.
>
> The reason is that the state of a static variable in TagGeneratorBase is
busted:
>
> static private Stack tagHandlerStack = new Stack();
>
> This Stack seems to be intended to hold the nesting hierarchy for action
> elements within a page. I have not traced through all code, but it seems
like
> if the code generation goes well, the state of the Stack is maintained by
an
> equal number of push() and pop() calls, but if the code generation fails,
junk
> is left on the Stack.
>
> I can't understand why this is a static variable; making it a regular
instance
> variable should solve the problem since a new instance of TagGeneratorBase
is
> created for each page. Having it as a static probably means that there are
> multi-threading issues as well, even though I haven't run into them yet.
> There's one more static in this class:
>
> static private Hashtable tagVarNumbers = new Hashtable();
>
> I'm not sure how it's used, but it can probably cause similar problems.
>
> My suggestion is to simple make both these variables regular instance
variables.
> If I'm missing something, please let me know.
>
> Hans
> --
> Hans Bergsten hans@gefionsoftware.com
> Gefion Software http://www.gefionsoftware.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Incorrect code for custom actions [Was: Re: 3.2 beta status update]
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Hans Bergsten wrote:
> [...]
> I've tested the 3.2 beta with two tag libraries that were working fine with
> Tomcat 3.1, using JDK 1.3 and JDK 1.2.2 on Windows NT. I noticed the
> following problems:
> [...]
> 3) Incorrect code generated for some custom actions.
Okay, I believe I have tracked down this problem now. But since the code for
generating the JSP implementation class is far from obvious, I would appreciate
if someone who's familiar with the code can confirm my findings.
The problem occurs in this scenario. First, the generation of the JSP
implementation
class for one page fails, due to a missing setter method for a custom action
attribute. This results in a CompileException being thrown by the
TagBeginGenerator
generateSetters() method. This is the expected behavior.
After this failure, though, processing of *any* page containing a custom action
results in invalid code being generated. Example:
com.ora.jsp.tags.counter.IncrementCounterTag _jspx_th_ora_incrementCounter_0 =
new com.ora.jsp.tags.counter.IncrementCounterTag();
_jspx_th_ora_incrementCounter_0.setPageContext(pageContext);
_jspx_th_ora_incrementCounter_0.setParent(_jspx_th_iob_dbStore_0);
The _jspx_th_iob_dbStore_0 variable refers to the tag handler in the first page,
i.e. the one with the missing setter method; it's not defined at all in this
page.
The reason is that the state of a static variable in TagGeneratorBase is busted:
static private Stack tagHandlerStack = new Stack();
This Stack seems to be intended to hold the nesting hierarchy for action
elements within a page. I have not traced through all code, but it seems like
if the code generation goes well, the state of the Stack is maintained by an
equal number of push() and pop() calls, but if the code generation fails, junk
is left on the Stack.
I can't understand why this is a static variable; making it a regular instance
variable should solve the problem since a new instance of TagGeneratorBase is
created for each page. Having it as a static probably means that there are
multi-threading issues as well, even though I haven't run into them yet.
There's one more static in this class:
static private Hashtable tagVarNumbers = new Hashtable();
I'm not sure how it's used, but it can probably cause similar problems.
My suggestion is to simple make both these variables regular instance variables.
If I'm missing something, please let me know.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: 3.2 beta status update
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Hans Bergsten wrote:
> [...]
> I've tested the 3.2 beta with two tag libraries that were working fine with
> Tomcat 3.1, using JDK 1.3 and JDK 1.2.2 on Windows NT. I noticed the
> following problems:
>
> 1) URL rewriting seems to be broken again,
> 2) Cookies, and likely any other header, can not be set in a JSP page
> if the page redirects. This looks like a problem discussed earlier
> that I thought was fixed already.
> 3) Incorrect code generated for some custom actions.
>
> I will try to locate and fix these problems. I feel that they are all
> too serious to let 3.2 be released before they are fixed. If someone
> already has a fix for one or more, please let us know.
All of these are solved now and committed to both the main branch and
the tomcat_32 branch.
If anyone has the time (I'm afraid I don't) to do some stress testing
on Jasper, I think it would be a good idea. Number 3) above turned out
to be caused by static variables, missing resets in error cases, and
possibly a lack of synchronization here and there. Even after the fix
I did, there may be other similar cases that cause problems.
I'm also pretty sure there's a number of synchronization points that can
be removed after my fix, and with similar changes in other places, there
may be even more. I'm not familiar enough with the code to dare do any
major changes here, but if someone who is has the time, it would be
great. This should probably be done for 3.3 instead of 3.2 though.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: 3.2 beta status update
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
rubys@us.ibm.com wrote:
>
> I've uploaded a 3.2 beta to
> http://jakarta.apache.org/builds/tomcat/release/v3.2-beta-1/ in case
> anybody wants to pound on it with me prior to wider availaiblity. I have
> not uploaded any Linux or Windows specific binaries.
>
> I've also created a branch for tomcat_32. Place any changes which you feel
> *must* go into the release there. Business as usual can continue on the
> main branch.
I've tested the 3.2 beta with two tag libraries that were working fine with
Tomcat 3.1, using JDK 1.3 and JDK 1.2.2 on Windows NT. I noticed the
following problems:
1) URL rewriting seems to be broken again,
2) Cookies, and likely any other header, can not be set in a JSP page
if the page redirects. This looks like a problem discussed earlier
that I thought was fixed already.
3) Incorrect code generated for some custom actions.
I will try to locate and fix these problems. I feel that they are all
too serious to let 3.2 be released before they are fixed. If someone
already has a fix for one or more, please let us know.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: 3.2 beta status update
Posted by Jim Rudnicki <jd...@pacbell.net>.
My previous Draft email _escaped_ before I could complete the message.
I had problems with JDK 1.1.2, but
using Sun JDK 1.1.8-004 (whats with these minor minor minor versions, aren't
two decimal places enough?!)
All works well. Except for one thing:
I have to edit every .bat file that had as its first line:
@echo off.
There is some quirkiness about the obstinate cr-lf problem. If I add a rem
line before the @echo line, the batch files run without fixing all the line
terminators. This might be a protective patch.
So if 1.2 is not supported yet, then ignore my previous post.
Jim
Re: 3.2 beta status update
Posted by Jim Rudnicki <jd...@pacbell.net>.
> I've uploaded a 3.2 beta to
> http://jakarta.apache.org/builds/tomcat/release/v3.2-beta-1/ in case
> anybody wants to pound on it with me prior to wider availaiblity.
I just built this Win98/Sun JD1.2.2-001
Problems I found:
server.xml and web.xml are not being read from the conf directory, they are
being read from the bin directory
The server will not start due to some confusion about the packaging of
Jasper. The trace below shows that the
classloader is looking in org.apache.jasper.runtime, while the class is
packaged in ___.servlet
java.lang.ClassNotFoundException: org.apache.jasper.runtime.JspLoader12
at java.net.URLClassLoader$1.run(URLClassLoader.java, Compiled Code)
at java.lang.Exception.<init>(Exception.java, Compiled Code)
at
java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java,Compiled
Code)
at java.net.URLClassLoader$1.run(URLClassLoader.java, Compiled Code)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java, Compiled
Code)
at java.lang.ClassLoader.loadClass(ClassLoader.java, Compiled Code)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java,
Compiled Code)
at java.lang.ClassLoader.loadClass(ClassLoader.java, Compiled Code)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:124)
at org.apache.jasper.runtime.JspServlet.init(JspServlet.java:246)
at
org.apache.tomcat.core.ServletWrapper.doInit(ServletWrapper.java:309)
at org.apache.tomcat.core.Handler.init(Handler.java:215)
at
org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:288)
at
org.apache.tomcat.context.LoadOnStartupInterceptor.contextInit(LoadOnStartup
Interceptor.java, Compiled Code)
at
org.apache.tomcat.core.ContextManager.initContext(ContextManager.java,
Compiled Code)
at org.apache.tomcat.core.ContextManager.init(ContextManager.java,
Compiled Code)
at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:197)
at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:237)
Exception in thread "main" java.lang.InstantiationError:
org/apache/jasper/runtime/JspLoader
at org.apache.jasper.runtime.JspServlet.init(JspServlet.java:253)
at
org.apache.tomcat.core.ServletWrapper.doInit(ServletWrapper.java:309)
at org.apache.tomcat.core.Handler.init(Handler.java:215)
at
org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:288)
at
org.apache.tomcat.context.LoadOnStartupInterceptor.contextInit(LoadOnStartup
Interceptor.java, Compiled Code)
at
org.apache.tomcat.core.ContextManager.initContext(ContextManager.java,
Compiled Code)
at org.apache.tomcat.core.ContextManager.init(ContextManager.java,
Compiled Code)
at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:197)
at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:237)