Re: TC4 base dir
On Fri, 24 Aug 2001, Craig R. McClanahan wrote: |That's cool about the server.xml file, and you can do the individual |elements, as you said (logger, default valve's logger for access, |etc.) but what I'm wondering about is if there's anything analogous to |changing the entire base dir (not just apps, but entire thing a la |3.x) ? | | The entire base directory is wherever the CATALINA_HOME environment | variable says it is, if you have that defined already.I have my | CATALINA_HOME always set, so that I can have little scripts like | catstart to start it on demand from whatever directory I'm in: | | $CATALINA_HOME/bin/catalina.sh start $@ | | Ok my last try since I think I'm not being clear enough =) | | TC 3.x has this: | | !-- | You can add a home attribute to represent the base for | all relative paths. If none is set, the TOMCAT_HOME property | will be used, and if not set . will be used. | webapps/, work/ and logs/ will be relative to this ( unless | set explicitely to absolute paths ). | -- | ContextManager debug=0 home=/home/rslifka/slifka-tomcat showDebugInfo= | true | | ...allowing me to use a single $TOMCAT_HOME/conf, /bin, etc. dir, but | many instances of /webapps, /work and /logs spread out wherever I | like. If Catalina has this something similar, then I'd like to make | sure I document it in my Running Multiple Instances doc =) | | - r | | | | No, Tomcat 4 doesn't currently have a thing like home -- patches are | welcome! But, my point is you don't *need* home to accomplish the | goals you have articulated: In my setup I have a couple of developers which need their own instance of Tomcat. It's very inconvenint that you _have_ to install tomcat at the place where you want to run it, and thus cannot handle tomcat as just another binary, which you just run with some options or env-vars set correctly. And apparently it's just a few env-variables that isn't handled quite correctly that messes up everything. I remeber that I managed to get it to run with another server.xml file (or whatever it's called), but it requeried some variable to be set to the install dir (CATALINA_HOME?). But doing this made it scan the install-webapps dir, starting up all those webapps that are bundled with the dist. Basically, what it lacks is a distinct CATALINA_HOME, which points to where it's installed (keeping with the naming of the JAVA_HOME variable?) and a CATALINA_WORK or similar, where it's running. These two variables are treated very inconsistent now, and have (as I remeber it) to point to the same location to work properly. This is such a banal feature that I cannot understand why it isn't implemented. There have been others requesting this too! And I know your answer, revolving around scratch your own bleedin' itch!! ;), but sadly I currently don't have time to sit down and understand all that startup stuff, no matter how much I'd like to do just that. I do actually believe that folks that know the startup sequence of Tomcat4 could change this behaviour in about 5 minutes. I hope that this is _fixed_ before you go final. -- Mvh, Endre
Re: TC4 base dir
Craig R. McClanahan [EMAIL PROTECTED] wrote:
No, Tomcat 4 doesn't currently have a thing like home -- patches are
welcome! But, my point is you don't *need* home to accomplish the
goals you have articulated:
while we are on a related topic, how about (re) considering this patch?
geoff
- Original Message -
From: Geoff Soutter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 19, 2001 1:36 PM
Subject: [t4] [patch] for inconvenient -config current dir
Hi there,
As I've been twiddling with T4 again recently this problem has resurfaced.
In T3, I was able to specify the -config option relative to my current
directory. T4 has changed this so that a relative path used with -config
is
resolved relative to CATALINA_HOME.
I find this annoying because I like to store my server.xml files into our
version control system, and it means that relative paths from my VCS work
dir to the server.xml don't work any more. I have to use something like
/vcs work dir/tomcat4/server.xml. Now, if you use an IDE to debug your
servlet in Tomcat, you need to enter this path into the config. And that
means that every time you create a new work dir, you need to update your
IDE
project file.
So, can we please change back to -config relative to the CWD the way
Tomcat 3 worked? Or perhaps at least get it to check for it relative to
CWD
before checking relative to CATALINA_HOME?
All thats required is to remove/change the absolute path stuff in the
configFile() method of Catalina.java like so:
protected File configFile() {
File file = new File(configFile);
/*
NOTE: alternatively use !file.exists() here for fallback
from CWD to CATALINA_HOME
if (!file.isAbsolute())
file = new File(System.getProperty(catalina.home) +
File.separator + configFile);
*/
return (file);
}
Geoff
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server PoolTcpConnector.java
nacho 01/08/27 02:44:18
Modified:src/share/org/apache/tomcat/modules/server
PoolTcpConnector.java
Log:
Bug#578
no cookies session tracking fails when used with SSL
Reported by sgala at hisitech.com (Santiago Gala)
This fix is only for the standalone HTTP connector when used SSL,
we need to find a more general patch that works with mod_jk too,
without JSSE and a SSL standalone connector configured.
Revision ChangesPath
1.9 +5 -2
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/PoolTcpConnector.java
Index: PoolTcpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/PoolTcpConnector.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- PoolTcpConnector.java 2001/08/19 22:48:56 1.8
+++ PoolTcpConnector.java 2001/08/27 09:44:18 1.9
@@ -241,8 +241,8 @@
javax.net.ssl.SSLServerSocketFactory;
public static final String SSL_FACT=
org.apache.tomcat.util.net.SSLSocketFactory;
-
-
+
+
public void setSecure( boolean b ) {
enabled=false;
secure=false;
@@ -266,6 +266,9 @@
log( Error loading SSL socket factory , ex);
return;
}
+
+System.getProperties().put(java.protocol.handler.pkgs,
+com.sun.net.ssl.internal.www.protocol);
}
secure=b;
enabled=true;
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
remm01/08/27 04:50:41
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
- A 206 returned an incorrect content length, instead of the actual number of bytes
returned.
Fix for bug 3274.
Revision ChangesPath
1.38 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- DefaultServlet.java 2001/07/22 20:25:11 1.37
+++ DefaultServlet.java 2001/08/27 11:50:41 1.38
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.37 2001/07/22 20:25:11 pier Exp $
- * $Revision: 1.37 $
- * $Date: 2001/07/22 20:25:11 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.38 2001/08/27 11:50:41 remm Exp $
+ * $Revision: 1.38 $
+ * $Date: 2001/08/27 11:50:41 $
*
*
*
@@ -122,7 +122,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.37 $ $Date: 2001/07/22 20:25:11 $
+ * @version $Revision: 1.38 $ $Date: 2001/08/27 11:50:41 $
*/
public class DefaultServlet
@@ -1206,7 +1206,7 @@
+ range.start
+ - + range.end + /
+ range.length);
-response.setContentLength((int) range.length);
+response.setContentLength((int) (range.end - range.start));
if (contentType != null) {
if (debug 0)
cvs commit: jakarta-tomcat/src/doc tomcat-ug.html
larryi 01/08/27 06:54:39 Modified:src/doc tomcat-ug.html Log: Included patch for server.xml text. Submitted by: Bojan Smojver Also updated directory structure table and other edits. Revision ChangesPath 1.11 +110 -90 jakarta-tomcat/src/doc/tomcat-ug.html Index: tomcat-ug.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ug.html,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- tomcat-ug.html2001/08/15 19:53:19 1.10 +++ tomcat-ug.html2001/08/27 13:54:39 1.11 @@ -1,7 +1,7 @@ !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head -!-- $Id: tomcat-ug.html,v 1.10 2001/08/15 19:53:19 larryi Exp $ -- +!-- $Id: tomcat-ug.html,v 1.11 2001/08/27 13:54:39 larryi Exp $ -- !-- Copyright 1999-2001 Apache Software Foundation -- meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 link rel=stylesheet href=style.css @@ -404,38 +404,77 @@ /tr tr td WIDTH=15% align=centerconf/td -td WIDTH=85% Configuration files including a href=#server_xmlserver.xml/a (Tomcat's main configuration file) and - a href=#web_xml - web.xml/a (default values for the various web applications deployed in - Tomcat.). +td WIDTH=85% a hrev=#configuring_serverConfiguration files/a, + including modules.xml, server.xml, and a number of apps-ilt;namegt;/i.xml/a. /td /tr - tr -td WIDTH=15% align=centerdoc/td -td WIDTH=85%Miscellaneous documents regarding Tomcat./td - /tr - tr -td WIDTH=15% align=centerlib/td -td WIDTH=85% Various jar files that are used by Tomcat. - Any file in this directory is appended to Tomcat's classpath. -/td - /tr - tr -td WIDTH=15% align=centera name=logs_dir_defnlogs/a/td -td WIDTH=85% This is where Tomcat places its log files by default./td - /tr - tr -td WIDTH=15% align=centersrc/td -td WIDTH=85% The servlet API source files. Don't get excited, - though; these are only the empty interfaces and abstract - classes that should be implemented by any servlet - container./td - /tr - tr -td WIDTH=15% align=centerwebapps/td -td WIDTH=85% Sample web applications. Any .war files placed - here will be automatically expanded. See a href=#deploying_warDeploying WAR files/a./td - /tr +tr + td width=15% align=centerconf/auto/td + td width=85%Directory where auto-generated configuration files are +written./td + /tr + tr + td width=15% align=centerconf/jk/td + td width=85%Directory containing mod_jk specific configuration files./td + /tr + tr + td width=15% align=centerconf/jserv/td + td width=85%Directory containing mod_jserv specific configuration files./td + /tr + tr + td width=15% align=centerconf/users/td + td width=85%Directory containing user name/password configuration files. +These are used by the SimpleRealm module for authentication./td + /tr +tr + td WIDTH=15% align=centerdoc/td + td WIDTH=85%Miscellaneous documents regarding Tomcat./td +/tr +tr + td WIDTH=15% align=centerlib/td + td WIDTH=85%Jar files that are used for starting and stopping Tomcat./td +/tr + tr + td width=15% align=centerlib/container/td + td width=85%Jar files that make up the Tomcat server classes. Any +Jar file in this directory is automatically included in Tomcat's +bServer Classloader/b. See +a href=#configuring_classesConfiguring Classes/a./td + /tr + tr + td width=15% align=centerlib/common/td + td width=85%Jar files that contain classes shared between the Tomcat +server and all web applications. Any Jar file in this directory is +automatically included in Tomcat's bCommon Classloader/b. See +a href=#configuring_classesConfiguring Classes/a./td + /tr + td width=15% align=centerlib/apps/td + td width=85%Jar files that contain classes shared between all web +applications. Any Jar file in this directory is automatically included +in Tomcat's bApps Classloader/b. See +a href=#configuring_classesConfiguring Classes/a./td +tr + td WIDTH=15% align=centera name=logs_dir_defnlogs/a/td + td WIDTH=85% This is where Tomcat places its log files by default./td +/tr + tr + td width=15% align=centermodules/td + td width=85%Directory where quot;pluginquot; jars are placed./td
[PATCH TC4] added jndi.jar to classpath in javac task
Catalina would not compile without adding jndi.jar to the classpath for catalina and the webapp/examples. Presumably this is not affecting people because they have it in there environment classpath. (I think I submitted this a while ago also.) diffed against current cvs update Cheers, jr -- John Reilly - [EMAIL PROTECTED] Xelector Ltd. 76 Talbot St. Dublin 1. -- catalina_build.diff
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java
keith 01/08/27 08:21:43
Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java
Log:
Update implementation to reflect Connector interface change.
Revision ChangesPath
1.5 +22 -5
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connector.java
Index: Ajp13Connector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connector.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Ajp13Connector.java 2001/07/25 14:49:51 1.4
+++ Ajp13Connector.java 2001/08/27 15:21:43 1.5
@@ -83,6 +83,7 @@
import org.apache.catalina.Logger;
import org.apache.catalina.Request;
import org.apache.catalina.Response;
+import org.apache.catalina.Service;
import org.apache.catalina.net.DefaultServerSocketFactory;
import org.apache.catalina.net.ServerSocketFactory;
import org.apache.catalina.util.LifecycleSupport;
@@ -265,7 +266,10 @@
private Ajp13Logger logger = new Ajp13Logger();
-
+/**
+ * The service which which the connector is associated
+ */
+private Service service = null;
// - Properties
@@ -610,6 +614,19 @@
}
+/**
+ * Returns the codeService/code with which we are associated.
+ */
+public Service getService() {
+ return service;
+}
+
+/**
+ * Set the codeService/code with which we are associated.
+ */
+public void setService(Service service) {
+ this.service = service;
+}
// - Public Methods
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c jk_ajp_common.h
keith 01/08/27 08:33:04
Modified:jk/doc AJPv13.html
jk/java/org/apache/ajp Ajp13.java RequestHandler.java
jk/native/common jk_ajp_common.c jk_ajp_common.h
Log:
Add REPORT method to Ajp13 (necessary for Webdav ACL
and Delta-V). This has also been added to jakarta-tomcat.
Revision ChangesPath
1.3 +2 -1 jakarta-tomcat-connectors/jk/doc/AJPv13.html
Index: AJPv13.html
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/doc/AJPv13.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AJPv13.html 2001/05/20 22:57:56 1.2
+++ AJPv13.html 2001/08/27 15:33:04 1.3
@@ -357,7 +357,8 @@
MOVE12
LOCK13
UNLOCK 14
-ACL 15
+ACL 15
+REPORT 16
/PRE
P
/DD
1.9 +2 -1 jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java
Index: Ajp13.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Ajp13.java2001/06/25 16:00:38 1.8
+++ Ajp13.java2001/08/27 15:33:04 1.9
@@ -154,7 +154,8 @@
MOVE,
LOCK,
UNLOCK,
-ACL
+ACL,
+REPORT
};
// id's for common request headers
1.2 +2 -1
jakarta-tomcat-connectors/jk/java/org/apache/ajp/RequestHandler.java
Index: RequestHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/RequestHandler.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- RequestHandler.java 2001/06/27 15:50:43 1.1
+++ RequestHandler.java 2001/08/27 15:33:04 1.2
@@ -148,7 +148,8 @@
MOVE,
LOCK,
UNLOCK,
-ACL
+ACL,
+REPORT
};
// id's for common request headers
1.8 +2 -0 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index: jk_ajp_common.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jk_ajp_common.c 2001/08/23 15:51:08 1.7
+++ jk_ajp_common.c 2001/08/27 15:33:04 1.8
@@ -130,6 +130,8 @@
*sc = SC_M_UNLOCK;
} else if(0 == strcmp(method, ACL)) {
*sc = SC_M_ACL;
+} else if(0 == strcmp(method, REPORT)) {
+ *sc = SC_M_REPORT;
} else {
rc = JK_FALSE;
}
1.6 +5 -3 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.h
Index: jk_ajp_common.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.h,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jk_ajp_common.h 2001/07/23 21:02:43 1.5
+++ jk_ajp_common.h 2001/08/27 15:33:04 1.6
@@ -59,7 +59,7 @@
* Description: common stuff for bi-directional protocol ajp13/ajp14. *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Author: Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.5 $ *
+ * Version: $Revision: 1.6 $ *
***/
#ifndef JK_AJP_COMMON_H
@@ -108,7 +108,8 @@
*| MOVE
*| LOCK
*| UNLOCK
- *| ACL
+ *| ACL
+ *| REPORT
*
*/
#define SC_M_OPTIONS(unsigned char)1
@@ -125,7 +126,8 @@
#define SC_M_MOVE (unsigned char)12
#define SC_M_LOCK (unsigned char)13
#define SC_M_UNLOCK (unsigned char)14
-#define SC_M_ACL (unsigned char)15
+#define SC_M_ACL (unsigned char)15
+#define SC_M_REPORT (unsigned char)16
/*
cvs commit: jakarta-tomcat-connectors/util .cvsignore
keith 01/08/27 08:36:47 Added: jk .cvsignore util .cvsignore Log: .cvsignore goodness Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/.cvsignore Index: .cvsignore === build build.properties 1.1 jakarta-tomcat-connectors/util/.cvsignore Index: .cvsignore === build
RE: [PATCH TC4] added jndi.jar to classpath in javac task
Hi John,
I did not need to do this to build tc4 out of the box.
What was the build error? Is your build.properties pointing
to jndi OK? If you do an ant -verbose, does ${jndi.home}
get set correctly? TC4 will automatically include
${jndi.home}/lib/jndi.jar (see catalina/build.xml:28)
Keith
| -Original Message-
| From: Reilly, John [mailto:[EMAIL PROTECTED]]
| Sent: Monday, August 27, 2001 11:09 AM
| To: Tomcat Dev (E-mail)
| Subject: [PATCH TC4] added jndi.jar to classpath in javac task
|
|
|
| Catalina would not compile without adding jndi.jar to the classpath for
| catalina and the webapp/examples. Presumably this is not affecting people
| because they have it in there environment classpath. (I think I submitted
| this a while ago also.)
|
| diffed against current cvs update
|
| Cheers,
| jr
RE: [PATCH TC4] added jndi.jar to classpath in javac task
Hi John,
I did not need to do this to build tc4 out of the box.
What was the build error? Is your build.properties pointing
to jndi OK? If you do an ant -verbose, does ${jndi.home}
get set correctly? TC4 will automatically include
${jndi.home}/lib/jndi.jar (see catalina/build.xml:28)
The problem is that the javac task on line 138 did not use ${jndi.jar}. The
build error was that it could not import the javax.naming classes. Changing
the javac task as per the diff fixed the problem (this would not have worked
if I did not have jndi.home set in my build.properties).
If you do a grep on the build.xml you will see that the unpatched version
only defines ${jndi.jar} and uses it on line 93 to copy jndi.jar to
common/lib
The only way you would be able to compile without the changes I suggested
would be to have jndi.jar in your environment CLASSPATH or in the ext
directory of your jre/jdk. (I think)
Keith
| -Original Message-
| From: Reilly, John [mailto:[EMAIL PROTECTED]]
| Sent: Monday, August 27, 2001 11:09 AM
| To: Tomcat Dev (E-mail)
| Subject: [PATCH TC4] added jndi.jar to classpath in javac task
|
|
|
| Catalina would not compile without adding jndi.jar to the
classpath for
| catalina and the webapp/examples. Presumably this is not
affecting people
| because they have it in there environment classpath. (I
think I submitted
| this a while ago also.)
|
| diffed against current cvs update
|
| Cheers,
| jr
Apache Web Server and tomcat for Java support
Hi, I want to know whether there is a new way for communication between Apache Web Server and Tomcat to support Java: for example, tomcat as a loadable module to Apache Web Server, so we need not start Tomcat and Apache Web Server seperately. Thanks! Xuemei
cvs commit: jakarta-tomcat-4.0/webapps/examples build.xml
craigmcc01/08/27 09:47:57
Modified:catalina build.xml
webapps/examples build.xml
Log:
Add jndi.jar to the compile classpath as needed to build Tomcat 4 on JDK
1.2 systems. This was not a problem on JDK 1.3, because the JNDI classes
have been integrated into the core JVM.
Submitted by: John Reilly [EMAIL PROTECTED]
Revision ChangesPath
1.52 +1 -1 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- build.xml 2001/08/24 23:06:08 1.51
+++ build.xml 2001/08/27 16:47:57 1.52
@@ -136,7 +136,7 @@
excludes=**/CVS/** /
!-- Compile internal server components --
javac srcdir=src/share destdir=${catalina.build}/classes
-
classpath=${parser.jar}:${jaxp.jar}:${regexp.jar}:${servlet.jar}:${jcert.jar}:${jnet.jar}:${jsse.jar}:${jmxri.jar}
+
classpath=${parser.jar}:${jaxp.jar}:${regexp.jar}:${servlet.jar}:${jcert.jar}:${jnet.jar}:${jsse.jar}:${jmxri.jar}:${jndi.jar}
deprecation=off debug=on optimize=off target=1.2
excludes=**/CVS/**
exclude name=**/factory/Tyrex*.java
1.9 +1 -1 jakarta-tomcat-4.0/webapps/examples/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/build.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- build.xml 2001/05/21 21:47:30 1.8
+++ build.xml 2001/08/27 16:47:57 1.9
@@ -41,7 +41,7 @@
javac srcdir=WEB-INF/classes
destdir=${webapps.build}/${webapp.name}/WEB-INF/classes
- classpath=${servlet.jar}
+ classpath=${servlet.jar}:${jndi.jar}
deprecation=off debug=on optimize=off
excludes=**/CVS/**/
Re: TC4 base dir
On Mon, 27 Aug 2001, Geoff Soutter wrote: while we are on a related topic, how about (re) considering this patch? The patch below deals with only one of 33 places that the catalina.home system property is referenced in the Catalina source code -- I think we'd want to consider them all :-). In order to support the idea of one install of Tomcat 4 being used for more than one configuration, we have to decide which subdirectories of $CATALINA_HOME should be made relative to some new location (specified by a command line option or a different environment variable). Here's my proposed breakdown: All of the following directories would be considered part of the static part of a Tomcat 4 installation, and would remain relative to $CATALINA_HOME (and thus shared by all uses): bin/ classes/ common/ classes/ lib/ jasper/ lib/ server/ All of the following directories, unless configured to absolute paths, would be resolved relative to a new $CATALINA_BASE directory (defaults to $CATALINA_HOME if not set) that would be used to configure a new catalina.base system property: conf/ logs/ webapps/ work/ With this arrangement, all of the binaries and Java classes installed in $CATALINA_HOME would be shared by all uses, but the configuration files, log files, web applications, and work directories would be unique. Does that sound like the right breakdown? geoff Craig
RE: isapi_redirect.dll
see the following: http://jakarta.apache.org/site/binindex.html i believe what you are looking for is this: http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.3/bin/win32/i38 6/ -Original Message- From: Golash Rahul [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 7:07 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: isapi_redirect.dll Hi there, Where can i find the isapi_redirect.dll which is required to redirect the requests to tomcat server while using IIS Web server as a front server for the Servlets on WinNT. Please acknowledge soon. with best regards rahul golash ___ SIEMENS Siemens Information Systems Ltd No 84, Keonics Electronics City Hosur Road, Bangalore 561 229 Rahul Golash mailto:[EMAIL PROTECTED] Systems Engineer *: +91 80 809 1288 Fax: +91 80 852 1119 ___
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves AccessLogValve.java
craigmcc01/08/27 12:10:26 Modified:catalina/src/bin catalina.bat catalina.sh catalina/src/share/org/apache/catalina/connector/warp WarpConfigurationHandler.java catalina/src/share/org/apache/catalina/core StandardContext.java StandardHost.java catalina/src/share/org/apache/catalina/logger FileLogger.java catalina/src/share/org/apache/catalina/realm MemoryRealm.java catalina/src/share/org/apache/catalina/startup Catalina.java CatalinaService.java ContextConfig.java HostConfig.java catalina/src/share/org/apache/catalina/valves AccessLogValve.java Log: Enhance Catalina startup/shutdown processing to support a new (optional) environment variable (CATALINA_BASE), and corresponding system property (catalina.base). If not set, these values default to corresponding values for CATALINA_HOME and catalina.home, respectively. When you set CATALINA_BASE to point to a directory other than the one pointed to by CATALINA_HOME, you are changing the *default* base from which all references to files in the conf, logs, webapps, and work directories are resolved. This allows you to share the static portion of a Tomcat 4 installation (read-only) among multiple uses of that installation on the same server. TODO: A pass through the docs to update them with this new information is coming up shortly. Submitted by: Too numerous to count :-) Revision ChangesPath 1.17 +19 -6 jakarta-tomcat-4.0/catalina/src/bin/catalina.bat Index: catalina.bat === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/catalina.bat,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- catalina.bat 2001/07/13 22:37:20 1.16 +++ catalina.bat 2001/08/27 19:10:25 1.17 @@ -4,6 +4,10 @@ rem rem Environment Variable Prequisites: rem +rem CATALINA_BASE (Optional) Base directory for resolving dynamic portions +rem of a Catalina installation. If not present, resolves to +rem the same directory that CATALINA_HOME points to. +rem rem CATALINA_HOME (Optional) May point at your Catalina build directory. rem If not present, the current working directory is assumed. rem @@ -12,12 +16,13 @@ rem rem JAVA_HOME Must point at your Java Development Kit installation. rem -rem $Id: catalina.bat,v 1.16 2001/07/13 22:37:20 remm Exp $ +rem $Id: catalina.bat,v 1.17 2001/08/27 19:10:25 craigmcc Exp $ rem --- rem - Save Environment Variables That May Change -- +set _CATALINA_BASE=%CATALINA_BASE% set _CATALINA_HOME=%CATALINA_HOME% set _CLASSPATH=%CLASSPATH% set _CP=%CP% @@ -41,6 +46,10 @@ goto cleanup :okCatalinaHome +if not %CATALINA_BASE% == goto gotCatalinaBase +set CATALINA_BASE=%CATALINA_HOME% +:gotCatalinaBase + rem - Prepare Appropriate Java Execution Commands - @@ -57,6 +66,8 @@ set CP=%CATALINA_HOME%\bin\bootstrap.jar;%JAVA_HOME%\lib\tools.jar set CLASSPATH=%CP% +echo Using CATALINA_BASE: %CATALINA_BASE% +echo Using CATALINA_HOME: %CATALINA_HOME% echo Using CLASSPATH: %CLASSPATH% @@ -81,23 +92,23 @@ :doRun if %2 == -security goto doRunSecure -%_RUNJAVA% %CATALINA_OPTS% -Dcatalina.home=%CATALINA_HOME% org.apache.catalina.startup.Bootstrap %2 %3 %4 %5 %6 %7 %8 %9 start +%_RUNJAVA% %CATALINA_OPTS% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% org.apache.catalina.startup.Bootstrap %2 %3 %4 %5 %6 %7 %8 %9 start goto cleanup :doRunSecure -%_RUNJAVA% %CATALINA_OPTS% -Djava.security.manager -Djava.security.policy==%CATALINA_HOME%/conf/catalina.policy -Dcatalina.home=%CATALINA_HOME% org.apache.catalina.startup.Bootstrap %3 %4 %5 %6 %7 %8 %9 start +%_RUNJAVA% %CATALINA_OPTS% -Djava.security.manager -Djava.security.policy==%CATALINA_BASE%/conf/catalina.policy -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% org.apache.catalina.startup.Bootstrap %3 %4 %5 %6 %7 %8 %9 start goto cleanup :doStart if %2 == -security goto doStartSecure -%_STARTJAVA% %CATALINA_OPTS% -Dcatalina.home=%CATALINA_HOME% org.apache.catalina.startup.Bootstrap %2 %3 %4 %5 %6 %7 %8 %9 start +%_STARTJAVA% %CATALINA_OPTS% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% org.apache.catalina.startup.Bootstrap %2 %3 %4 %5 %6 %7 %8 %9 start goto cleanup :doStartSecure echo Using Security Manager -%_STARTJAVA% %CATALINA_OPTS% -Djava.security.manager
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config context.xml host.xml loader.xml logger.xml realm.xml valve.xml
craigmcc01/08/27 13:22:37 Modified:.RUNNING.txt webapps/tomcat-docs manager-howto.xml ssl-howto.xml webapps/tomcat-docs/appdev deployment.xml source.xml webapps/tomcat-docs/config context.xml host.xml loader.xml logger.xml realm.xml valve.xml Log: Update tomcat-docs documents to reflect the option for CATALINA_BASE instead of CATALINA_HOME. Revision ChangesPath 1.2 +27 -2 jakarta-tomcat-4.0/RUNNING.txt Index: RUNNING.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RUNNING.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- RUNNING.txt 2001/07/27 22:26:03 1.1 +++ RUNNING.txt 2001/08/27 20:22:37 1.2 @@ -1,4 +1,4 @@ -$Id: RUNNING.txt,v 1.1 2001/07/27 22:26:03 craigmcc Exp $ +$Id: RUNNING.txt,v 1.2 2001/08/27 20:22:37 craigmcc Exp $ Running The Tomcat 4.0 Servlet/JSP Container @@ -101,7 +101,32 @@ ./shutdown.sh (Unix) -(4) Troubleshooting: +(4) Advanced Configuration - Multiple Tomcat 4 Instances + +In many circumstances, it is desireable to have a single copy of a Tomcat 4 +binary distribution shared among multiple users on the same server. To make +this possible, you must configure a CATALINA_BASE environment variable (in +addition to CATALINA_HOME as described above) that points to a directory +that is unique to your instance. + +When you do this, Tomcat 4 will calculate all relative references for files in +the following directories based on the value for CATALINA_BASE instead of +CATALINA_HOME: + +* conf - Server configuration files (including server.xml) + +* logs - Log and output files + +* webapps - Automatically loaded web applications + +* work - Temporary working directories for web applications + +If you do not set CATALINA_BASE to an explicit value, it will be initialized +to the same value as is set for CATALINA_HOME (which means that the same +directory is used for all relative path resoluations). + + +(5) Troubleshooting: There are only really 3 things that can go wrong during the stand-alone Tomcat 4.0 install: 1.2 +10 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/manager-howto.xml Index: manager-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/manager-howto.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- manager-howto.xml 2001/08/16 23:21:25 1.1 +++ manager-howto.xml 2001/08/27 20:22:37 1.2 @@ -59,6 +59,16 @@ section name=Configuring Manager Application Access +blockquoteem +pThe description below uses the variable name $CATALINA_HOME +to refer to the directory into which you have installed Tomcat 4, +and is the base directory against which most relative paths are +resolved. However, if you have configured Tomcat 4 for multiple +instances by setting a CATALINA_BASE directory, you should use +$CATALINA_BASE instead of $CATALINA_HOME for each of these +references./p +/em/blockquote + pIt would be quite unsafe to ship Tomcat with default settings that allowed anyone on the Internet to execute the Manager application on your server. Therefore, the Manager application is shipped with the requirement that anyone 1.3 +10 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml Index: ssl-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ssl-howto.xml 2001/08/21 20:22:52 1.2 +++ ssl-howto.xml 2001/08/27 20:22:37 1.3 @@ -16,6 +16,16 @@ section name=Quick-Start Version +blockquoteem +pThe description below uses the variable name $CATALINA_HOME +to refer to the directory into which you have installed Tomcat 4, +and is the base directory against which most relative paths are +resolved. However, if you have configured Tomcat 4 for multiple +instances by setting a CATALINA_BASE directory, you should use +$CATALINA_BASE instead of $CATALINA_HOME for each of these +references./p +/em/blockquote + pTo install and configure SSL support on Tomcat 4, you need to follow these simple steps. For more information, read the rest of this HOW-TO./p ol 1.3 +10 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/deployment.xml Index: deployment.xml === RCS file:
Re: cvs commit: jakarta-tomcat-4.0/tester/src/bin tester.xml
On Sat, 25 Aug 2001, Glenn Nielsen wrote: Date: Sat, 25 Aug 2001 21:12:18 -0500 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-4.0/tester/src/bin tester.xml Craig, Would this replacement URL class allow the manager servlet bug which prevents releoading a war file from the same URL to be fixed in Tomcat 4? Are you referring to a specific outstanding Bugzilla bug report? I'm not aware of a current issue (I thought it was addressed already). In principle, the new org.apache.catalina.util.URL is unlikely to deal with problems like this -- it does *not* included any openConnection() or openStream(). The problem that brought this about was that java.net.URL requires a valid URLStreamHandler, which means you cannot use it (for example) to do a response.sendRedirect() to an https server unless the *calling* Tomcat JVM has JSSE available. Regards, Glenn Craig
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs ssl-howto.xml
craigmcc01/08/27 13:39:55 Modified:webapps/tomcat-docs ssl-howto.xml Log: Update to the SSL HOW-TO w.r.t. server certificates on named virtual hosts sharing a single IP address. Submitted by: Christopher Cain [EMAIL PROTECTED] Revision ChangesPath 1.4 +15 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml Index: ssl-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ssl-howto.xml 2001/08/27 20:22:37 1.3 +++ ssl-howto.xml 2001/08/27 20:39:55 1.4 @@ -153,6 +153,21 @@ page request and take the appropriate action of codehttps/code is not specified./p +pFinally, using name-based virtual hosts on a secured connection can be +problematic. This is a design limitation of the SSL protocol itself. The SSL +handshake, where the client browser accepts the server certificate, must occur +before the HTTP request is accessed. As a result, the request information +containing the virtual host name cannot be determined prior to authentication, +ant it is therefore not possible to assign multiple certificates to a single +IP address. If all virtual hosts on a single IP address need to authenticate +against the same certificate, the addition of multiple virtual hosts should not +interfere with normal SSL operations on the server. Be aware, however, that +most client browsers will compare the server's domain name against the domain +name listed in the certificate, if any (applicable primarily to official, +CA-signed certificates). If the domain names do not match, these browsers will +display a warning to the client user. In general, only address-based virtual +hosts are commonly used with SSL in a production environment./p + /section section name=Configuration
cvs commit: jakarta-tomcat-4.0/webapps/webdav/WEB-INF web.xml
craigmcc01/08/27 13:57:22 Modified:webapps/ROOT/WEB-INF web.xml webapps/examples/WEB-INF web.xml webapps/manager/WEB-INF web.xml webapps/tomcat-docs/WEB-INF web.xml webapps/webdav/WEB-INF web.xml Log: Update the web application deployment descriptor DOCTYPE values to reflect what will be in the final spec. Submitted by: Thom Park [EMAIL PROTECTED] Revision ChangesPath 1.2 +1 -1 jakarta-tomcat-4.0/webapps/ROOT/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/ROOT/WEB-INF/web.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- web.xml 2000/08/23 18:29:54 1.1 +++ web.xml 2001/08/27 20:57:21 1.2 @@ -2,7 +2,7 @@ !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN -http://java.sun.com/j2ee/dtds/web-app_2_3.dtd; +http://java.sun.com/dtd/web-app_2_3.dtd; web-app /web-app 1.18 +1 -1 jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/WEB-INF/web.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- web.xml 2001/07/26 19:42:44 1.17 +++ web.xml 2001/08/27 20:57:21 1.18 @@ -2,7 +2,7 @@ !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN -http://java.sun.com/j2ee/dtds/web-app_2_3.dtd; +http://java.sun.com/dtd/web-app_2_3.dtd; web-app 1.3 +1 -1 jakarta-tomcat-4.0/webapps/manager/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/manager/WEB-INF/web.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- web.xml 2001/05/27 21:13:40 1.2 +++ web.xml 2001/08/27 20:57:21 1.3 @@ -2,7 +2,7 @@ !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN -http://java.sun.com/j2ee/dtds/web-app_2_3.dtd; +http://java.sun.com/dtd/web-app_2_3.dtd; web-app 1.2 +1 -1 jakarta-tomcat-4.0/webapps/tomcat-docs/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/WEB-INF/web.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- web.xml 2001/07/28 01:35:39 1.1 +++ web.xml 2001/08/27 20:57:21 1.2 @@ -2,7 +2,7 @@ !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN -http://java.sun.com/j2ee/dtds/web-app_2_3.dtd; +http://java.sun.com/dtd/web-app_2_3.dtd; web-app /web-app 1.2 +1 -1 jakarta-tomcat-4.0/webapps/webdav/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/webdav/WEB-INF/web.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- web.xml 2000/08/31 19:09:10 1.1 +++ web.xml 2001/08/27 20:57:22 1.2 @@ -2,7 +2,7 @@ !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN -http://java.sun.com/j2ee/dtds/web-app_2_3.dtd; +http://java.sun.com/dtd/web-app_2_3.dtd; web-app
Re: DTD DOCTYPE wrong in examples....?
On Tue, 21 Aug 2001, Thom Park wrote: Date: Tue, 21 Aug 2001 14:00:34 -0700 From: Thom Park [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: DTD DOCTYPE wrong in examples? Hello, Sun appear to have changed the DOCTYPE for the web application in servlet specification 2.3. Actually, in the draft spec it states that the doc type is: !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/j2ee/dtds/web-app_2_3.dtd; however, the actual location appears to be: http://java.sun.com/dtd/web-app_2_3.dtd This is the value that will be in the final spec (because that is where the DTD actually lives). I have just committed a fix to bring all the webapps included with Tomcat 4 up-to-date with respect to this. NOTE: Depending on what XML parser you use, an out-of-date value will not matter. Tomcat registers an internal copy of the DTD with its parser, so that as long as you get the public identifier correct, the parser will *not* try to retrieve the DTD across the network. -Thom Craig
Re: Fw: Bug in ServletResponse.flushBuffer() in Tomcat 4.0b7?
On Tue, 21 Aug 2001, Jonathan Eric Miller wrote: Date: Tue, 21 Aug 2001 10:47:11 -0500 From: Jonathan Eric Miller [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Tomcat Developer List [EMAIL PROTECTED] Subject: Fw: Bug in ServletResponse.flushBuffer() in Tomcat 4.0b7? I originally posted this to the tomcat-user list, but, I received no response. As far as I can tell, it's a bug, so, I'm now forwarding this to the developer list in hopes that someone here might be able to confirm whether this is a bug or not. If you know the answer and respond, please respond to me directly or post to the user list as I am not on this list. Thanks a lot. I think you guys are doing a great job. It's just a few small issues like this that I hope to resolve at this point. Jon Jon, I tried this with Tomcat 4.0 stand alone (current CVS code, Linux, JDK 1.3.1) and it works exactly as you expect -- you see the first part of the output, followed by a ten-second delay, followed by the second part. (Of course, I had to put the Thread.sleep() call into a try/catch block.) As you undoubtedly noticed, the HTML that you emit before the flush has to be completed paragraphs or other elements -- otherwise the characters will still get buffered inside the browser itself. One way to ensure that the browser is not messing you up is to do a telnet connection: telnet localhost 8080 and type GET /myapp/servlet/SimpleServlet HTTP/1.0 followed by a carriage return (^M) and line feed (^J). Craig
RE: Tomcat 3.2.3 and getPathInfo
Using Apache 1.3.19 here's what I see. Apache does normalize the URL but there is a small difference between what it does and what Tomcat does. Apache does not remove multiple adjacent / characters. For example, http://server/cgi-bin/script/fu/bar -- PATH_INFO = /fu/bar http://server/cgi-bin/script/fu/../bar -- PATH_INFO = /bar http://server/cgi-bin/script/fu//bar -- PATH_INFO = /fu//bar The multiple adjacent / characters don't seem to have any effect on locating resources. For example, http://server///cgi-bin/script/fu/bar works just fine. Unless other comitters feel otherwise, I'll work on changes to the tomcat_32 branch to make path info work as it does with CGI in Apache. Another difference is that the REQUEST_URI CGI variable is the original non-normalized URI, but Tomcat's getRequestURI() now returns the normalized version. I'm still waiting to hear back from the servlet expert group about whether the normalization plans are going into the specification. Marc Saegesser -Original Message- From: Jason Hunter [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 12:25 AM To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 and getPathInfo So what does the Apache Web Server do for PATH_INFO on a request to http://foo.com/cgi-bin/somecgi/http://extra.com? -jh-
Re: TC4 base dir
Craig R. McClanahan [EMAIL PROTECTED] wrote: The patch below deals with only one of 33 places that the catalina.home system property is referenced in the Catalina source code -- I think we'd want to consider them all :-). Yeah, I know, I was just scratching the itch that I had at the time. ;-) In order to support the idea of one install of Tomcat 4 being used for more than one configuration, we have to decide which subdirectories of $CATALINA_HOME should be made relative to some new location (specified by a command line option or a different environment variable). Here's my proposed breakdown: Sounds good to me! Cheers Geoff
Re: Tomcat 3.2.3 and getPathInfo
Marc Saegesser wrote: Using Apache 1.3.19 here's what I see. Apache does normalize the URL but there is a small difference between what it does and what Tomcat does. Apache does not remove multiple adjacent / characters. For example, http://server/cgi-bin/script/fu/bar -- PATH_INFO = /fu/bar http://server/cgi-bin/script/fu/../bar -- PATH_INFO = /bar http://server/cgi-bin/script/fu//bar -- PATH_INFO = /fu//bar The multiple adjacent / characters don't seem to have any effect on locating resources. For example, http://server///cgi-bin/script/fu/bar works just fine. Unless other comitters feel otherwise, I'll work on changes to the tomcat_32 branch to make path info work as it does with CGI in Apache. Perfect, then my issue (at least) would be solved. -jh-
403 error-page N/W : I guess its just me
Is it just me? Does anybody have tomcat working with a custom 403 page? If not, this seems like a big problem. Any help greatly appreciated... This is really screwing up my login flow. Thanks... ...Casey From Sunday's post... I'm trying to get tomcat to use my 403 forbidden error page. I've had no luck with it so far. My 404 page works fine. I have this problem even if I turn off IE friendly error messages. Using tomcat 4.0b7, JDBCRealm (against mySQL), running on Linux. from web-xml : error-page error-code404/error-code location/security/status/notfound.jsp/location /error-page error-page error-code403/error-code location/security/status/forbidden.jsp/location /error-page from localhost_access_log : (Here's where I hit a forbidden page)... 192.168.1.100 - - [26/Aug/2001:13:14:13 -0600] POST /security/j_security_check HTTP/1.1 302 - 192.168.1.100 - guest [26/Aug/2001:13:14:13 -0600] GET /secured/index.jsp HTTP/ 1.1 403 - (Here's where I hit a page that doesn't exist)... 192.168.1.100 - guest [26/Aug/2001:13:14:30 -0600] GET /asdasdas HTTP/1.1 200 1561 from catalina.out XmlMapper: new null org.apache.catalina.deploy.ErrorPage error-page ErrorPage[er rorCode=0, location=null] XmlMapper: org.apache.catalina.deploy.ErrorPage.setErrorCode( 403) XmlMapper: org.apache.catalina.deploy.ErrorPage.setLocation( /security/status/fo rbidden.jsp) XmlMapper: Calling org.apache.catalina.core.StandardContext.addErrorPage ErrorPa ge[errorCode=403, location=/security/status/forbidden.jsp] XmlMapper: pop error-page org.apache.catalina.deploy.ErrorPage: ErrorPage[errorC ode=403, location=/security/status/forbidden.jsp]
How to force authentication from JSP?
Is there a way to force a user to be authenticates as 'Guest' for example? Running Tomcat 4.0b7.. JDBCRealm... Is it possible for a JSP (not through javascript) to do something along the following lines : jsp:forward page=j_security_check jsp:param name=j_username value=%=p_username% / jsp:param name=j_password value=%=p_password% / /jsp:forward The above doesn't work... 404 error.. which seems logical since j_security_check isn't not really a page. What I really need this for is where I have a 'Create new user account' page. Once the account is created I should have already logged the user in for convenience. I know this has been asked before, but I couldn't find the answer in the archives. Thanks so much for your help! ...Casey
Extending Server.xml configurability (for additional classpaths)
I've seen lots of discussion on the user list desiring the ability to have additional classpaths available to web applications, but not necessarily available to all web apps. Ideally, this could be specified in the web.xml file, but that would require changing a spec, and I can think of some arguments against doing so anyway. But, perhaps it would be possible to add classpath specifications in the Server.xml file. Inside a context tag, you could specify something like this: additional-classpath~someuser/somedir/classesadditional-classpath Multiple occurrences of this would just add to the locations where classes can be found. An alternative for us would be to do something with the class loaders in our own web apps, if that's possible, but I'd like to see Tomcat have the functionality. Can someone give me some pointers to get started adding this particular configuration tag? I'd really appreciate it. BTW, I'm currently working with the 4.0b7 codebase. Thanks!
Follow Up: 403 error-page N/W
I found one more detail... My 403 error page works if the 403 is caused by a filter, but it doesn't work if caused by JDBCRealm. consider the file /secured/junk.html - which is protected by a security constraint which is Form based and tied to JDBCRealm (I'm sure that's bad wording... I hope you get the idea...) - if I login as a user with the correct role to access /secured/junk.html, but I force my filter to cause a 403 for that file, my 403 error page is displayed correctly. - if I login as a user WITHOUT the correct role to access /secures/junk.html, my custom 403 error page is NOT accessed. - if I login as a user WITHOUT the correct role to access /secures/junk.html, and I force my filter to cause a 403 for that file, my custom 403 error page is still NOT accessed. Hopefully I've given some good clues now... Thanks.. ...Casey -Original Message- From: Bragg, Casey [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 8:56 PM To: [EMAIL PROTECTED] Subject: 403 error-page N/W : I guess its just me Is it just me? Does anybody have tomcat working with a custom 403 page? If not, this seems like a big problem. Any help greatly appreciated... This is really screwing up my login flow. Thanks... ...Casey From Sunday's post... I'm trying to get tomcat to use my 403 forbidden error page. I've had no luck with it so far. My 404 page works fine. I have this problem even if I turn off IE friendly error messages. Using tomcat 4.0b7, JDBCRealm (against mySQL), running on Linux. from web-xml : error-page error-code404/error-code location/security/status/notfound.jsp/location /error-page error-page error-code403/error-code location/security/status/forbidden.jsp/location /error-page from localhost_access_log : (Here's where I hit a forbidden page)... 192.168.1.100 - - [26/Aug/2001:13:14:13 -0600] POST /security/j_security_check HTTP/1.1 302 - 192.168.1.100 - guest [26/Aug/2001:13:14:13 -0600] GET /secured/index.jsp HTTP/ 1.1 403 - (Here's where I hit a page that doesn't exist)... 192.168.1.100 - guest [26/Aug/2001:13:14:30 -0600] GET /asdasdas HTTP/1.1 200 1561 from catalina.out XmlMapper: new null org.apache.catalina.deploy.ErrorPage error-page ErrorPage[er rorCode=0, location=null] XmlMapper: org.apache.catalina.deploy.ErrorPage.setErrorCode( 403) XmlMapper: org.apache.catalina.deploy.ErrorPage.setLocation( /security/status/fo rbidden.jsp) XmlMapper: Calling org.apache.catalina.core.StandardContext.addErrorPage ErrorPa ge[errorCode=403, location=/security/status/forbidden.jsp] XmlMapper: pop error-page org.apache.catalina.deploy.ErrorPage: ErrorPage[errorC ode=403, location=/security/status/forbidden.jsp]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/test Header.java HttpRequest.java
costin 01/08/27 22:46:28
Modified:src/share/org/apache/tomcat/util/test Header.java
HttpRequest.java
Log:
Fixes in the test suite. We must send 1.0 requests, since we can't handle
1.1 responses.
Revision ChangesPath
1.5 +4 -0 jakarta-tomcat/src/share/org/apache/tomcat/util/test/Header.java
Index: Header.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/test/Header.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Header.java 2001/02/09 03:48:15 1.4
+++ Header.java 2001/08/28 05:46:28 1.5
@@ -97,6 +97,10 @@
this.value = v;
}
+public String toString() {
+ return value;
+}
+
// Utils
// Code from JSERV !!!
1.4 +2 -1
jakarta-tomcat/src/share/org/apache/tomcat/util/test/HttpRequest.java
Index: HttpRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/test/HttpRequest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- HttpRequest.java 2001/02/20 03:14:12 1.3
+++ HttpRequest.java 2001/08/28 05:46:28 1.4
@@ -320,7 +320,8 @@
if( v!=null) sb.append(v);
}
}
- sb.append( ).append(protocol);
+ // sb.append( ).append(protocol);
+ sb.append( ).append(HTTP/1.0); // only http1.0 for now on request
requestLine=sb.toString();
}
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/test Header.java HttpRequest.java
On Tue, Aug 28, 2001 at 05:46:28AM -, [EMAIL PROTECTED] wrote: costin 01/08/27 22:46:28 Modified:src/share/org/apache/tomcat/util/test Header.java HttpRequest.java Log: Fixes in the test suite. We must send 1.0 requests, since we can't handle 1.1 responses. Out of curiosity, what is the problem with HTTP/1.1 responses? -- justin
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/testHeader.java HttpRequest.java
On Mon, 27 Aug 2001, Justin Erenkrantz wrote: On Tue, Aug 28, 2001 at 05:46:28AM -, [EMAIL PROTECTED] wrote: costin 01/08/27 22:46:28 Modified:src/share/org/apache/tomcat/util/test Header.java HttpRequest.java Log: Fixes in the test suite. We must send 1.0 requests, since we can't handle 1.1 responses. Out of curiosity, what is the problem with HTTP/1.1 responses? -- justin The internal tests were wrong, we did send the requests as HTTP/1.1 when speaking with Apache or IIS. And because they believed it, the response got Chunked encoding - so most tests were either failing or taking forever to execute ( since the reader was still stupid 1.0, waiting for EOF, which happened after the timeout expires ). ( updating to an 1.1 client for the tester is the right fix, but will have to wait for more urgent things ). This has nothing to do with tomcat accepting Chunked encoding on the request - we did few fixes but this hasn't been tested yet, I believe there are few changes in mod_jk we still have to do. Costin
