Re: AJP Todo
On Sat, 1 Dec 2001, Remy Maucherat wrote: If you want to work on this, it would be great to make it a bit more independent of the container. Right now it is very tightly coupled, in order for it to work you need to start tomcat, it doesn't work very well with context reloads, etc. I'd leave it being tied to the container, and getting the lifecycle / container events. It's (at least it should be) a simple piece of code, and although most of the code could be static utility methods, I'd implement the wrapper as a listener, instead of a webapp. A trusted webapp can register listeners ( or should be able to ), it should be able to register connectors, etc. Long term we should be able to extract the information from web.xml without having to fully start tomcat ( and use it as a parser to extract the servlet mappings, etc ). Well, if you can also port the 'trusted app' - it would be really great. I said I would, but it will require adding a few method to the Context interface (so please, no screaming over API breakage ;-)). As long as you don't remove methods, I'm ok. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4966] - request.getParameter(String) SOMETIMES fail to parse the querystring
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4966. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4966 request.getParameter(String) SOMETIMES fail to parse the querystring --- Additional Comments From [EMAIL PROTECTED] 2001-12-02 05:42 --- I´ll create a testcase and run it on some more platforms, I´ll get back to you when I can get it to fail in predictable way. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Sat, 1 Dec 2001 [EMAIL PROTECTED] wrote: On the TODO list for AJP, there is: - Implementing jvmroute. I think I found a way to do it without accessing the Request. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java
remm01/12/02 09:38:18
Modified:catalina/src/share/org/apache/catalina/core Tag:
tomcat_40_branch StandardContext.java
Log:
- Port patch which makes the parent class loader of a privileged webapp be
the Catalina loader, which gives it full access to the Catalina internals.
Revision ChangesPath
No revision
No revision
1.78.2.8 +13 -7
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.78.2.7
retrieving revision 1.78.2.8
diff -u -r1.78.2.7 -r1.78.2.8
--- StandardContext.java 2001/11/17 08:42:54 1.78.2.7
+++ StandardContext.java 2001/12/02 17:38:17 1.78.2.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.78.2.7 2001/11/17 08:42:54 remm Exp $
- * $Revision: 1.78.2.7 $
- * $Date: 2001/11/17 08:42:54 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.78.2.8 2001/12/02 17:38:17 remm Exp $
+ * $Revision: 1.78.2.8 $
+ * $Date: 2001/12/02 17:38:17 $
*
*
*
@@ -142,7 +142,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.78.2.7 $ $Date: 2001/11/17 08:42:54 $
+ * @version $Revision: 1.78.2.8 $ $Date: 2001/12/02 17:38:17 $
*/
public class StandardContext
@@ -3307,9 +3307,15 @@
}
}
if (getLoader() == null) { // (2) Required by Manager
-if (debug = 1)
-log(Configuring default Loader);
-setLoader(new WebappLoader(getParentClassLoader()));
+if (getPrivileged()) {
+if (debug = 1)
+log(Configuring privileged default Loader);
+setLoader(new WebappLoader(this.getClass().getClassLoader()));
+} else {
+if (debug = 1)
+log(Configuring non-privileged default Loader);
+setLoader(new WebappLoader(getParentClassLoader()));
+}
}
if (getManager() == null) { // (3) After prerequisites
if (debug = 1)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java
patrickl01/12/02 11:22:23
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
Log:
Reversed previous revision and moved server.await() into the same try/catch block as
server.start(). This change, which forces Tomcat to immediately shutdown if an
exception is thrown by server.initialize() or server.start(), was recommended by Remy
Maucherat. Immediate shutdown of Tomcat is preferred because this behavior is
consistent no matter what types of Connectors are configured for Tomcat whereas, in
the previous revision, the behavior was dependent on the order of the Connectors
within server.xml.
Revision ChangesPath
1.41 +2 -13
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java
Index: Catalina.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- Catalina.java 2001/11/29 17:18:09 1.40
+++ Catalina.java 2001/12/02 19:22:23 1.41
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.40 2001/11/29 17:18:09 patrickl Exp $
- * $Revision: 1.40 $
- * $Date: 2001/11/29 17:18:09 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.41 2001/12/02 19:22:23 patrickl Exp $
+ * $Revision: 1.41 $
+ * $Date: 2001/12/02 19:22:23 $
*
*
*
@@ -97,7 +97,7 @@
* /u
*
* @author Craig R. McClanahan
- * @version $Revision: 1.40 $ $Date: 2001/11/29 17:18:09 $
+ * @version $Revision: 1.41 $ $Date: 2001/12/02 19:22:23 $
*/
public class Catalina {
@@ -494,16 +494,9 @@
if (server instanceof Lifecycle) {
try {
server.initialize();
-} catch (LifecycleException e) {
-System.out.println(Catalina.start: + e);
-e.printStackTrace(System.out);
-if (e.getThrowable() != null) {
-System.out.println(- Root Cause -);
-e.getThrowable().printStackTrace(System.out);
-}
-}
-try {
((Lifecycle) server).start();
+// Wait for the server to be told to shut down
+server.await();
} catch (LifecycleException e) {
System.out.println(Catalina.start: + e);
e.printStackTrace(System.out);
@@ -513,10 +506,6 @@
}
}
}
-
-
-// Wait for the server to be told to shut down
-server.await();
// Shut down the server
if (server instanceof Lifecycle) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5226] New: - Strange tomcat behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5226. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5226 Strange tomcat behavior Summary: Strange tomcat behavior Product: Tomcat 4 Version: 4.0 Beta 1 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I start tomcat everything is ok, however when I try to access the index.html page it refuses. The JVMs are not recycled on shutdown and the port being used is not released. Is there a way to get the debug information on startup so i can know what's going on? I get the following error when attempting to shutdown tomcat [elrond@rivendell tomcat]$ bin/shutdown.sh Guessing CATALINA_HOME from catalina.sh to bin/.. Setting CATALINA_HOME to bin/.. Using CLASSPATH: bin/../bin/bootstrap.jar:/usr/local/java/jdk13/lib/tools.jar Using CATALINA_BASE: bin/.. Using CATALINA_HOME: bin/.. Using JAVA_HOME: /usr/local/java/jdk13 Catalina.stop: java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:323) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:136) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:123) at java.net.Socket.init(Socket.java:273) at java.net.Socket.init(Socket.java:100) at org.apache.catalina.startup.Catalina.stop(Catalina.java:826) at org.apache.catalina.startup.Catalina.execute(Catalina.java:683) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5227] New: - Strange tomcat behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5227. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5227 Strange tomcat behavior Summary: Strange tomcat behavior Product: Tomcat 4 Version: 4.0 Beta 1 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I start tomcat everything is ok, however when I try to access the index.html page it refuses. The JVMs are not recycled on shutdown and the port being used is not released. Is there a way to get the debug information on startup so i can know what's going on? I get the following error when attempting to shutdown tomcat [elrond@rivendell tomcat]$ bin/shutdown.sh Guessing CATALINA_HOME from catalina.sh to bin/.. Setting CATALINA_HOME to bin/.. Using CLASSPATH: bin/../bin/bootstrap.jar:/usr/local/java/jdk13/lib/tools.jar Using CATALINA_BASE: bin/.. Using CATALINA_HOME: bin/.. Using JAVA_HOME: /usr/local/java/jdk13 Catalina.stop: java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:323) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:136) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:123) at java.net.Socket.init(Socket.java:273) at java.net.Socket.init(Socket.java:100) at org.apache.catalina.startup.Catalina.stop(Catalina.java:826) at org.apache.catalina.startup.Catalina.execute(Catalina.java:683) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5228] New: - Strange tomcat behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5228 Strange tomcat behavior Summary: Strange tomcat behavior Product: Tomcat 4 Version: 4.0 Beta 1 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I start tomcat everything is ok, however when I try to access the index.html page it refuses. The JVMs are not recycled on shutdown and the port being used is not released. Is there a way to get the debug information on startup so i can know what's going on? I get the following error when attempting to shutdown tomcat [elrond@rivendell tomcat]$ bin/shutdown.sh Guessing CATALINA_HOME from catalina.sh to bin/.. Setting CATALINA_HOME to bin/.. Using CLASSPATH: bin/../bin/bootstrap.jar:/usr/local/java/jdk13/lib/tools.jar Using CATALINA_BASE: bin/.. Using CATALINA_HOME: bin/.. Using JAVA_HOME: /usr/local/java/jdk13 Catalina.stop: java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:323) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:136) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:123) at java.net.Socket.init(Socket.java:273) at java.net.Socket.init(Socket.java:100) at org.apache.catalina.startup.Catalina.stop(Catalina.java:826) at org.apache.catalina.startup.Catalina.execute(Catalina.java:683) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5228] - Strange tomcat behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5228 Strange tomcat behavior [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2001-12-02 13:18 --- *** This bug has been marked as a duplicate of 5226 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5226] - Strange tomcat behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5226. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5226 Strange tomcat behavior --- Additional Comments From [EMAIL PROTECTED] 2001-12-02 13:18 --- *** Bug 5228 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5227] - Strange tomcat behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5227. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5227 Strange tomcat behavior [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2001-12-02 13:19 --- *** This bug has been marked as a duplicate of 5226 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5226] - Strange tomcat behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5226. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5226 Strange tomcat behavior --- Additional Comments From [EMAIL PROTECTED] 2001-12-02 13:19 --- *** Bug 5227 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK versions
[EMAIL PROTECTED] wrote: What I would like to do is make a branch for mod_jk 1.2, and eventually build a snapshot. If I'm getting this right, you are trying to preserve 1.2 for bug fixing a backward compatibility, while focusing on 2.0. Yes? If so, I'm [+1] for it as it seems very reasonable. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_logger_apache2.c
costin 01/12/02 14:09:54 Added: jk/native2/server/apache2 jk_logger_apache2.c Log: A logger implementation that send the logs to apache's error.log. Instead of tracking 2 log files and setting up mod_jk.log, we now use the native log format. This is not yet completed, but works. One big question is if we can pass the (...) params ( using va_list or some other tricks ) from one function to another. ( apache's log have no va_arg variant for the log function ) Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native2/server/apache2/jk_logger_apache2.c Index: jk_logger_apache2.c === /* = * * * * The Apache Software License, Version 1.1 * * * * Copyright (c) 1999-2001 The Apache Software Foundation. * * All rights reserved.* * * * = * * * * Redistribution and use in source and binary forms, with or without modi- * * fication, are permitted provided that the following conditions are met: * * * * 1. Redistributions of source code must retain the above copyright notice * *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, Jk, 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 Software Foundation.* * * * 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 indivi- * * duals on behalf of the Apache Software Foundation. For more
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorDispatcherValve.java
remm01/12/02 14:17:41
Modified:catalina/src/share/org/apache/catalina/valves Tag:
tomcat_40_branch ErrorDispatcherValve.java
Log:
- Fix a NPE which occured when handling the 500 that was returned when the host
mapper failed to map the request to a context. The status is still 500, but the
error report gives some info on the problem, and no exception is logged.
Revision ChangesPath
No revision
No revision
1.5.2.4 +9 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java
Index: ErrorDispatcherValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
retrieving revision 1.5.2.3
retrieving revision 1.5.2.4
diff -u -r1.5.2.3 -r1.5.2.4
--- ErrorDispatcherValve.java 2001/11/17 08:41:51 1.5.2.3
+++ ErrorDispatcherValve.java 2001/12/02 22:17:41 1.5.2.4
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
1.5.2.3 2001/11/17 08:41:51 remm Exp $
- * $Revision: 1.5.2.3 $
- * $Date: 2001/11/17 08:41:51 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
1.5.2.4 2001/12/02 22:17:41 remm Exp $
+ * $Revision: 1.5.2.4 $
+ * $Date: 2001/12/02 22:17:41 $
*
*
*
@@ -104,7 +104,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
- * @version $Revision: 1.5.2.3 $ $Date: 2001/11/17 08:41:51 $
+ * @version $Revision: 1.5.2.4 $ $Date: 2001/12/02 22:17:41 $
*/
public class ErrorDispatcherValve
@@ -214,6 +214,8 @@
Throwable throwable) {
Context context = request.getContext();
+if (context == null)
+return;
Throwable realError = throwable;
ErrorPage errorPage = findErrorPage(context, realError);
@@ -281,6 +283,9 @@
// Handle a custom error page for this status code
Context context = request.getContext();
+if (context == null)
+return;
+
ErrorPage errorPage = context.findErrorPage(statusCode);
if (errorPage != null) {
response.setAppCommitted(false);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorDispatcherValve.java
remm01/12/02 14:19:26
Modified:catalina/src/share/org/apache/catalina/valves
ErrorDispatcherValve.java
Log:
- Fix a NPE which occured when handling the 500 that was returned when the host
mapper failed to map the request to a context. The status is still 500, but the
error report gives some info on the problem, and no exception is logged.
Revision ChangesPath
1.8 +9 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java
Index: ErrorDispatcherValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ErrorDispatcherValve.java 2001/11/17 08:31:45 1.7
+++ ErrorDispatcherValve.java 2001/12/02 22:19:26 1.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
1.7 2001/11/17 08:31:45 remm Exp $
- * $Revision: 1.7 $
- * $Date: 2001/11/17 08:31:45 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
1.8 2001/12/02 22:19:26 remm Exp $
+ * $Revision: 1.8 $
+ * $Date: 2001/12/02 22:19:26 $
*
*
*
@@ -104,7 +104,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
- * @version $Revision: 1.7 $ $Date: 2001/11/17 08:31:45 $
+ * @version $Revision: 1.8 $ $Date: 2001/12/02 22:19:26 $
*/
public class ErrorDispatcherValve
@@ -214,6 +214,8 @@
Throwable throwable) {
Context context = request.getContext();
+if (context == null)
+return;
Throwable realError = throwable;
ErrorPage errorPage = findErrorPage(context, realError);
@@ -281,6 +283,9 @@
// Handle a custom error page for this status code
Context context = request.getContext();
+if (context == null)
+return;
+
ErrorPage errorPage = context.findErrorPage(statusCode);
if (errorPage != null) {
response.setAppCommitted(false);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java
remm01/12/02 14:24:49
Modified:catalina/src/share/org/apache/catalina/core Tag:
tomcat_40_branch StandardContext.java
Log:
- Revert this patch (sorry Costin):
- Port patch which makes the parent class loader of a privileged webapp be
the Catalina loader, which gives it full access to the Catalina internals.
- The problem is that Catalina wants to load-on-startup Jasper for all webapps,
and Jasper is not available in the Catalina CL.
Revision ChangesPath
No revision
No revision
1.78.2.9 +17 -11
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.78.2.8
retrieving revision 1.78.2.9
diff -u -r1.78.2.8 -r1.78.2.9
--- StandardContext.java 2001/12/02 17:38:17 1.78.2.8
+++ StandardContext.java 2001/12/02 22:24:49 1.78.2.9
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.78.2.8 2001/12/02 17:38:17 remm Exp $
- * $Revision: 1.78.2.8 $
- * $Date: 2001/12/02 17:38:17 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.78.2.9 2001/12/02 22:24:49 remm Exp $
+ * $Revision: 1.78.2.9 $
+ * $Date: 2001/12/02 22:24:49 $
*
*
*
@@ -142,7 +142,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.78.2.8 $ $Date: 2001/12/02 17:38:17 $
+ * @version $Revision: 1.78.2.9 $ $Date: 2001/12/02 22:24:49 $
*/
public class StandardContext
@@ -3307,15 +3307,21 @@
}
}
if (getLoader() == null) { // (2) Required by Manager
-if (getPrivileged()) {
-if (debug = 1)
-log(Configuring privileged default Loader);
-setLoader(new WebappLoader(this.getClass().getClassLoader()));
+// FIXME: All webapps require Jasper, but Jasper isn't available in
+// the Catalina CL.
+/*
+ if (getPrivileged()) {
+ if (debug = 1)
+ log(Configuring privileged default Loader);
+ setLoader(new WebappLoader(this.getClass().getClassLoader()));
} else {
-if (debug = 1)
-log(Configuring non-privileged default Loader);
-setLoader(new WebappLoader(getParentClassLoader()));
+*/
+if (debug = 1)
+log(Configuring non-privileged default Loader);
+setLoader(new WebappLoader(getParentClassLoader()));
+/*
}
+*/
}
if (getManager() == null) { // (3) After prerequisites
if (debug = 1)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5226] - Strange tomcat behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5226. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5226 Strange tomcat behavior --- Additional Comments From [EMAIL PROTECTED] 2001-12-02 14:54 --- What probably happens is that the VM dies on startup because of the well-known problems running the Sun JVM on Linux (workarounds with more details in the release notes). Please confim that is the cause of your problems. Also, please avoid filing the same bug multiple times. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] about kjc
On Sun, 2 Dec 2001 08:03, Jon Stevens wrote: on 12/1/01 10:08 AM, Remy Maucherat [EMAIL PROTECTED] wrote: Hi, tomcat users and developrs! /* I have post this patch twice. This is third time. */ Do you know kjc which is one of the completely opensource Java compiler? If not, you can see detail at http://www.dms.at/kopi. Accoding to Edouard G. Parmelan's report (http://rpmfind.net/tools/Kaffe/messages/1291.html), KJC HAVE BEATEN SUN'S JAVA COMPILER since version 1.5 about JLS compatibility. It was a grate news for Java open source community;) I and teik-san (san means Mr. in Japanese) wrote two kjc plugin for tomcat. One is for 3.3.x, and the other is for 4.0.x. If you take kjc plugin, it's good advertisement and help for kjc. Do you respect opensource? If so, could you take them? BTW, kjc is distributed under GPL. But you can take these patch in legal. Because you don't need to include kjc in tomcat. When you want to use kjc, only then you have to include it. In the fact, I wrote kjc plugin for Ant and it's really in it. So, you can also use kjc with Ant fine:) +1 for this patch as it is legal since it uses reflection. Remy I thought that using reflection to work with GPL code was still considered illegal by the FSF. Depends on exactly it is used from my understanding. If you use reflection but still directly integrate with the GPL work such that there is no chance that the GPL layer could be replaced with something else or your code can not run in GPL free mode then it is considered no different from directly linking against it. Note that if you use the main() interface that is considered okay last time I checked. However if you need to bind against the innards of the compiler then one option is to do the following. Create an interface layer and place it under a GPL compatible license (MIT, BSDL or whatever) and program against that interface. Then add some code to GPL work so that it implements interface. -- Cheers, Pete --- Murphy's law - Anything that can go wrong, will. (Actually, this is Finagle's law, which in itself shows that Finagle was right.) --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_webapp fails to build
Hi,
I'm not having much joy with building webapp-module-1.0.1-tc401 source on
Debian 2.2r4 i686.
1) The instructions for building it are incorrect, as they say if you
download a source distribution, all you have to do is:
./configure --with-apxs
... unfortunately, ./configure is not there until ./support/buildconf.sh
has been run.
2) After doing ./support/buildconf.sh ./configure --with-apxs make I
always get a failed compile:
{ APXS_LDFLAGS_SHLIB=`/usr/bin/apxs -q LDFLAGS_SHLIB` \
\
-lm -lcrypt -lnsl -ldl ; \
APXS_LDFLAGS_SHLIB=`/bin/echo ${APXS_LDFLAGS_SHLIB}` ; \
APXS_CFLAGS=`/usr/bin/apxs -q CFLAGS` \
-g -O2 \
-g -O2 \
\
-DLINUX=2 -D_REENTRANT \
-I/tmp/webapp-module-1.0.1-tc401/apr/include \
-I/tmp/webapp-module-1.0.1-tc401/include \
; \
APXS_CFLAGS=`/bin/echo ${APXS_CFLAGS}` ; \
/usr/bin/apxs \
-S CFLAGS=${APXS_CFLAGS} \
-S LDFLAGS_SHLIB=${APXS_LDFLAGS_SHLIB} \
-o mod_webapp.so \
-c mod_webapp.c \
/tmp/webapp-module-1.0.1-tc401/lib/libwebapp.a \
/tmp/webapp-module-1.0.1-tc401/lib/libapr.a ; \
} Bareword found where operator expected at (eval 6) line 1, near
-DLINUX=2 -DEAPI -DTARGET=apache
(Missing operator before apache?)
Bareword apache not allowed while strict subs in use at (eval 6) line
1.
String found where operator expected at (eval 6) line 1, near
apache -DUSE_HSREGEX -DUSE_EXPAT -I../lib/expat-lite -g -O2 -g -O2
-DLINUX=2 -D_REENTRANT -I/tmp/webapp-module-1.0.1-tc401/apr/include
-I/tmp/webapp-module-1.0.1-tc401/include
gcc -DLINUX=2 -DEAPI -DTARGET=apache -DUSE_HSREGEX -DUSE_EXPAT
-I../lib/expat-lite -fpic -DSHARED_MODULE -I/usr/include/apache-1.3 -c
mod_webapp.c
mod_webapp.c:70: wa.h: No such file or directory
apxs:Break: Command failed with rc=65536
make[2]: *** [mod_webapp.so] Error 1
make[2]: Leaving directory `/tmp/webapp-module-1.0.1-tc401/apache-1.3'
make[1]: Exiting directory apache-1.3
make[1]: *** [template] Error 2
make[1]: Leaving directory `/tmp/webapp-module-1.0.1-tc401'
make: *** [apache-1.3-build] Error 2
This happens with the latest CVS version too. Am I missing something
obvious? Help!
Andrew.
--
All views are my own who else would want them?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] about kjc
On Sun, 2 Dec 2001, Takashi Okamoto wrote: Date: Sun, 02 Dec 2001 09:19:37 +0900 From: Takashi Okamoto [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: [PATCH] about kjc Hi, Costin. At Sat, 1 Dec 2001 09:24:59 -0800 (PST), [EMAIL PROTECTED] wrote: +1 for the patch, but there's something that bothers me - we are starting to duplicate what's already present in ant. Next we'll have gcj support, etc. How difficult would it be to add an 'ant' compiler adapter, that will just use the ant javac task ? Of cource, using ant is better:) It's good idea. It seems not so difficult. You can use Javac or CompilerAdapterFactory (and Compiler Adapter) class for it. I looked at this option a little bit a while back, and have only one concern -- multiple threads trying to compile at the same time. Ant tasks generally assume that they don't need to worry about thread safety issues, so we need to review this code carefully. (Of course, this issue applies even more so to the new Javac entry point in 1.4 -- it writes error messages to System.out). And also use the same ant mechansim, a global property - it's possible other tools will need a compiler ( what is cocoon doing ? ) ? I don't know recent Cocoon. But cocoon 1.8.x was using just tomcat's JavaCompiler;) This would also allow to automatically compile servlets ( the same as jsps are compiled ), Resin has it already. It's very useful:) thanks. Takashi Okamoto Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Question on mod_webapp and WebAppDeployment semantics
I was reviewing the source code and operation of the mod_webapp library
module and noticed a little operational quirk..
I've seen a couple of messages relevant to this but nothing that really
gives me the correct answer.
In the Sun Servlet specification v2.3 section 4.4 describes the parts that
make up a Request URI.
The problem is this:
lines 81-88 of jakarta-tomcat-connectors/webapp/lib/wa_config.c does some
normalizing of the deployment URL path:
81strncpy(buf,p,1024);
82l=strlen(buf)-1;
83if (buf[l]=='/') buf[l]='\0';
84if (buf[0]=='/' || l==0) {
85 appl-rpth=apr_pstrcat(wa_pool,buf,/,NULL);
86} else {
87 appl-rpth=apr_pstrcat(wa_pool,/,buf,/,NULL);
88}
In the case that the buffer is loaded with the correct application path
starting with '/' or if the application name is empty (indicating that this
is the ROOT context of the app server) a '/' is appended. Unfortunately
this causes a requests to /someapp to fail with a 404 and /someapp/ to work
correctly provided that there is a welcome file list associated with the
application. Applications like Tomcat's manager application choke on this,
as it's attempting to list the applications associated under '/' instead of
listing all the applications that are in the servlet. The manager think's
your asking for anything with the servlet path '/', as the breakdown of the
request URI is:
- Context Path = /manager (assuming we've deployed the manager as
'/manager')
- Servlet Path = /
- Path Info =
If the above code snippet was changed to the following:
strncpy(buf,p,1024);
l=strlen(buf)-1;
if (buf[l]=='/') buf[l]='\0';
if(l == 0) {
appl-rpth=apr_pstrcat(wa_pool, buf, NULL);
} else if (buf[0]=='/') {
appl-rpth=apr_pstrcat(wa_pool,buf,NULL);
} else {
appl-rpth=apr_pstrcat(wa_pool,/,buf,NULL);
}
I think it may solve the issue of application failure.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5229] New: - Session cannot unbind if using DistributedManager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5229. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5229 Session cannot unbind if using DistributedManager Summary: Session cannot unbind if using DistributedManager Product: Tomcat 4 Version: 4.0.1 Final Platform: All OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi If you use StandardCluster and DistributedManager in the server.xml, the HttpSessionBindingListener fails to get called. This is because when the session is replicated, the reference to the old object is lost. Hence, no events: Cluster className=org.apache.catalina.cluster.StandardCluster multicastPort=6789 multicastAddress=228.5.6.7 checkInterval=5 debug=99/ Context path=/coredev docBase=e:\opensource\e3\dev\www\core\webapp debug=0 reloadable=true Manager className=org.apache.catalina.session.DistributedManager debug=3 saveOnRestart=true maxActiveSessions=-1 minIdleSwap=-1 maxIdleSwap=-1 maxIdleBackup=-1 Store className=org.apache.catalina.session.FileStore/ /Manager /Context Regards Keith -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: server.xml DTD/Schema
On Fri, 30 Nov 2001, Mika Goeckel wrote: Date: Fri, 30 Nov 2001 14:02:01 +0100 From: Mika Goeckel [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: server.xml DTD/Schema Craig, yes, that's exactly the problem. Valve is another prominent case where the attribute-checking is not possible. One solution, but I confess that I would not recommend it, is to distinguish between the different types, i.e. change Valve to AccessLogValve,RequestDumperValve,RemoteHostFilter etc. That would certainly make the server.xml validatable, but create the burden of changing the xsd/dtd every times a user creates her own Valve/Logger/Realm etc. What if I wanted to add my own custom Valve implementation class? Doing this would mean I'd have to modify the code that processes server.xml, versus the current approach of just sticking your Valve implementation class in the right place, and adding the Valve entry in server.xml. Could xslt be a solution to check the required attributes if the dtd/schema uses union? Maybe that is to much effort because anyway if a required attribute is not present, the digester would moan. We explicitly turn DTD validation *off* when parsing the server.xml file. The problem isn't really missing required attributes. The problem is that * DTD validation will reject any attribute that is *not* listed in the DTD (required or not makes no difference). * You cannot even identify what the valid set of attributes is until runtime, because a Digester Rule implementation can dynamically choose whatever implementation class it wants, and can push any arbitrary object onto the evaluation stack whenever it wants. The Set Properties Rule works by matching attribute names against the JavaBeans properties of the top item on the evaluation stack, using Java reflection APIs. Bottom line -- XML validation technology is just not up to supporting the flexibility supported by the server.xml file. Mika Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Sat, 1 Dec 2001, Bill Barker wrote:
Date: Sat, 1 Dec 2001 17:17:31 -0800
From: Bill Barker [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: AJP Todo
I have no objection to help porting ${Server}Config to 4.x, but I'm still a
Catalina novice. The 3.3 API is more command and control, so it is easier
to get to the information.
+0 on officially supporting AJP in tomcat 4.x, as has been discussed
(i.e. I favor the idea, but cannot help).
It will take me a little time to find out how to
get the servlet-mappings in Catalina.
Nearly all of the configuration-related information related to a web
application is available via getXxx or findXxx methods on the
org.apache.catalina.context.Context interface. For servlet mappings in
particular, you can look up the mapping for a particular pattern with
findServletMapping(), or get all the defined mapping patterns with
findServletMappings().
There are similar methods available to access all the other stuff that was
configured in web.xml (or, in some cases, from server.xml).
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5229] - Session cannot unbind if using DistributedManager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5229. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5229 Session cannot unbind if using DistributedManager --- Additional Comments From [EMAIL PROTECTED] 2001-12-02 16:49 --- Hi I have looked into the code deeper and found the problem. When the first getSession() is called, the session is replicated using multicast. At this time the multicast receiver is sleeping. During this time, the session is modified (ie modify the object that is bound to the session). When the multicast receiver wakes up and start receiving, it overwrites the changes to the session. Tomcat somehow needs to know how to replicate with the guarantee that it will not overwrite new session state. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PATCH: LocalStrings_ja.properties
On Sun, 2 Dec 2001, Kazuhiro Kazama wrote: Date: Sun, 02 Dec 2001 12:42:30 +0900 (JST) From: Kazuhiro Kazama [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: PATCH: LocalStrings_ja.properties I found the following differences between original messages and japanese translations. 1, I forgot to translate Craig's changes in catalina/src/share/org/apache/catalina/core/LocalStrings.properties. 2, I translated addition of messages in catalina/src/share/org/apache/catalina/realm/LocalStrings_ja.properties and post it, but it isn't merged. Would you merge this patch? Kazuhiro Kazama ([EMAIL PROTECTED]) NTT Network Innovation Laboratories I had the enjoyable opportunity to meet Kazama-san and several other avid supporters of Jakarta projects while I was at JavaOne Japan last week in Yokohama. Thank you for your continued help! For Japanese speakers who would like support on Jakarta projects in your native language, check out the Ja-Jakarta web site at: http://www.ingrid.org/jajakarta/ It contains Japanese translations of a large portions of the information available at jakarta.apache.org, as well as links to Japanese-language mailing lists on the various projects. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 4.0.1 and persistent connection problem
Sir, If I will contribute patches to fix this problem, which module I should check out? Regards yang Remy Maucherat wrote: Dear Sir I already did some research about this problem. But still be confused. I want to take advantage of the persistent connection of Http/1.1. In my experiement, if HTTP/1.1 client connects to the tomcat 4.0.1 Http/1.1 directly, the persistent connection can be established. However, it is usless because actually all companies employ http proxies. Furthermore, a lot of them such as the squid is a http/1.0 proxy. in my application, the client (http/1.1) - squid proxy(http/1.0) tomcat 4.0.1.(Http/1.1) I found that tomcat 4.0.1 always sends a FIN package after it sends the response even i send the Connection: Keep-Alive in the request header. Also, I know the tomcat does also received Connection: Keep-Alive header via proxy. I did a comparison between tomcat4.0.1 and apache 1.3.9, the results show that if If I add Connection: Keep-Alive header in the request, apache server will keep the connection alive even the proxy/client sends a HTTP/1.0 package. However, It seems that tomcat 4.0.1 doesn't support this feature. I think this feature isn't defined in specification, however, it is so important that it provide the only way(am i right?) to establish persistent connection in real world which is consisted of unexpected HTTP/1.0 proxies. I don't know whether my understanding is correct or not. Any comments are welcome. That's correct. Tomcat 4 doesn't support legacy HTTP/1.0 keepalive. As usual, if you want to have it fixed you can contribute patches. Keepalives over HTTP/1.0 are not that useful in a JSP / servlets environment, as in many many cases, the content-length of the response is not set. Overall, I think it's time for HTTP/1.0 to go away (1.1 has been around for some time now). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- ^ ^ (oo)\___ (__)\ )\/\ ||w | || || Welcome http://192.168.213.203 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5231] New: - Tomcat 3.2.4 does not start due to error in classpath in tomcat.bat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5231. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5231 Tomcat 3.2.4 does not start due to error in classpath in tomcat.bat Summary: Tomcat 3.2.4 does not start due to error in classpath in tomcat.bat Product: Tomcat 3 Version: 3.2.x Nightly Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Config AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It appears that the org.xml.sax.* classes have been moved from parser.jar to crimson.jar between 3.2.3 and 3.2.4, but tomcat.bat has not been changed to reflect this in the staticClasspath section, so we get a NoClassDefFoundError exception for org.xml.sax.HandlerBase when attempting to start Tomcat. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters IdentityInputFilter.java IdentityOutputFilter.java
remm01/12/02 22:09:30
Modified:http11/src/java/org/apache/coyote/http11
Http11Connector.java InputFilter.java
InternalInputBuffer.java InternalOutputBuffer.java
OutputFilter.java
http11/src/java/org/apache/coyote/http11/filters
IdentityInputFilter.java IdentityOutputFilter.java
Log:
- Continuing development.
- Change the pattern used by the filters to use a more conventional chain. The
old machanism was too constraining.
Revision ChangesPath
1.3 +48 -7
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Connector.java
Index: Http11Connector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Connector.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Http11Connector.java 2001/10/01 01:20:42 1.2
+++ Http11Connector.java 2001/12/03 06:09:30 1.3
@@ -59,6 +59,8 @@
package org.apache.coyote.http11;
+import java.io.EOFException;
+import java.io.InterruptedIOException;
import java.io.InputStream;
import java.io.IOException;
import java.io.OutputStream;
@@ -156,17 +158,56 @@
inputBuffer.setInputStream(input);
outputBuffer.setOutputStream(output);
+// Ok flag
+boolean ok = true;
+// TEMP
+boolean stopped = false;
+
+while (!stopped ok) {
+
+try {
+inputBuffer.parseRequestLine();
+// Check for HTTP/0.9
+
+inputBuffer.parseHeaders();
+} catch (EOFException e) {
+ok = false;
+} catch (InterruptedIOException e) {
+//HttpServletResponse.SC_BAD_REQUEST
+ok = false;
+} catch (Exception e) {
+//SC_BAD_REQUEST
+ok = false;
+}
+
+// Setting up filters, and parse some request headers
+prepareRequest();
+
+// Process the request in the adapter
+try {
+adapter.service(request, response);
+} catch (InterruptedIOException e) {
+ok = false;
+} catch (Throwable t) {
+// ISE
+ok = false;
+}
+
+// Finish the handling of the request
+try {
+outputBuffer.endRequest();
+} catch (IOException e) {
+ok = false;
+} catch (Throwable t) {
+// Problem ...
+ok = false;
+}
+// FIXME: Next request
-
-try {
-adapter.service(request, response);
-} catch (Exception e) {
-;
}
-
-
+// FIXME: Recycle
}
1.3 +6 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InputFilter.java
Index: InputFilter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InputFilter.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- InputFilter.java 2001/09/17 21:27:31 1.2
+++ InputFilter.java 2001/12/03 06:09:30 1.3
@@ -107,4 +107,10 @@
public ByteChunk getEncodingName();
+/**
+ * Set the next buffer in the filter pipeline.
+ */
+public void setBuffer(InputBuffer buffer);
+
+
}
1.2 +51 -26
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalInputBuffer.java
Index: InternalInputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalInputBuffer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- InternalInputBuffer.java 2001/09/17 06:04:00 1.1
+++ InternalInputBuffer.java 2001/12/03 06:09:30 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalInputBuffer.java,v
1.1 2001/09/17 06:04:00 remm Exp $
- * $Revision: 1.1 $
- * $Date: 2001/09/17 06:04:00 $
+ * $Header:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalInputBuffer.java,v
1.2 2001/12/03 06:09:30 remm Exp $
+ * $Revision: 1.2 $
+ * $Date: 2001/12/03 06:09:30 $
*
*
*
@@ -111,6 +111,8 @@
headerBuffer2 = new
i18n/servlets/jsp: tutorial/essay
Hello, community! :-) I have spent quite a bit time solving two complementary problems: outputting web pages in national (cyrillic, Japanese, Chinese)characters/ reading form parameters with national characters with servlets/jsps. I have also spent quite a bit time answering questions about these tasks in several mailists - looks like this sometimes becomes a quest for people. So I have written a short tutorial/essay on this topic that I would like now to present for your attention and review. http://tagunov.newmail.ru/i18n/i18n.html I would really this to be the link I will easily send people when I hear them ask again questions that I have already answered a number of times various maillists, so I modestly ask those of you who are interested in the subject and/or have any experience in this field to comment on it and correct my surely numerous and large mistakes :-) BTW, i have developed one arguable idea in this essay that i would very much like to discuss with experts. It is about the fact that you can't dynamically choose a charset in a jsp in a servlet-engine portable way.. This idea closely touches the question of how functional any imagenable i18n taglib can be and thus has a direct connection with i18n taglibrary developmet. There are a couple places in this essay that i would eagerly like to make more complete. To do this i need feedback, especially from people who run servlet engines different from mine... Having thought through my ideas well i would certainly like now to share them with the community and possibly start some discussion around it! :-) And without any doubt, I invite everybody who is experiencing problems with i18n/servlets/jsps to try to find some help in this modest study. -- Sincerely yours, Anton Tagunov http://tagunov.newmail.ru mailto:[EMAIL PROTECTED] P.S. I'm sorry not to be on the list, (it's actually so crowded!) so if you want me to hear your replies, please e-mail directly! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
