BugRat Report #365 has been filed.
Bug report #365 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/365 REPORT #365 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: Tomcat-4.0-m4 JVM Release: - Operating System: Red Hat 6.2 OS Release: Platform: Synopsis: method getXMLReader() does not exist in javax.xml.parsers.SAXParser Description: When you compile the source code of tomcat milestone version 4.0 you will get an error when system compiles the file ParserXJspSax.java which will be compile in org.apache.jasper.compiler package. Error is ... Function getXMLReader() does not exist in javax.xml.parsers.SAXParser and it will stop the compilation. Title: BugRat Report # 365 BugRat Report # 365 Project: Tomcat Release: Tomcat-4.0-m4 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Amit Kaushik ([EMAIL PROTECTED]) Date Submitted: Nov 9 2000, 05:24:17 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: method getXMLReader() does not exist in javax.xml.parsers.SAXParser Environment: (jvm, os, osrel, platform) -, Red Hat 6.2, , Additional Environment Description: Report Description: When you compile the source code of tomcat milestone version 4.0 you will get an error when system compiles the file ParserXJspSax.java which will be compile in org.apache.jasper.compiler package. Error is ... Function getXMLReader() does not exist in javax.xml.parsers.SAXParser and it will stop the compilation. Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #366 has been filed.
Bug report #366 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/366 REPORT #366 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: Tomcat-4.0-m4 JVM Release: - Operating System: Red Hat 6.2 OS Release: Platform: Synopsis: method getXMLReader() does not exist in javax.xml.parsers.SAXParser Description: When you compile the source code of tomcat milestone version 4.0 you will get an error when system compiles the file ParserXJspSax.java which will be compile in org.apache.jasper.compiler package. Error is ... Function getXMLReader() does not exist in javax.xml.parsers.SAXParser and it will stop the compilation. Title: BugRat Report # 366 BugRat Report # 366 Project: Tomcat Release: Tomcat-4.0-m4 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Amit Kaushik ([EMAIL PROTECTED]) Date Submitted: Nov 9 2000, 05:27:08 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: method getXMLReader() does not exist in javax.xml.parsers.SAXParser Environment: (jvm, os, osrel, platform) -, Red Hat 6.2, , Additional Environment Description: Report Description: When you compile the source code of tomcat milestone version 4.0 you will get an error when system compiles the file ParserXJspSax.java which will be compile in org.apache.jasper.compiler package. Error is ... Function getXMLReader() does not exist in javax.xml.parsers.SAXParser and it will stop the compilation. Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The Ping servlet
filename="text1.rtf" filename="text1.rtf"
Re: No revolution today
How? As far as I can tell it's broken in TC 3.1 / mod_jserv. Can you describe your configuration? On Thu, 9 Nov 2000, [EMAIL PROTECTED] wrote: On Wed, 8 Nov 2000, Nick Bauman wrote: On Thu, 9 Nov 2000, Henri Gomez wrote: It is important that tomcat3 has a design that allows support for future versions of the servlet API, but if tomcat developers don't want to see it happen - so be it. When Servlet2.3 will be final and in wide use, there is nothing that can stop someone from providing the module that supports it ( not necesarily from apache site ). Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for at least one or two years. Note that many importants sites still use Apache JServ (API 2.0) and GnuJSP. I for one, would love to see the 3.x codebase's Session API actually work "as advertised" in a web server farm with a rotator box like BigIP. Right now the Session API in tomcat 3.1 /does not work/ across multiple instances of tomcat in a server farm. umm...it does. i use it. -Ys- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpResponseImpl.java HttpResponseStream.java
remm00/11/09 10:52:09
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpResponseImpl.java HttpResponseStream.java
Log:
- The determination of the chunk mode flag is more dynamic. Before, it was
only determined when the stream was instantiated, which could lead to
problems.
Revision ChangesPath
1.3 +125 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseImpl.java
Index: HttpResponseImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseImpl.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- HttpResponseImpl.java 2000/10/07 05:27:35 1.2
+++ HttpResponseImpl.java 2000/11/09 18:52:08 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseImpl.java,v
1.2 2000/10/07 05:27:35 craigmcc Exp $
- * $Revision: 1.2 $
- * $Date: 2000/10/07 05:27:35 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseImpl.java,v
1.3 2000/11/09 18:52:08 remm Exp $
+ * $Revision: 1.3 $
+ * $Date: 2000/11/09 18:52:08 $
*
*
*
@@ -68,6 +68,7 @@
import java.io.IOException;
import java.io.PrintWriter;
import java.io.OutputStream;
+import java.util.ArrayList;
import javax.servlet.ServletOutputStream;
import org.apache.catalina.connector.HttpResponseBase;
@@ -76,7 +77,8 @@
* Implementation of bHttpResponse/b specific to the HTTP connector.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.2 $ $Date: 2000/10/07 05:27:35 $
+ * @author a href="mailto:[EMAIL PROTECTED]"Remy Maucherat/a
+ * @version $Revision: 1.3 $ $Date: 2000/11/09 18:52:08 $
*/
final class HttpResponseImpl
@@ -99,6 +101,12 @@
protected boolean allowChunking;
+/**
+ * Associated HTTP response stream.
+ */
+protected HttpResponseStream responseStream;
+
+
// - Properties
@@ -140,6 +148,7 @@
public void recycle() {
super.recycle();
+responseStream = null;
allowChunking = false;
}
@@ -194,8 +203,119 @@
* @exception IOException if an input/output error occurs
*/
public ServletOutputStream createOutputStream() throws IOException {
+
+responseStream = new HttpResponseStream(this);
+ return (responseStream);
+
+}
+
+
+/**
+ * Tests is the connection will be closed after the processing of the
+ * request.
+ */
+public boolean isCloseConnection() {
+String connectionValue = (String) getHeader("Connection");
+return (connectionValue != null
+ connectionValue.equals("close"));
+}
+
+
+/**
+ * Add the specified header to the specified value.
+ *
+ * @param name Name of the header to set
+ * @param value Value to be set
+ */
+public void addHeader(String name, String value) {
+
+ if (isCommitted())
+ return;
+
+ if (included)
+ return; // Ignore any call from an included servlet
+
+super.addHeader(name, value);
+
+if (name.equals("Connection") responseStream != null)
+responseStream.checkChunking(this);
+
+}
+
+
+
+
+/**
+ * Set the specified header to the specified value.
+ *
+ * @param name Name of the header to set
+ * @param value Value to be set
+ */
+public void setHeader(String name, String value) {
+
+ if (isCommitted())
+ return;
+
+ if (included)
+ return; // Ignore any call from an included servlet
+
+super.setHeader(name, value);
+
+if (name.equals("Connection") responseStream != null)
+responseStream.checkChunking(this);
+
+}
+
+
+/**
+ * Removes the specified header.
+ *
+ * @param name Name of the header to remove
+ * @param value Value to remove
+ */
+public void removeHeader(String name, String value) {
+
+ if (isCommitted())
+ return;
+
+ if (included)
+ return; // Ignore any call from an included servlet
+
+ synchronized (headers) {
+ArrayList values = (ArrayList) headers.get(name);
+if ((values != null) (!values.isEmpty())) {
+values.remove(value);
+if (values.isEmpty())
+headers.remove(name);
+}
+ }
+
+
Re: Tomcat JNDI
No problemo. The GPL issue is being resolved (=we're switching license). That's great ! There is a lot of code that should be reused/shared, and it's really bad when the license prevents that. additional permissions, like changing the class path, and also ACL doesn't implement the "Sealed" and other security attributes. That means code that assumes ACL is present may not run in all configurations. Ah, I see. Well, I don't rely on the ACL. I rely only on *a* CL being set as context classloader/app, that's all. I don't which one it is. :-) Basically I just keep a hashtable with the CL as key and the namespace as value. Simple and works. Ah, that's cool. I thought you were using ACL methods. Nice solution. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test hardware != User hardware =applicability problems?
criteria on a limited set of requests. So, one more time: What workload is Tomcat expected to run, and what will TC thruput and response be running that workload on a particular architecture? Or, since TC is free, this is up to the user to simply try it and see? I don't think you can ( or should ) predict what the user will run, but how much will tomcat add. It is important to know that at x req/s tomcat is adding y ms for each request, z ms for an internal dispatch, etc. ( of course, on average ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible bug in tomcat wrt setting cookies?
Yes, this is a real bug in 3.2b6 (and probably earlier). I checked in a patch for it earlier this week, which will be included in b7 and the eventual release. What caused the problem was kind of interesting -- the session stuff was abstracted out into a RequestInterceptor, which would add the session cookie if necessary. The error case showed up when the first flush of the buffer occurred in the included servlet/page, rather than the outer page before the include. The session interceptor would be fired, and it would try to add the cookie ... but included servlets/pages are (correctly) forbidden from trying to add cookies or headers, so it never really got added. The current workaround is to force a response.flushBuffer() before processing the include. However, this is related to some other RequestDispatcher issues (such as the fact that RD did not use to propogate exceptions to the caller, in violation of the spec). Larry just checked in some changes -- it's my turn to put eyeballs to them. Anyone else who wants to help is urged to check out the "tomcat_32" branch from CVS and help us get this right. Craig kenneth topp wrote: I apologize, this is with tomcat 3.2b4 and 3.2b6 Thanks, On Wed, 8 Nov 2000, kenneth topp wrote: I think this is a bug: A servlet includes a .jsp (via include() not forward() ) The servlet always creates a session. the session cookie never get's set, because the SessionInterceptor doesn't have the Response that was given the sessionId... or something. Does this sound right? If I addCookie in the servlet, it will get sent when the user goes through an include. TIA, Kenneth Topp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
umm...it does. i use it. -Ys- My understanding is it DOES work for app contexts mapped to a URL like "/myapp" but it does NOT work for the root context. "/" Many of us have webapps that mount to the root context. I spent WAY to much time figuring this out, I'd love to be proven wrong. But the mailing list supports what I'm saying if you search for "load balancing" -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
On Thu, 9 Nov 2000, Nick Bauman wrote: How? As far as I can tell it's broken in TC 3.1 / mod_jserv. Can you describe your configuration? SNIP "as advertised" in a web server farm with a rotator box like BigIP. Right now the Session API in tomcat 3.1 /does not work/ across multiple instances of tomcat in a server farm. umm...it does. i use it. -Ys- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems __ 4 x /- 3 x -/-- tomcat JVMs Net---Load Balancer apache \-per apachewebserver. (piranha - redhat) \- web servers with mod_jservx 3 i also use : Net---Apache with mod_jserv 30 x tomcat jvms. -Ys- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat and WAP phones
Hi all,
While developing Tomcat based application for mobile phone, I have found
out that the lack of cookies support in WAP phones, will not let me run my
servlets on Tomcat load balance configuration.
In order to point Apache to two tomcats, I needed the apache to use the
jvmRoute section in the cookie to route the requests back to the original
Tomcat (using mod_jk).
Since the urls in the wml has written using the encodeurl function that
does not support adding the .jvmRoute to the url, the followed requests come
from the user without specifying the origin Tomcat (since there are no
cookies).
In order to fix that I have written RequestInterceptor to allow URL
session support to work with multiple Tomcat configuration.
To use that you must REPLACE the SessionInterceptor with the new
interceptor. Here is that part of server.xml:
!--
Commented
out by Shai Fultheim to enable url session interceptor.
RequestInterceptor
className=org.apache.tomcat.request.SessionInterceptor /
--
RequestInterceptor
className=org.apache.tomcat.session.URLSessionInterceptor
debug=1 /
The interceptor is part of
session package in order to use the (StandartSession.)encodeUrl.
The interceptor source file attached. Source Code below:
/*
*
*
* The
Apache Software License, Version 1.1
*
*
Copyright (c) 1999 The Apache Software Foundation. All rights
*
reserved.
*
* Redistribution
and use in source and binary forms, with or without
*
modification, are permitted provided that the following conditions
* are
met:
*
* 1.
Redistributions of source code must retain the above copyright
* notice, this list of
conditions and the following disclaimer.
*
* 2.
Redistributions in binary form must reproduce the above copyright
* notice, this list of
conditions and the following disclaimer in
* the documentation and/or
other materials provided with the
* distribution.
*
* 3.
The end-user documentation included with the redistribution, if
* any, must include the
following acknowlegement:
*
This product includes software developed by the
*
Apache Software Foundation (http://www.apache.org/).
* Alternately, this
acknowlegement may appear in the software itself,
* if and wherever such
third-party acknowlegements normally appear.
*
* 4.
The names The Jakarta Project, Tomcat, and Apache
Software
* Foundation must not
be used to endorse or promote products derived
* from this software without
prior written permission. For written
* permission, please contact
[EMAIL PROTECTED]
*
* 5.
Products derived from this software may not be called Apache
* nor may Apache appear
in their names without prior written
* permission of the Apache
Group.
*
* THIS
SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
*
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
*
DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR
* ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
*
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
*
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH
DAMAGE.
*
*
* This
software consists of voluntary contributions made by many
*
individuals on behalf of the Apache Software Foundation. For more
*
information on the Apache Software Foundation, please see
*
http://www.apache.org/.
*
*
[Additional notices, if required by prior licensing conditions]
*
*/
/*
* This
Interceptor written by Shai Fultheim, [EMAIL PROTECTED]
*
* Being
used to rewrite the sessionID to include JVM ID(jvmRoute).
* This
will allow (Response.)encodeUrl to work in multi tomcats
*
configuration.
*
* The
class is part of session package in order to use the
*
(StandartSession.)encodeUrl.
*
* All
changes to: Shai Fultheim, [EMAIL PROTECTED]
*/
package org.apache.tomcat.session;
import org.apache.tomcat.core.*;
public class URLSessionInterceptor extends BaseInterceptor
{
// Separates the session id from the jvm route
static final char SESSIONID_ROUTE_SEP = '.';
ContextManager cm;
int manager_note;
public URLSessionInterceptor() {
}
//
Called on init. Takes the context manager (used for logging) and
//
the standardManager address.
public void engineInit( ContextManager cm
) throws TomcatException {
this.cm
= cm;
//
set-up a per/container note for StandardManager
manager_note
= cm.getNoteId(ContextManager.CONTAINER_NOTE,
tomcat.standardManager);
if
( debug 0 )
Re: No revolution today
On Thu, 9 Nov 2000, Matthew Dornquast wrote: umm...it does. i use it. -Ys- My understanding is it DOES work for app contexts mapped to a URL like "/myapp" but it does NOT work for the root context. "/" Many of us have webapps that mount to the root context. I spent WAY to much time figuring this out, I'd love to be proven wrong. But the mailing list supports what I'm saying if you search for "load balancing" -Matthew yep. root context bug. reported loong ago. -Ys- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: No revolution today
Our site (http://www.spun.com) runs multiple Apache servers with load
balancers ("rotator box like BigIP") that distribute traffic over the Apache
servers. We have a farm of Tomcat servers. The session API's work for us.
The only problem is that Tomcat, as distributed, does not allow load
balancing persistence for the root context. We hacked a way around that
(search the archives if you're interested) - but it's an admitted kludge.
Joseph
-Original Message-
From: Nick Bauman [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 08, 2000 8:42 PM
To: [EMAIL PROTECTED]
Subject: Re: No revolution today
On Thu, 9 Nov 2000, Henri Gomez wrote:
It is important that tomcat3 has a design that allows support for
future
versions of the servlet API, but if tomcat developers don't want to see
it
happen - so be it. When Servlet2.3 will be final and in wide use, there
is
nothing that can stop someone from providing the module that supports it
(
not necesarily from apache site ).
Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for
at
least one or two years. Note that many importants sites still use Apache
JServ
(API 2.0) and GnuJSP.
I for one, would love to see the 3.x codebase's Session API actually work
"as advertised" in a web server farm with a rotator box like BigIP. Right
now the Session API in tomcat 3.1 /does not work/ across multiple
instances of tomcat in a server farm.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpConnector.java HttpProcessor.java HttpResponseImpl.java HttpResponseStream.java
remm00/11/09 12:15:50
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpConnector.java HttpProcessor.java
HttpResponseImpl.java HttpResponseStream.java
Log:
- Add a switch on the connector to be able to completely disable chunking,
if needed.
In the server.xml file,
Connector className="org.apache.catalina.connector.http.HttpConnector"
port="80" minProcessors="5" maxProcessors="75"
acceptCount="10" debug="0" allowChunking="false"/
will create an HTTP/1.1 connector which will never attempt to chunk. If
chunking is needed (content length is not specified), the connection will
be closed after processing the request.
Revision ChangesPath
1.4 +32 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java
Index: HttpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- HttpConnector.java2000/09/08 22:29:34 1.3
+++ HttpConnector.java2000/11/09 20:15:50 1.4
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
1.3 2000/09/08 22:29:34 craigmcc Exp $
- * $Revision: 1.3 $
- * $Date: 2000/09/08 22:29:34 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
1.4 2000/11/09 20:15:50 remm Exp $
+ * $Revision: 1.4 $
+ * $Date: 2000/11/09 20:15:50 $
*
*
*
@@ -94,7 +94,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.3 $ $Date: 2000/09/08 22:29:34 $
+ * @version $Revision: 1.4 $ $Date: 2000/11/09 20:15:50 $
*/
@@ -249,6 +249,12 @@
private String threadSync = "";
+/**
+ * Is chunking allowed ?
+ */
+private boolean allowChunking = true;
+
+
// - Properties
@@ -270,6 +276,28 @@
public void setAcceptCount(int count) {
this.acceptCount = count;
+
+}
+
+
+/**
+ * Get the allow chunking flag.
+ */
+public boolean isChunkingAllowed() {
+
+return (allowChunking);
+
+}
+
+
+/**
+ * Set the allow chunking flag.
+ *
+ * @param allowChunking Allow chunking flag
+ */
+public void setAllowChunking(boolean allowChunking) {
+
+this.allowChunking = allowChunking;
}
1.10 +7 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java
Index: HttpProcessor.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- HttpProcessor.java2000/10/10 17:09:24 1.9
+++ HttpProcessor.java2000/11/09 20:15:50 1.10
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
1.9 2000/10/10 17:09:24 remm Exp $
- * $Revision: 1.9 $
- * $Date: 2000/10/10 17:09:24 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
1.10 2000/11/09 20:15:50 remm Exp $
+ * $Revision: 1.10 $
+ * $Date: 2000/11/09 20:15:50 $
*
*
*
@@ -106,7 +106,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.9 $ $Date: 2000/10/10 17:09:24 $
+ * @version $Revision: 1.10 $ $Date: 2000/11/09 20:15:50 $
*/
final class HttpProcessor
@@ -760,7 +760,9 @@
// requested.
ackRequest(output);
// If the protocol is HTTP/1.1, chunking is allowed.
-((HttpResponseImpl) response).setAllowChunking(true);
+if (connector.isChunkingAllowed())
+((HttpResponseImpl) response)
+.setAllowChunking(true);
}
}
} catch (EOFException e) {
1.4 +4 -53
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseImpl.java
Index: HttpResponseImpl.java
Re: No revolution today
reOur site (http://www.spun.com) runs multiple Apache servers with load
balancers ("rotator box like BigIP") that distribute traffic over the Apache
servers. We have a farm of Tomcat servers. The session API's work for us.
The only problem is that Tomcat, as distributed, does not allow load
balancing persistence for the root context. We hacked a way around that
(search the archives if you're interested) - but it's an admitted kludge.
--
Yes, I did see that, and while i admired the hack, it wont work in our
situation. :)
I'd really like to see this very old bug fixed.
If for no other reason, it was stated it would work, and does not.
-Matthew
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible bug in tomcat wrt setting cookies?
Thanks for the information Craig, I just got a checkout of tomcat_32, so I will look at it. Kenneth On Thu, 9 Nov 2000, Craig R. McClanahan wrote: Yes, this is a real bug in 3.2b6 (and probably earlier). I checked in a patch for it earlier this week, which will be included in b7 and the eventual release. What caused the problem was kind of interesting -- the session stuff was abstracted out into a RequestInterceptor, which would add the session cookie if necessary. The error case showed up when the first flush of the buffer occurred in the included servlet/page, rather than the outer page before the include. The session interceptor would be fired, and it would try to add the cookie ... but included servlets/pages are (correctly) forbidden from trying to add cookies or headers, so it never really got added. The current workaround is to force a response.flushBuffer() before processing the include. However, this is related to some other RequestDispatcher issues (such as the fact that RD did not use to propogate exceptions to the caller, in violation of the spec). Larry just checked in some changes -- it's my turn to put eyeballs to them. Anyone else who wants to help is urged to check out the "tomcat_32" branch from CVS and help us get this right. Craig kenneth topp wrote: I apologize, this is with tomcat 3.2b4 and 3.2b6 Thanks, On Wed, 8 Nov 2000, kenneth topp wrote: I think this is a bug: A servlet includes a .jsp (via include() not forward() ) The servlet always creates a session. the session cookie never get's set, because the SessionInterceptor doesn't have the Response that was given the sessionId... or something. Does this sound right? If I addCookie in the servlet, it will get sent when the user goes through an include. TIA, Kenneth Topp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/resources LocalStrings.properties
craigmcc00/11/09 13:18:10
Modified:src/share/org/apache/tomcat/facade Tag: tomcat_32
RequestDispatcherImpl.java
src/share/org/apache/tomcat/resources Tag: tomcat_32
LocalStrings.properties
Log:
Previous changes implemented "exception rethrowing" in the case of a path
based include(). This patch adds the following enhancements:
- If an included servlet throws an exception other than IOException or
ServletException, wrap it in a new ServletException (as the root cause)
and throw that instead.
- Add exception throwing support in the following additional cases:
* Path based forward() - getServletContext().getRequestDispatcher()
* Name based include() - getServletContext().getNamedDispatcher()
* Name based forward() - getServletContext().getNamedDispatcher()
- When processing a named based include, set the "included" flag on the
response so that attempts to modify headers and cookies in the included
servlet are (correctly) ignored.
Currently passes all the Watchdog servlet tests, and all the Watchdog JSP
tests except for some taglib-related ones that are unrelated to this
particular issue.
Revision ChangesPath
No revision
No revision
1.8.2.5 +97 -8
jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/RequestDispatcherImpl.java
Index: RequestDispatcherImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/RequestDispatcherImpl.java,v
retrieving revision 1.8.2.4
retrieving revision 1.8.2.5
diff -u -r1.8.2.4 -r1.8.2.5
--- RequestDispatcherImpl.java2000/11/09 13:27:36 1.8.2.4
+++ RequestDispatcherImpl.java2000/11/09 21:18:09 1.8.2.5
@@ -188,7 +188,28 @@
// CM should have set the wrapper - call it
ServletWrapper wr=realRequest.getWrapper();
- if( wr!=null ) wr.service(realRequest, realResponse);
+Throwable t = null;
+if( wr != null ) {
+try {
+wr.service(realRequest, realResponse);
+} catch (Throwable t1) {
+t = t1;
+}
+}
+
+// Clean up the request and response as needed
+; // No action required
+
+// Rethrow any exception thrown by the forwarded-to servlet
+if (t != null) {
+if (t instanceof IOException)
+throw (IOException) t;
+else if (t instanceof ServletException)
+throw (ServletException) t;
+else
+throw new ServletException
+(sm.getString("dispatcher.forwardException", t));
+}
// close the response - output after this point will be discarded.
realResponse.finish();
@@ -348,12 +369,17 @@
realResponse.setIncluded( false );
}
+// Rethrow any exception thrown by the included servlet
if (t != null) {
if (t instanceof IOException)
throw (IOException) t;
else if (t instanceof ServletException)
throw (ServletException) t;
+else
+throw new ServletException
+(sm.getString("dispatcher.includeException", t));
}
+
}
@@ -364,13 +390,48 @@
public void includeNamed(ServletRequest request, ServletResponse response)
throws ServletException, IOException
{
- // Use the original request - as in specification !
// We got here if name!=null, so assert it
ServletWrapper wrapper = context.getServletByName( name );
- Request realR=((HttpServletRequestFacade)request).getRealRequest();
- if( wrapper!=null)
- wrapper.service( realR, realR.getResponse());
+
+ // Use the original request - as in specification !
+Request realRequest = ((HttpServletRequestFacade)request).
+ getRealRequest();
+ Response realResponse = realRequest.getResponse();
+
+// Set the "included" flag so that things like header setting in the
+// included servlet will be correctly ignored
+ boolean old_included=realResponse.isIncluded();
+ if( ! old_included ) {
+ realResponse.setIncluded( true );
+ }
+
+// Call the included servlet
+Throwable t = null;
+ if( wrapper!=null) {
+try {
+wrapper.service( realRequest, realRequest.getResponse());
+} catch (Throwable t1) {
+t = t1;
+}
+}
+
+// Clean up the request and response as needed
+ if( ! old_included ) {
+ realResponse.setIncluded( false );
+ }
+
+//
Tomcat classloader is not working correctly
I am experiencing wide application problems with how the classloader works in Tomcat. Using Tomcat v3.0.1 (something like that) JDK v1.2.2 Sun OS Please respond back to my JPMorgan account. Here is some history. I built several servlet based applications on the Java WebServer - but management asked me to move them into one architecture and choose Tomcat. So I began to move them, however they wanted one server, to use on process - with all my applications under one house ... We began by implementing a CVS repository and I used Ant to make by builds. But when I began to install the applications the server got crazy. So what happened? The classloader seems to be getting things wrong. First the Lotus XSL implementation from IBM does not work right with Jakata. The Sax classes in Jakata seem to not be correct with lotusxsl v1.0.1 - I tried the previous v0.2.0 - but that failed too. I have custom XSLT applications which are server side and parse XML using XSLT, and the XSL has custom Name Space programs in the XSL - which help in parsing. When I run them they fail. If I load the classes in front of the main libraries that Jakata uses - it works. Can someone please address this issue. See in the Java WebServer - it has no notion of Sax (it was before Sax - atleast the one I am using is) - so it works fine. But Jakata chokes. The next problem is how the classloader works when having my API run in the global lib, and having it try to access properties in my application level class path. I use WebMacro to build my servlets. When I load the WebMacro libraries in the global lib (via mod'ing the start script 'tomcat.sh') it fails. The problem is WebMacro is looking from its properties in the global classpath and not in the application classpath. This is a serious error in the server itself. It should look in its local path first, then to global. In this case it looks in global since the API is in global, and never even looks in application level classpath. Here is another problem with the classloader. If I have TopLink API in the global lib, and it tries to map the SQL rows to the objects which are in my application lib classpath, it chokes. TopLink can not access the classes in the application level classpath. This is a serious error. I am trying to build large scale applications in Jakata - but the way it works prevents this. I believe that you must be using the security mechanism in the Java VM which is preventing the global API to access the application level API (in the case of TopLink) above. Here is the TopLink output. I have confirmed that TopLink is connecting to the database (in my case IBM UDB v7.1) and is calling the SQL fine. EXCEPTION [TOPLINK-1011] (v2.5.1 GA May 11 2000): TOPLink.Tools.BuilderReader.BuilderException EXCEPTION DESCRIPTION: Could not convert: com.jpmorgan.ams.jxmlive.model.MessageAuditHolder into an accessible Java class. INTERNAL EXCEPTION: EXCEPTION [TOPLINK-3001] (v2.5.1 GA May 11 2000): TOPLink.Public.Exceptions.ConversionException EXCEPTION DESCRIPTION: The object, 'com.jpmorgan.ams.jxmlive.model.MessageAuditHolder' of class, 'class java.lang.String' could not be converted to 'class java.lang.Class', INTERNAL EXCEPTION: java.lang.ClassNotFoundException: com.jpmorgan.ams.jxmlive.model.MessageAuditHolder Later this weekend I am going to run the application in JProbe to profile the application and try to trace it. Can someone give me a clue on how to get around these problems? Is there some security properties that I can set to allow global API to make calls into application level classes? What am I doing wrong? Thanks Sean Bowes This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF web.xml
craigmcc00/11/09 13:21:35 Modified:src/tests/webpages/WEB-INF Tag: tomcat_32 web.xml Log: Do not attempt to load the "PermanentlyAvailable2" servlet at startup time. Because the test application is part of the default build, this will lead to tons of user questions about "Why do I get this error message at startup time" even though the error message is correct. Revision ChangesPath No revision No revision 1.6.4.3 +2 -0 jakarta-tomcat/src/tests/webpages/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/web.xml,v retrieving revision 1.6.4.2 retrieving revision 1.6.4.3 diff -u -r1.6.4.2 -r1.6.4.3 --- web.xml 2000/08/28 03:29:32 1.6.4.2 +++ web.xml 2000/11/09 21:21:35 1.6.4.3 @@ -79,7 +79,9 @@ servlet-class PermanentlyUnavailable /servlet-class +!-- load-on-startup/load-on-startup +-- /servlet servlet-mapping - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/resources LocalStrings.properties
larryi 00/11/09 13:42:55
Modified:src/share/org/apache/tomcat/context Tag: tomcat_32
DefaultCMSetter.java
src/share/org/apache/tomcat/core Tag: tomcat_32
ContextManager.java
src/share/org/apache/tomcat/resources Tag: tomcat_32
LocalStrings.properties
Log:
Add some indication of the unavailable time to the default response for
UnavailableExceptions. Needed to see if recent changes to Exception
handling are actually working.
Revision ChangesPath
No revision
No revision
1.45.2.7 +17 -0
jakarta-tomcat/src/share/org/apache/tomcat/context/DefaultCMSetter.java
Index: DefaultCMSetter.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/context/DefaultCMSetter.java,v
retrieving revision 1.45.2.6
retrieving revision 1.45.2.7
diff -u -r1.45.2.6 -r1.45.2.7
--- DefaultCMSetter.java 2000/09/28 02:07:03 1.45.2.6
+++ DefaultCMSetter.java 2000/11/09 21:42:46 1.45.2.7
@@ -379,6 +379,23 @@
.append(msg)
.append("/bbr");
+ // add unavailable time if present
+ if ( sc == 503) {
+Integer ut =
(Integer)req.getAttribute("tomcat.servlet.error.unavailableTime");
+if ( ut != null) {
+// if permanent
+if (ut.intValue() 0) {
+ buf.append("br")
+
.append(sm.getString("defaulterrorpage.service.permanently.unavailable"))
+ .append("br");
+} else {
+ buf.append("br")
+
.append(sm.getString("defaulterrorpage.service.unavailable",ut))
+ .append("br");
+}
+ }
+ }
+
buf.append("/body\r\n");
if( res.isUsingStream() ) {
No revision
No revision
1.100.2.16 +1 -0
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.100.2.15
retrieving revision 1.100.2.16
diff -u -r1.100.2.15 -r1.100.2.16
--- ContextManager.java 2000/11/09 13:40:48 1.100.2.15
+++ ContextManager.java 2000/11/09 21:42:54 1.100.2.16
@@ -1081,6 +1081,7 @@
ctx.log( "UnavailableException in: " + req +
", time remaining " + unavailableTime + " seconds : " + msg,
t);
req.setAttribute("javax.servlet.error.message", msg );
+req.setAttribute("tomcat.servlet.error.unavailableTime", new
Integer(unavailableTime));
res.setStatus(HttpServletResponse.SC_SERVICE_UNAVAILABLE); // 503
handleStatus( req, res, HttpServletResponse.SC_SERVICE_UNAVAILABLE );
// indicate error handling has been called
No revision
No revision
1.4.2.4 +3 -1
jakarta-tomcat/src/share/org/apache/tomcat/resources/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/resources/LocalStrings.properties,v
retrieving revision 1.4.2.3
retrieving revision 1.4.2.4
diff -u -r1.4.2.3 -r1.4.2.4
--- LocalStrings.properties 2000/11/09 21:18:09 1.4.2.3
+++ LocalStrings.properties 2000/11/09 21:42:55 1.4.2.4
@@ -1,4 +1,4 @@
-# $Id: LocalStrings.properties,v 1.4.2.3 2000/11/09 21:18:09 craigmcc Exp $
+# $Id: LocalStrings.properties,v 1.4.2.4 2000/11/09 21:42:55 larryi Exp $
#
# Localized strings for package org.apache.tomcat.core
@@ -21,6 +21,8 @@
defaulterrorpage.thisdocumenthasmoved=This document has moved
defaulterrorpage.internalservleterror=Internal Servlet Error:
defaulterrorpage.notfoundrequest=Not found request:
+defaulterrorpage.service.unavailable=Service is unavailable, try again in {0}
seconds
+defaulterrorpage.service.permanently.unavailable=Service is permanently unavailable
#RequestDispatcherImpl.java
dispatcher.forwardException=Forwarded servlet threw exception
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/resources LocalStrings_en.properties
nacho 00/11/09 14:50:50 Removed: src/share/org/apache/tomcat/resources Tag: tomcat_32 LocalStrings_en.properties Log: * Removing was added as binary to CVS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
Well, but if you don't need the root-context, then the load balancing *should* work with other contexts. You are using mod_jserv with APJ Balancesets, right? Right Jospeh! So how important is it to support load balancing of root contexts? How many users use the root context? From where I sit, it's a requirement, I have no other option. I don't want to go into the reasons as to why this is, (Unless there is a great deal of interest) but I do wonder how many others are doing it like I am? its a big change. fix for 3.3 ? This would seriously nuke loadbalancing for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable out after so many months (years?). I wish I knew if it was a big change or not. When I was trying to do it, it felt like it was more of a mod_jserv issue and had little/nothing to do with tomcat. It seemed like mod_serv config parser just couldn't grok what I was telling it. (Kudos to the designer(s) of the API for mod_jserv, I thought it well thought out and easy to config given the amount of power/flexibility they were giving me.) 3.2 Stable is very important, at a minimum however, documentation should be updated to state it's not supported in 3.2 root context. -matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: No revolution today
Matthew, In my environment, I wanted to force all contexts to be in the root context. So, my point is -- if you only need the root context (one context only!), my kludge works. If you want root context and non-root contexts to both coexist, then you'll need to modify my kludge to NOT force the context to the root context. You'll have to test it to see if it works for you (because I haven't). I think Andrew Cowie did the latter (not force the contexts to the root context), but I don't want to speak for him. If you need multiple contexts without the root context, then the existing Tomcat should be perfectly fine. Joseph -Original Message- From: Matthew Dornquast [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 09, 2000 2:28 PM To: [EMAIL PROTECTED] Subject: Re: No revolution today Well, but if you don't need the root-context, then the load balancing *should* work with other contexts. You are using mod_jserv with APJ Balancesets, right? Right Jospeh! So how important is it to support load balancing of root contexts? How many users use the root context? From where I sit, it's a requirement, I have no other option. I don't want to go into the reasons as to why this is, (Unless there is a great deal of interest) but I do wonder how many others are doing it like I am? its a big change. fix for 3.3 ? This would seriously nuke loadbalancing for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable out after so many months (years?). I wish I knew if it was a big change or not. When I was trying to do it, it felt like it was more of a mod_jserv issue and had little/nothing to do with tomcat. It seemed like mod_serv config parser just couldn't grok what I was telling it. (Kudos to the designer(s) of the API for mod_jserv, I thought it well thought out and easy to config given the amount of power/flexibility they were giving me.) 3.2 Stable is very important, at a minimum however, documentation should be updated to state it's not supported in 3.2 root context. -matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
In our situation, we plan to use multiple virtual hosts, each with its own root context. That makes the URLs shorter and easier for people to work with. It also lets you more easily move/copy one context to another without having to fix all the links. I've posted patches that make this work for us in the past, along with several other patches for cookie behavior. We're not running this in production yet, but I've had load balancing working as expected (as far as I can tell) with mod_jk and tomcat_32. I don't have the load balancing hardware available for testing, but I've set up DNS round robin, as well as things like killing apache on one host to force it to the other and the sessions being routed properly. If anybody is interested in the patches, let me know and I'll post them to the list again. One fixed root context load balancing (at least for us), cookie deletion, session cookie selection, and one that prevents session cookies other than the valid one from being leaked into a webapp. I'd also like to cast my vote for a production quality release and continued development of tomcat 3.x for production use. Tomcat 4.0 may be elegant, but what I need right now is robust and fast Servlet 2.2/JSP 1.1. Paul Frieden Joseph Chiu wrote: Matthew, In my environment, I wanted to force all contexts to be in the root context. So, my point is -- if you only need the root context (one context only!), my kludge works. If you want root context and non-root contexts to both coexist, then you'll need to modify my kludge to NOT force the context to the root context. You'll have to test it to see if it works for you (because I haven't). I think Andrew Cowie did the latter (not force the contexts to the root context), but I don't want to speak for him. If you need multiple contexts without the root context, then the existing Tomcat should be perfectly fine. Joseph -Original Message- From: Matthew Dornquast [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 09, 2000 2:28 PM To: [EMAIL PROTECTED] Subject: Re: No revolution today Well, but if you don't need the root-context, then the load balancing *should* work with other contexts. You are using mod_jserv with APJ Balancesets, right? Right Jospeh! So how important is it to support load balancing of root contexts? How many users use the root context? From where I sit, it's a requirement, I have no other option. I don't want to go into the reasons as to why this is, (Unless there is a great deal of interest) but I do wonder how many others are doing it like I am? its a big change. fix for 3.3 ? This would seriously nuke loadbalancing for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable out after so many months (years?). I wish I knew if it was a big change or not. When I was trying to do it, it felt like it was more of a mod_jserv issue and had little/nothing to do with tomcat. It seemed like mod_serv config parser just couldn't grok what I was telling it. (Kudos to the designer(s) of the API for mod_jserv, I thought it well thought out and easy to config given the amount of power/flexibility they were giving me.) 3.2 Stable is very important, at a minimum however, documentation should be updated to state it's not supported in 3.2 root context. -matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
I'm interested in these patches. Also, I'm interested in the issues with the issues with root contexts (the thread name on tomcat-dev or .java file) Thanks, Kenneth Topp On Thu, 9 Nov 2000, Paul Frieden wrote: In our situation, we plan to use multiple virtual hosts, each with its own root context. That makes the URLs shorter and easier for people to work with. It also lets you more easily move/copy one context to another without having to fix all the links. I've posted patches that make this work for us in the past, along with several other patches for cookie behavior. We're not running this in production yet, but I've had load balancing working as expected (as far as I can tell) with mod_jk and tomcat_32. I don't have the load balancing hardware available for testing, but I've set up DNS round robin, as well as things like killing apache on one host to force it to the other and the sessions being routed properly. If anybody is interested in the patches, let me know and I'll post them to the list again. One fixed root context load balancing (at least for us), cookie deletion, session cookie selection, and one that prevents session cookies other than the valid one from being leaked into a webapp. I'd also like to cast my vote for a production quality release and continued development of tomcat 3.x for production use. Tomcat 4.0 may be elegant, but what I need right now is robust and fast Servlet 2.2/JSP 1.1. Paul Frieden Joseph Chiu wrote: Matthew, In my environment, I wanted to force all contexts to be in the root context. So, my point is -- if you only need the root context (one context only!), my kludge works. If you want root context and non-root contexts to both coexist, then you'll need to modify my kludge to NOT force the context to the root context. You'll have to test it to see if it works for you (because I haven't). I think Andrew Cowie did the latter (not force the contexts to the root context), but I don't want to speak for him. If you need multiple contexts without the root context, then the existing Tomcat should be perfectly fine. Joseph -Original Message- From: Matthew Dornquast [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 09, 2000 2:28 PM To: [EMAIL PROTECTED] Subject: Re: No revolution today Well, but if you don't need the root-context, then the load balancing *should* work with other contexts. You are using mod_jserv with APJ Balancesets, right? Right Jospeh! So how important is it to support load balancing of root contexts? How many users use the root context? From where I sit, it's a requirement, I have no other option. I don't want to go into the reasons as to why this is, (Unless there is a great deal of interest) but I do wonder how many others are doing it like I am? its a big change. fix for 3.3 ? This would seriously nuke loadbalancing for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable out after so many months (years?). I wish I knew if it was a big change or not. When I was trying to do it, it felt like it was more of a mod_jserv issue and had little/nothing to do with tomcat. It seemed like mod_serv config parser just couldn't grok what I was telling it. (Kudos to the designer(s) of the API for mod_jserv, I thought it well thought out and easy to config given the amount of power/flexibility they were giving me.) 3.2 Stable is very important, at a minimum however, documentation should be updated to state it's not supported in 3.2 root context. -matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets InvokerServlet.java LocalStrings.properties
craigmcc00/11/09 17:19:18
Modified:catalina/src/share/org/apache/catalina/servlets
InvokerServlet.java LocalStrings.properties
Log:
Make the invoker servlet work when called underneath a request dispatcher
path-based include.
Revision ChangesPath
1.3 +102 -33
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java
Index: InvokerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- InvokerServlet.java 2000/09/28 19:00:26 1.2
+++ InvokerServlet.java 2000/11/10 01:19:17 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
1.2 2000/09/28 19:00:26 craigmcc Exp $
- * $Revision: 1.2 $
- * $Date: 2000/09/28 19:00:26 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
1.3 2000/11/10 01:19:17 craigmcc Exp $
+ * $Revision: 1.3 $
+ * $Date: 2000/11/10 01:19:17 $
*
*
*
@@ -73,9 +73,11 @@
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.catalina.Context;
+import org.apache.catalina.Globals;
import org.apache.catalina.HttpRequest;
import org.apache.catalina.HttpResponse;
import org.apache.catalina.Wrapper;
+import org.apache.catalina.util.StringManager;
/**
@@ -84,7 +86,7 @@
* in the web application deployment descriptor.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.2 $ $Date: 2000/09/28 19:00:26 $
+ * @version $Revision: 1.3 $ $Date: 2000/11/10 01:19:17 $
*/
public final class InvokerServlet
@@ -106,6 +108,13 @@
private int debug = 0;
+/**
+ * The string manager for this package.
+ */
+private static StringManager sm =
+StringManager.getManager(Constants.Package);
+
+
// - Public Methods
@@ -217,21 +226,61 @@
HttpServletResponse response)
throws IOException, ServletException {
- // Identify the class name of the servlet we want
- if (debug = 1)
- log("serveRequest: Serving request " + request.getMethod() +
- " " + request.getRequestURI());
- String pathInfo = request.getPathInfo();
- if (pathInfo == null) {
+// Disallow calling this servlet via a named dispatcher
+if (request.getAttribute(Globals.NAMED_DISPATCHER_ATTR) != null)
+throw new ServletException
+(sm.getString("invokerServlet.notNamed"));
+
+// Identify the input parameters and our "included" state
+String inRequestURI = null;
+String inContextPath = null;
+String inServletPath = null;
+String inPathInfo = null;
+String inQueryString = null;
+boolean included =
+(request.getAttribute(Globals.REQUEST_URI_ATTR) != null);
+if (included) {
+inRequestURI =
+(String) request.getAttribute(Globals.REQUEST_URI_ATTR);
+inContextPath =
+(String) request.getAttribute(Globals.CONTEXT_PATH_ATTR);
+inServletPath =
+(String) request.getAttribute(Globals.SERVLET_PATH_ATTR);
+inPathInfo =
+(String) request.getAttribute(Globals.PATH_INFO_ATTR);
+inQueryString =
+(String) request.getAttribute(Globals.QUERY_STRING_ATTR);
+} else {
+inRequestURI = request.getRequestURI();
+inContextPath = request.getContextPath();
+inServletPath = request.getServletPath();
+inPathInfo = request.getPathInfo();
+inQueryString = request.getQueryString();
+}
+if (debug = 1) {
+log("serveRequest: included='" + included + "', requestURI='" +
+inRequestURI + "', contextPath='" + inContextPath + "'");
+log(" servletPath='" + inServletPath + "', pathInfo='" +
+inPathInfo + "', queryString='" + inQueryString + "'");
+}
+
+// Make sure a servlet name or class name was specified
+ if (inPathInfo == null) {
if (debug = 1)
- log("serveRequest: Invalid pathInfo '" + pathInfo + "'");
- response.sendError(HttpServletResponse.SC_NOT_FOUND,
-request.getRequestURI());
- return;
+ log("serveRequest: Invalid
More on redirection problems
Hola a todos: After some more research in the issues related to NATs and tomcat standalone, and more reading, i think i have found a real and common problem in tomcat 3.X, that it's not present in Tomcat 4.0 ( this is from a brief reading of the code ). The problem, i think i'd found, is that when tomcat does a redirection do not use the "host" header received, he tries to recontruct host+port info based on his own port and the name (or ip ) found in the Host header of the request, that IMHO is bad because the real uri (host+port) is dictated by the Host header.. But in addition i'd found that the relevant RFC for tomcat3 ( that is a HTTP 1.0 server AFAIK ) dont say anything about Host headers or something similar at all. I have prepared a simple patch for tomcat 3.2 and 3.x about this. Any comments? Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More on redirection problems
Nacho wrote: Hola a todos: After some more research in the issues related to NATs and tomcat standalone, and more reading, i think i have found a real and common problem in tomcat 3.X, that it's not present in Tomcat 4.0 ( this is from a brief reading of the code ). The problem, i think i'd found, is that when tomcat does a redirection do not use the "host" header received, he tries to recontruct host+port info based on his own port and the name (or ip ) found in the Host header of the request, that IMHO is bad because the real uri (host+port) is dictated by the Host header.. But in addition i'd found that the relevant RFC for tomcat3 ( that is a HTTP 1.0 server AFAIK ) dont say anything about Host headers or something similar at all. I have prepared a simple patch for tomcat 3.2 and 3.x about this. What Tomcat 4.0 does is sets the value that is returned by request.getServerName() -- and this is the value used to construct absolute URLs on a redirect -- from the value of the "Host" header. If your patch does this to Tomcat 3.2, I'm +1 for it. Any comments? Saludos , Ignacio J. Ortega Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Handler.java
craigmcc00/11/09 18:06:32
Modified:src/share/org/apache/tomcat/core Tag: tomcat_32 Handler.java
Log:
Restore the previous exception propogation model so that exceptions are
propogated only from included servlets. This undoes part of a change
Larry committed earlier -- after further discussion with him, we've agreed
that this is the correct behavior so that servlets can trap exceptions
thrown by included servlets without corrupting the content of the
response.
NOTE: If you include a JSP page that declares an error page, and your JSP
page throws an exception, the transfer to the error page will still happen
as expected even in an included page. This is handled completely within
the JSP environment, and did not rely on the error propogation mechanism
for servlet exceptions -- which was Larry's primary concern.
As a result of this change, Tomcat 3.2 will trigger the error-page
handling only if the top-level servlet throws an exception. This is also
consistent with the behavior of Tomcat 4.0 in this respect.
Revision ChangesPath
No revision
No revision
1.7.2.6 +27 -21jakarta-tomcat/src/share/org/apache/tomcat/core/Handler.java
Index: Handler.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Handler.java,v
retrieving revision 1.7.2.5
retrieving revision 1.7.2.6
diff -u -r1.7.2.5 -r1.7.2.6
--- Handler.java 2000/11/09 14:11:27 1.7.2.5
+++ Handler.java 2000/11/10 02:06:32 1.7.2.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Handler.java,v 1.7.2.5
2000/11/09 14:11:27 larryi Exp $
- * $Revision: 1.7.2.5 $
- * $Date: 2000/11/09 14:11:27 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Handler.java,v 1.7.2.6
2000/11/10 02:06:32 craigmcc Exp $
+ * $Revision: 1.7.2.6 $
+ * $Date: 2000/11/10 02:06:32 $
*
*
*
@@ -258,16 +258,19 @@
contextM.handleStatus( req, res, 404);
return;
}
- // handle error, does nothing if already handled
- contextM.handleError( req, res, ex);
- // rethrow the exception
context.log("Exception in init " + ex.getMessage(), ex );
- if (ex instanceof IOException)
- throw (IOException) ex;
- else if (ex instanceof ServletException)
- throw (ServletException) ex;
- else
- throw new ServletException("Servlet Init Exception", ex);
+if (res.isIncluded()) { // Only propogate on includes
+if (ex instanceof IOException)
+throw (IOException) ex;
+else if (ex instanceof ServletException)
+throw (ServletException) ex;
+else
+throw new ServletException
+("Servlet Init Exception", ex);
+} else {// Only handle on top level
+contextM.handleError( req, res, ex );
+return;
+}
}
}
}
@@ -289,17 +292,20 @@
if( t==null ) return;
- // handle error, does nothing if already handled
+// Rethrow the exception if we are inside an include
+if (res.isIncluded()) {
+//context.log("Rethrowing doService exception: " + t);
+if (t instanceof IOException)
+throw (IOException) t;
+else if (t instanceof ServletException)
+throw (ServletException) t;
+else
+throw new ServletException("Servlet Exception", t);
+}
+
+ // handle error, does nothing if already handled, at top level
contextM.handleError( req, res, t );
- // rethrow the exception
- context.log("Rethrowing doService exception: " + t);
- if (t instanceof IOException)
- throw (IOException) t;
- else if (t instanceof ServletException)
- throw (ServletException) t;
- else
- throw new ServletException("Servlet Exception", t);
}
// protected void handleError( Request req, Response res, Throwable t) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util MimeHeaderField.java
craigmcc00/11/09 18:59:39
Modified:src/share/org/apache/tomcat/util Tag: tomcat_32
MimeHeaderField.java
Log:
Correctly perform header name comparisons based on the data type of the
*name*, not the *value*. This bug caused duplicate headers in some cases,
even if the calling servlet called a method like response.setDateHeader()
with the same header name more than once (which should cause the previous
value to be replaced).
PR: BugRat Bug Report #185.
Revision ChangesPath
No revision
No revision
1.10.2.1 +4 -4
jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/MimeHeaderField.java
Index: MimeHeaderField.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/MimeHeaderField.java,v
retrieving revision 1.10
retrieving revision 1.10.2.1
diff -u -r1.10 -r1.10.2.1
--- MimeHeaderField.java 2000/06/23 02:16:29 1.10
+++ MimeHeaderField.java 2000/11/10 02:59:39 1.10.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/MimeHeaderField.java,v
1.10 2000/06/23 02:16:29 costin Exp $
- * $Revision: 1.10 $
- * $Date: 2000/06/23 02:16:29 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/MimeHeaderField.java,v
1.10.2.1 2000/11/10 02:59:39 craigmcc Exp $
+ * $Revision: 1.10.2.1 $
+ * $Date: 2000/11/10 02:59:39 $
*
*
*
@@ -364,7 +364,7 @@
* @param s the string to compare
*/
public boolean nameEquals(String s) {
- switch (type) {
+ switch (nameType) {
case T_STR:
return name.equalsIgnoreCase(s);
case T_CHARS:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
edit bug #13 by person #0 (logged in as: Nick Bauman)
Environment description modified: Description changed from: See Description To: Apparenlty, the Session API only works in a distributed environment when something other than the root context is used with mod_jserv Bug description modified: Description changed from: I have two servers with identical servlets on both doing load balancing (1 JVM per server). For this example consider A1 to be servlet A running on server 1 and so on, B2 to be servlet B on server 2 etc. code pre A1 - set cookie to (say) abc=20 B2 - reads from the cookie. gets abc=20. correct. C2 - deletes the cookie (setMaxAge to 0) C2 - sets a new cookie abc=30 C2 - reads from the cookie. gets abc=30. correct. B1 - reads from the cookie. gets abc=20 bug. B2 - reads form the cookie. gets abc=30. correct. /pre /code I'm using mod_jserv.so to do the load balancing. using netscape 4.73 to access the servlets and tomcat 3.2b2 with blackdown JDK 1.2.2FCS on redhat linux 6.2 kernel 2.2.16-3. I cant offer any insight into whats causing it...AFAIK this behaviour was not present in 3.1 and changing the JDK doesnt help. it only occurs with load balancing and not with the regular non load balanced operation. It doesnt affect me any more since i've worked around it and dont care either waybut it shouldnt really be present anyway. Any comments/insights ? To: I have two servers with identical servlets on both doing load balancing (1 JVM per server). For this example consider A1 to be servlet A running on server 1 and so on, B2 to be servlet B on server 2 etc. code pre A1 - set cookie to (say) abc=20 B2 - reads from the cookie. gets abc=20. correct. C2 - deletes the cookie (setMaxAge to 0) C2 - sets a new cookie abc=30 C2 - reads from the cookie. gets abc=30. correct. B1 - reads from the cookie. gets abc=20 bug. B2 - reads form the cookie. gets abc=30. correct. /pre /code p I'm using mod_jserv.so to do the load balancing. using netscape 4.73 to access the servlets and tomcat 3.2b2 with blackdown JDK 1.2.2FCS on redhat linux 6.2 kernel 2.2.16-3. p I cant offer any insight into whats causing it...AFAIK this behaviour was not present in 3.1 and changing the JDK doesnt help. it only occurs with load balancing and not with the regular non load balanced operation. It doesnt affect me any more since i've worked around it and dont care either waybut it shouldnt really be present anyway. Any comments/insights ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
edit bug #13 by person #0 (logged in as: Nick Bauman)
There were no modifications to the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
