RE: cvs commit: jakarta-tomcat build.xml
doh, thanks Mike..
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: martes 19 de junio de 2001 2:35
Para: [EMAIL PROTECTED]
Asunto: cvs commit: jakarta-tomcat build.xml
mmanders01/06/18 17:34:38
Modified:.build.xml
Log:
Updated conditionals for commons-dbcp. This will now build
properly even if jakarta-commons isn't available.
Revision ChangesPath
1.135 +29 -30jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.134
retrieving revision 1.135
diff -u -r1.134 -r1.135
--- build.xml 2001/06/17 18:59:39 1.134
+++ build.xml 2001/06/19 00:34:37 1.135
@@ -38,10 +38,16 @@
property name=jakarta-tomcat-jasper
location=${ws}/jakarta-tomcat-jasper /
+
+ property name=jakarta-commons
+location=${ws}/jakarta-commons /
!-- External packages we depend on --
!-- Tomcat depends on:
- - Ant ( latest binary install in jakarta-ant-1.3 )
+ - Ant ( latest 1.3 binary install in jakarta-ant,
peer to jakarta-tomcat )
+ - jakarta-tomcat-connectors ( latest src, peer to
jakarta-tomcat )
+ - jakarta-tomcat-jasper ( latest src, peer to
jakarta-tomcat )
+ - jakarta-commons (optional, latest src, peer to
jakarta-tomcat )
- Jaxp ( optional, the jar files from ant can be
used instead )
- Jsse ( optional )
--
@@ -54,18 +60,6 @@
property name=ant.lib value=${ant.home}/lib/
property name=jsse.lib value=${jsse.home}/lib/
- path id=commons-dbcp
-fileset dir=../jakarta-commons/dbcp
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/pool
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/collections
-include name=**/build/*.jar/
-/fileset
- /path
-
!-- Binaries checked in ( servlet.jar is not likely to change,
the 2.2 spec is final --
property name=servlet22.jar value=bin/servlet22.jar/
@@ -80,8 +74,7 @@
available property=jsse.present
file=${jsse.lib}/jsse.jar/
available property=commons-dbcp.present
-
classname=org.apache.commons.dbcp.DriverManagerConnectionFactory
- classpathref=commons-dbcp/
+
file=${jakarta-commons}/dbcp/dist/commons-dbcp.jar /
available property=jdk12.present
classname=java.security.PrivilegedAction/
available property=jakarta-tomcat-connectors-present
@@ -109,6 +102,7 @@
target name=msg.jtj unless=jakarta-tomcat-jasper-present
fail message=Can't find jakarta-tomcat-jasper
repository, you must check it out before building tomcat /
/target
+
target name=init
depends=detect,msg.jdk12,msg.jsse,msg.jtc,msg.jtj,msg.commons-dbcp
/target
@@ -380,23 +374,26 @@
/target
- target name=commons-prepare if=commons-dbcp.present
-!--
+ target name=commons-prepare depends=prepare
if=commons-dbcp.present
+ !-- Because of way the build.xml files are set up, we
can't call them from
+ inside this file. They need to be run before this
script is executed
+ if you want the PooledJDBCRealm code to be built.
ant
antfile=../jakarta-commons/collections/build.xml target=dist/
ant antfile=../jakarta-commons/pool/build.xml
target=dist/
ant antfile=../jakarta-commons/dbcp/build.xml
target=dist/
---
-copy todir=${tomcat.build}/lib/container flatten=yes
-fileset dir=../jakarta-commons/dbcp
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/pool
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/collections
-include name=**/build/*.jar/
-/fileset
-/copy
+--
+echo message=copying commons jars/
+copy todir=${tomcat.build}/lib/container flatten=yes
+fileset dir=../jakarta-commons/dbcp
+include name=**/dist/*.jar/
+/fileset
+fileset dir=../jakarta-commons/pool
+include name=**/dist/*.jar/
+/fileset
+fileset dir=../jakarta-commons/collections
+include name=**/dist/*.jar/
+/fileset
+/copy
/target
!-- Standard interceptors
== --
@@ -410,8 +407,10 @@
pathelement
location=${tomcat.build}/lib/common/connector_util.jar/
pathelement
3.2.1 vs 3.2.2 versions - Oren
Which is better and what the differences. should I expect problem by moving from 1 to 2.s Oren Deri ___ Oren Deri (E-mail).vcf Oren Deri (E-mail).vcf
[tomcat 4] Jasper Status
Hi, I've been considering embedding Jasper in another app. I've been looking at the code and, while is it is *mucky*, it seems this is probably possible (although I can see it's going to severely try my patience ;-). The thing is, I found this document Proposal for Development of Jasper in Tomcat 4.0 in the jasper/doc/dev directory which seems to indicate that the whole thing is up for a major refactoring. This means that if I spend the time to embed it now, based on the current interfaces, all that work could go up in smoke when it gets refactored. Thus, I'm wondering, how far along is Jasper towards a 4.0 release? Is it going to be refactored before release or are we intending to release it largely as is? Thanks, Geoff -- I hate to advocate weird chemicals, alcohol, violence or insanity to anyone... but they've always worked for me. - Hunter S. Thompson
iPlanet + Tomcat on AIX ??
I have Netscape Web Server (IPlanet) version 3.63. This version of IPlanet doesn't support Java Server Pages, or in other words, there is no Servlet Engine. I need to install some servlet engine on that server in order to run JSPs. Upgrade of the Web server is not possible, because of some other issues. I have tried to install Tomcat to work with Netscape. My problem is that I don't know how to compile NSAPI redirector on AIX platform (AIX 4.2.1.0). Does anyone have binary or makefile for AIX ?? Thank you for your help. Robert
getRemoteUser and non-ansi characters
We have problems with user-ids containing german characters (so-called 'Umlaute'), eg. 'ÖÄÜ' HttpServletRequest.getRemoteUser() returns only the string up-to the first umlaut, eg. for user 'MMÄHHH' we get only 'MM'. Our environment is: Tomcat 3.2.1 + mod_jk + Apache 1.3.19 Authentification is done by apache via mod_auth_mysql, apache-access-log shows correct user-id. IMHO full 8bit charset should be supported by (at least) basic-auth. Any ideas or comments? Thanks, -martin
RE: Missing CGIServlet from nightly build
I'm trying to use the Tomcat nightly's, and found that the org.apache.catalina.servlets.CGIServlet class is missing from the 16th, 17th and 18th June builds, although it (an its related classes) is in the earlier nightlys, As far as I know the build environment for the nightly builds is still using jdk1.2 but CGIServlet requires 1.3 - therefore it is not built. jr
RE: 3.2.1 vs 3.2.2 versions - Oren
Tomcat 3.2.2 is a bug fix release. The release notes in src/doc/readme detail the changes between 3.2.1 and 3.2.2. -Original Message- From: Oren Deri, Nice-Eye [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 3:54 AM To: [EMAIL PROTECTED] Subject: 3.2.1 vs 3.2.2 versions - Oren Which is better and what the differences. should I expect problem by moving from 1 to 2.s Oren Deri ___ Oren Deri (E-mail).vcf
RE: Missing CGIServlet from nightly build
Thanks John. Does this make the nightlies unusable? Is there a plan to move to 1.3? Kevin Jones DevelopMentor www.develop.com -Original Message- From: Reilly, John [mailto:[EMAIL PROTECTED]] Sent: 19 June 2001 13:28 To: '[EMAIL PROTECTED]' Subject: RE: Missing CGIServlet from nightly build I'm trying to use the Tomcat nightly's, and found that the org.apache.catalina.servlets.CGIServlet class is missing from the 16th, 17th and 18th June builds, although it (an its related classes) is in the earlier nightlys, As far as I know the build environment for the nightly builds is still using jdk1.2 but CGIServlet requires 1.3 - therefore it is not built. jr
RE: cvs commit: jakarta-tomcat build.xml
No problem. Big fat hairy lie Of course I would never make
a mistake like that /Big fat hairy lie unless of course I
actually try to modify the code :-)
Mike Anderson
[EMAIL PROTECTED] 06/19/01 01:23AM
doh, thanks Mike..
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: martes 19 de junio de 2001 2:35
Para: [EMAIL PROTECTED]
Asunto: cvs commit: jakarta-tomcat build.xml
mmanders01/06/18 17:34:38
Modified:.build.xml
Log:
Updated conditionals for commons-dbcp. This will now build
properly even if jakarta-commons isn't available.
Revision ChangesPath
1.135 +29 -30jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.134
retrieving revision 1.135
diff -u -r1.134 -r1.135
--- build.xml 2001/06/17 18:59:39 1.134
+++ build.xml 2001/06/19 00:34:37 1.135
@@ -38,10 +38,16 @@
property name=jakarta-tomcat-jasper
location=${ws}/jakarta-tomcat-jasper /
+
+ property name=jakarta-commons
+location=${ws}/jakarta-commons /
!-- External packages we depend on --
!-- Tomcat depends on:
- - Ant ( latest binary install in jakarta-ant-1.3 )
+ - Ant ( latest 1.3 binary install in jakarta-ant,
peer to jakarta-tomcat )
+ - jakarta-tomcat-connectors ( latest src, peer to
jakarta-tomcat )
+ - jakarta-tomcat-jasper ( latest src, peer to
jakarta-tomcat )
+ - jakarta-commons (optional, latest src, peer to
jakarta-tomcat )
- Jaxp ( optional, the jar files from ant can be
used instead )
- Jsse ( optional )
--
@@ -54,18 +60,6 @@
property name=ant.lib value=${ant.home}/lib/
property name=jsse.lib value=${jsse.home}/lib/
- path id=commons-dbcp
-fileset dir=../jakarta-commons/dbcp
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/pool
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/collections
-include name=**/build/*.jar/
-/fileset
- /path
-
!-- Binaries checked in ( servlet.jar is not likely to change,
the 2.2 spec is final --
property name=servlet22.jar value=bin/servlet22.jar/
@@ -80,8 +74,7 @@
available property=jsse.present
file=${jsse.lib}/jsse.jar/
available property=commons-dbcp.present
-
classname=org.apache.commons.dbcp.DriverManagerConnectionFactory
- classpathref=commons-dbcp/
+
file=${jakarta-commons}/dbcp/dist/commons-dbcp.jar /
available property=jdk12.present
classname=java.security.PrivilegedAction/
available property=jakarta-tomcat-connectors-present
@@ -109,6 +102,7 @@
target name=msg.jtj unless=jakarta-tomcat-jasper-present
fail message=Can't find jakarta-tomcat-jasper
repository, you must check it out before building tomcat /
/target
+
target name=init
depends=detect,msg.jdk12,msg.jsse,msg.jtc,msg.jtj,msg.commons-dbcp
/target
@@ -380,23 +374,26 @@
/target
- target name=commons-prepare if=commons-dbcp.present
-!--
+ target name=commons-prepare depends=prepare
if=commons-dbcp.present
+ !-- Because of way the build.xml files are set up, we
can't call them from
+ inside this file. They need to be run before this
script is executed
+ if you want the PooledJDBCRealm code to be built.
ant
antfile=../jakarta-commons/collections/build.xml target=dist/
ant antfile=../jakarta-commons/pool/build.xml
target=dist/
ant antfile=../jakarta-commons/dbcp/build.xml
target=dist/
---
-copy todir=${tomcat.build}/lib/container flatten=yes
-fileset dir=../jakarta-commons/dbcp
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/pool
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/collections
-include name=**/build/*.jar/
-/fileset
-/copy
+--
+echo message=copying commons jars/
+copy todir=${tomcat.build}/lib/container flatten=yes
+fileset dir=../jakarta-commons/dbcp
+include name=**/dist/*.jar/
+/fileset
+fileset dir=../jakarta-commons/pool
+include name=**/dist/*.jar/
+/fileset
+fileset dir=../jakarta-commons/collections
+include name=**/dist/*.jar/
+/fileset
+/copy
/target
!--
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_md5.c
hgomez 01/06/19 08:55:08 Modified:jk/native/common jk_md5.c Log: Bug fixes, bad buffer used ! Revision ChangesPath 1.5 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_md5.c Index: jk_md5.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_md5.c,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- jk_md5.c 2001/06/14 19:43:58 1.4 +++ jk_md5.c 2001/06/19 15:55:04 1.5 @@ -103,7 +103,7 @@ /*** * Description: MD5 encoding wrapper * * Author: Henri Gomez [EMAIL PROTECTED] * - * Version: $Revision: 1.4 $ * + * Version: $Revision: 1.5 $ * ***/ /* @@ -502,7 +502,7 @@ if (org2 != NULL) ap_MD5Update(ctx, org2, strlen(org2)); -ap_MD5Final(dst, ctx); +ap_MD5Final(buf, ctx); return (jk_hextocstr(buf, dst, JK_MD5_DIGESTSIZE)); }
RE: Missing CGIServlet from nightly build
Does this make the nightlies unusable? Only if you want to use tomcat to run cgi scripts. Is there a plan to move to 1.3? I think thats up to Craig. jr Kevin Jones DevelopMentor www.develop.com -Original Message- From: Reilly, John [mailto:[EMAIL PROTECTED]] Sent: 19 June 2001 13:28 To: '[EMAIL PROTECTED]' Subject: RE: Missing CGIServlet from nightly build I'm trying to use the Tomcat nightly's, and found that the org.apache.catalina.servlets.CGIServlet class is missing from the 16th, 17th and 18th June builds, although it (an its related classes) is in the earlier nightlys, As far as I know the build environment for the nightly builds is still using jdk1.2 but CGIServlet requires 1.3 - therefore it is not built. jr
Re: [tomcat-dev] [J-T-C] What about ajp13 refactory in java ?
I've been lurking on this list for awhile and wading through all the code, and this one has been bothering me for awhile. Is there a way we could get a STATUS and README file written for j-t-c? I would do it myself, but honestly I'm at a loss for what would go in there. Hi Aaron, What did you need exactly ? in jtc you'll find 4 subdirs : coyote: a reflexion framework +/- on what is needed to handle HTTP request on the java side. jk: the mod_jk native and java parts. There's build files (build.xml) for both TC 4.0 and TC 3.3. Also the build configure for the native part (jk) is really easy to use (just read jk/native/README.configure). util: a set of API used by Tomcat. There came from Tomcat 3.3 but they were extracted since and put here. webapp: mod_webapp/warp protocol (only ajp14) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_md5.c
On Tue, Jun 19, 2001 at 03:55:09PM -, [EMAIL PROTECTED] wrote: hgomez 01/06/19 08:55:08 Modified:jk/native/common jk_md5.c Log: Bug fixes, bad buffer used ! Revision ChangesPath 1.5 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_md5.c [...] ISTR that j-t-c/jk/native already depends on APR. Instead of duplicating efforts, may I suggest we reuse the md5 functionality of APR (see apr_md5.h)? -aaron
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp14_worker.c
hgomez 01/06/19 09:35:23
Modified:jk/native/common jk_ajp14_worker.c
Log:
Minor fixes.
init info (web_server_name/secret_key) need to be
stored locally (if not there're lost by pool activity)
also correct logon phase (didn't get the cmd byte)
Revision ChangesPath
1.6 +31 -3 jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.c
Index: jk_ajp14_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jk_ajp14_worker.c 2001/06/18 14:15:27 1.5
+++ jk_ajp14_worker.c 2001/06/19 16:35:20 1.6
@@ -58,7 +58,7 @@
/***
* Description: AJP14 next generation Bi-directional protocol. *
* Author: Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.5 $ *
+ * Version: $Revision: 1.6 $ *
***/
#include jk_context.h
@@ -111,10 +111,20 @@
aw = pThis-worker_private;
/* Set Secret Key (used at logon time) */
- aw-login-secret_key = jk_get_worker_secret_key(props, aw-name);
+ aw-login-secret_key = strdup(jk_get_worker_secret_key(props, aw-name));
+ if (aw-login-secret_key == NULL) {
+ jk_log(l, JK_LOG_ERROR, can't malloc secret_key\n);
+ return JK_FALSE;
+ }
+
/* Set WebServerName (used at logon time) */
- aw-login-web_server_name = we-server_name;
+ aw-login-web_server_name = strdup(we-server_name);
+
+ if (aw-login-web_server_name == NULL) {
+ jk_log(l, JK_LOG_ERROR, can't malloc web_server\n);
+ return JK_FALSE;
+ }
if (get_endpoint(pThis, je, l) == JK_FALSE)
return JK_FALSE;
@@ -140,6 +150,17 @@
ajp_worker_t *aw = (*pThis)-worker_private;
if (aw-login) {
+
+ if (aw-login-web_server_name) {
+ free(aw-login-web_server_name);
+ aw-login-web_server_name = NULL;
+ }
+
+ if (aw-login-secret_key) {
+ free(aw-login-secret_key);
+ aw-login-secret_key = NULL;
+ }
+
free(aw-login);
aw-login = NULL;
}
@@ -157,6 +178,8 @@
jk_msg_buf_t*msg,
jk_logger_t *l)
{
+ int cmd;
+
jk_login_service_t *jl = ae-worker-login;
ajp14_marshal_login_init_into_msgb(msg, jl, l);
@@ -169,6 +192,11 @@
jk_log(l, JK_LOG_DEBUG, Into ajp14:logon - wait init reply\n);
jk_b_reset(msg);
+
+ if ((cmd = jk_b_get_byte(msg)) != AJP14_LOGSEED_CMD) {
+ jk_log(l, JK_LOG_ERROR, Into ajp14:logon - awaited command %d,
received command %d\n, AJP14_LOGSEED_CMD, cmd);
+ return JK_FALSE;
+ }
if (ajp_connection_tcp_get_message(ae, msg, l) != JK_TRUE)
return JK_FALSE;
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_md5 .c
ISTR that j-t-c/jk/native already depends on APR. Instead of duplicating efforts, may I suggest we reuse the md5 functionality of APR (see apr_md5.h)? mod_jk didn't use APR. webapp use APR. It's not a duplicate effort since I use allready code present in Apache (if linked with Apache) or code from Apache (if I'm using IIS/iPlanet/Domino). - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [tomcat-dev] [J-T-C] What about ajp13 refactory in java ?
On Tue, Jun 19, 2001 at 06:16:15PM +0200, Gomez Henri wrote: I've been lurking on this list for awhile and wading through all the code, and this one has been bothering me for awhile. Is there a way we could get a STATUS and README file written for j-t-c? I would do it myself, but honestly I'm at a loss for what would go in there. Hi Aaron, What did you need exactly ? in jtc you'll find 4 subdirs : coyote: a reflexion framework +/- on what is needed to handle HTTP request on the java side. jk: the mod_jk native and java parts. There's build files (build.xml) for both TC 4.0 and TC 3.3. Also the build configure for the native part (jk) is really easy to use (just read jk/native/README.configure). util: a set of API used by Tomcat. There came from Tomcat 3.3 but they were extracted since and put here. webapp: mod_webapp/warp protocol (only ajp14) Thank you for the details, they were very useful. I have put them together with some other things I found scattered around in code and various other places and compiled a README.txt that someone may wish to commit. It needs some work in places where I am unfamiliar, but it gives us a good place to work from. -aaron Apache Tomcat Connectors Introduction This CVS module contains the code for the Tomcat Connectors. It currently contains two distinct connectors: jk and webapp. This module also contains utility classes that are used by the connectors as well as Tomcat itself. The components are: Connectors -- * jk: The native and java parts of the ajp12/ajp13 [is this correct?] connector. Both Tomcat 4.0 and Tomcat 3.3 are supported. * webapp: The native and java parts of the ajp14 connector, now known as mod_webapp and warp respectively. Utilities - * coyote: A reflexion framework +/- of what is needed to handle HTTP requests in Tomcat (in java). These utilities are not intended for user code. They are used internally by Tomcat. * util: A set of APIs used by Tomcat. Note: these came from Tomcat 3.3 but they were extracted for general use here. Building Apache Tomcat Connectors = It is not necessary to build and install both connectors. [ Talk about tradeoffs between jk and webapp. Perhaps reference some other documentation that already does this. ] * If you wish to build the 'jk' connector, see the documentation in jk/README.txt for the java implementation, and jk/native/README.configure for help with the native Apache module. * If you wish to build the 'webapp' connector, see the documentation in webapp/README.txt. Installing Apache Tomcat Connectors === [ This could use some serious work. There are a few factors that make this more complicated than it should be, namely using 'jk' vs 'webapp', and then how to install and configure for both TC 3.3 and TC 4.0. ]
Re: [tomcat-dev] [J-T-C] What about ajp13 refactory in java ?
On Tue, Jun 19, 2001 at 10:06:07AM -0700, Aaron Bannert wrote: Apache Tomcat Connectors Introduction This CVS module contains the code for the Tomcat Connectors. It currently contains two distinct connectors: jk and webapp. This module also contains utility classes that are used by the connectors as well as Tomcat itself. The components are: Connectors -- * jk: The native and java parts of the ajp12/ajp13 [is this correct?] connector. Both Tomcat 4.0 and Tomcat 3.3 are supported. * webapp: The native and java parts of the ajp14 connector, now known as mod_webapp and warp respectively. Whoops, that's obviously not correct. warp is the protocol (right?), mod_webapp is the webserver module (Apache et al), and do we have a name for the java part? How about this instead: * webapp: The native and java parts of the connector that implements the warp protocol (ajp14). This includes mod_webapp for integration with a frontend webserver (like Apache). -aaron
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappLoader.java
remm01/06/19 10:38:02
Modified:catalina/src/share/org/apache/catalina/loader
WebappLoader.java
Log:
- Add a permission for the work dir.
Revision ChangesPath
1.2 +12 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java
Index: WebappLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- WebappLoader.java 2001/06/19 02:12:49 1.1
+++ WebappLoader.java 2001/06/19 17:38:00 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
1.1 2001/06/19 02:12:49 remm Exp $
- * $Revision: 1.1 $
- * $Date: 2001/06/19 02:12:49 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
1.2 2001/06/19 17:38:00 remm Exp $
+ * $Revision: 1.2 $
+ * $Date: 2001/06/19 17:38:00 $
*
*
*
@@ -119,7 +119,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.1 $ $Date: 2001/06/19 02:12:49 $
+ * @version $Revision: 1.2 $ $Date: 2001/06/19 17:38:00 $
*/
public class WebappLoader
@@ -643,6 +643,14 @@
((WebappClassLoader)classLoader).setPermissions
(rootUrl);
}
+File workDir =
+(File) servletContext.getAttribute
+(Globals.WORK_DIR_ATTR);
+if (workDir != null) {
+File libDir = new File(workDir, WEB-INF/lib/);
+((WebappClassLoader)classLoader).setPermissions
+(libDir.getAbsolutePath());
+}
} catch (MalformedURLException e) {
}
}
problem of installation of tomcat
Dear Sir/Madam, I have met a problem installing tomcat, such a problem has not been raised yet. h I have already setup system path and classpath for jdk in C:\autoexec.bat as follow: set path=C:\jdk1.2\bin set classpath=.;C:\jdk1.2\lib\tools.jar It works well with normal java example test. h My tomcat.bat has been changed as follow: @echo off rem A batch file to start/stop tomcat server. rem This batch file written and tested under Windows NT rem Improvements to this file are welcome rem Guess TOMCAT_HOME if it is not present set Java_home=c:\jdk1.2 if not %TOMCAT_HOME% == goto gothome .. h The error message I get when startup tomcat server is followed: Java window: java.lang.ClassNotFoundException: org/apache/tomcat/service/http/HttpConnectionHandler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Compiled Code) at org.apache.tomcat.service.SimpleTcpConnector.setProperty(SimpleTcpConnector.java:180) .. Finished startup: Starting tomcat in new window Using classpath: ..\classes;..\lib\webserver.jar;..\lib\jasper.jar;..\lib\xml.jar;..\lib\servlet.jar;.; C:\jdk1.2\lib\tools.jar h I have checked that org/apache/tomcat/service/http/HttpConnectionHandler.java exists in C:\Tomcat\Binary\src\org folder Can you help me out ? thanks Jack Miao _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: AW: Serious problem with Tomcat JVM running out of memory
Thomas Bezdicek wrote: Hi, hmm, i just quickly looked at the code, and my first (and possible not true, but first and only) idea was, what about the class DocumentCache ??? is it freeing the memory, do you use explicit System.gc() there from time to time (maybe use a timer-task)? I've set the size of the cache to (1) because there is only one 1.5MB XML file being transformed by the servlet. The file is updated infrequently and the cache is updated accordingly. I haven't done explicit System.gc(); I was assuming the DocumentCache object was getting replaced in place. We are using it quite the same technics (except translets, just because it will need a lot of testing before implementing) and we had also a memory problem which was caused by a quite unclean behavior of a cache-class. Here's more data on the pattern of memory usuage. I got the heap size from the servlet by doing rt.totalMemory()-rt.freeMemory(). Here's some data ending with the servlet being accessed for the 388th time. The change in memory is enourmous. in search servlet Heap size: 127433632 in search servlet Heap size: 130209136 in search servlet Heap size: 101303624 in search servlet Heap size: 107158080 in search servlet Heap size: 112277496 in search servlet Heap size: 117602496 in search servlet Heap size: 123471064 in search servlet Heap size: 115313744 in search servlet Heap size: 123947424 in search servlet Heap size: 115989448 in search servlet Heap size: 123113392 in search servlet Heap size: 128074312 in search servlet Heap size: 127979096 in search servlet Heap size: 132658448 in search servlet Heap size: 108687936 in search servlet Heap size: 132478184 in search servlet Heap size: 110560664 in search servlet Heap size: 121183272 in search servlet Heap size: 126615216 The changes in the heap sizes each time the servlet is run are enormous. What could be causing this? Tom hope it helps, tom -Ursprungliche Nachricht- Von: Tom Amiro [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 18. Juni 2001 23:06 An: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Betreff: Serious problem with Tomcat JVM running out of memory Hi, Yes I've tried that and it did not seem to help. I'm using the XSLTC processor from Sun that compiles XSL stylesheets into translets (java byte code). Tom Hi, have you tried to set java memory parameters in tomcat.sh at TOMCAT_OPTS (e.g. -Xmx256m -Xms128m). We are running a quite large application without problems after setting these parameters. regards, tom btw: what xslt-processor do you use, cause we are experiencing an enormous performance leak using xalan compared to ms-xml (40 sec to 3 msec) xalan on solaris 8 440Mhz, ms-xml on w2k P3-850. -Ursprungliche Nachricht- Von: Tom Amiro [mailto:[EMAIL PROTECTED]] Gesendet: Sonntag, 17. Juni 2001 22:33 An: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Betreff: serious problem with Tomcat JVM running out of memory Hello, I am at the end of my rope. A couple of weeks ago, I tried to deploy a Java servlet that gets about 300-400 hits a day using Tomcat in stand-alone mode and Tomcat keeps running out of memory and crashing. The servlet does an XSLT transformation on an XML file about 1.5MB large. I was planning on integrating Tomcat into the main Apache server after finishing the development, but haven't been able to get that far. I've tried a lot of things and collected a lot of data, but have not been able to prevent the Tomcat heap from growing and growing, until TC crashes. The terminal window shows lots of out-of-memory messages coming from the servlet before the crash -- so I know it is servlet. Tomcat is only running the servlet (that gets 300-400 hits a day) and some JSP data entry tools used to maintain the XML file. I've found that even when we refrain from using the data entry tools, and just let the servlet run the problem still happens. The JSPs add to it, but even with them out of the picture, the situation is untenable. I've spent more than 6 months developing this application -- an event calendar -- and was forced to put it into production before it was tested. But Java servlets and JSPs are supposed to make it easier to create web applications, right? At first, I thought I must be something wrong. So I did every thing I could to plug memory leaks in my code. The thing that really perplexes me is that the heap -- (rt.totalMemory()-rt.freeMemory() --will hover around 75M for quite a while and then seem to jump in leaps and bounds -- sometimes 5-10MB at a time. In the very beginning, I sent mail to the users group and have implemented suggestions, like increasing the file descriptors to 1024, minimizing sessions (session.setMaxInactiveInterval(120), starting the
header handling in WARP
Hello everyone,
I have a question on how the Warp handler handles headers
coming back from a request.
In pr_warp.c, warp_handler,the following is written:
/* Check if we got an HDR packet (header) */
if (i-type==TYP_REQUEST_HDR) {
char *nam=p_rstring(i);
char *val=p_rstring(i);
wa_debug(WA_MARK,Header \%s\: \%s\,nam,val);
if (strcasecmp(Connection,nam)!=0) {
wa_rsetheader(r,nam,val);
}
if (strcasecmp(Content-Type,nam)==0) {
wa_rsetctype(r,val);
}
}
I notice that the headers for Connection and Content-Type are set in the
request's structure. However I couldn't see how any other headers will
get sent back to the client.
I'm sure I'm missing something!
Can someone (perhap Pier?) enlighten me as I'm getting a wee bit fed up with
my own density on this one ;-)
thanks,
Thom
Jasper performance query (circa 3.1 code)
I'm using Jasper in Weblogic from tomcat 3.1 (ish, we've patched a couple of things too). While profiling some of my JSP's, I see the JspRuntimeLibrary.introspectHelper consuming between 40-70% of the time, and a large %age of the object creation. Drilling down, most of the time is the line (which is still in Jasper34) java.beans.BeanInfo info = java.beans.Introspector.getBeanInfo(bean.getClass()); Which in turn is slow due to the construction of the BeanInfo (concrete class: GenericBeanInfo) So my question is: why isn't this cached? Or rather, if I were to cache this object, what are my problems? Those I see so far are: 1) If it's cached, where is the cache held? (a) If within JspRuntimeLibrary, I must synchronize the Map -- may cause a bottleneck between threads, since this is called hundreds of times per JSP. (b)If not here, then perhaps on the thread -- we're using our own subclass at this point (most of the time) so I could store it as a thread local there, or change the generation to pass in a storage object / cache. 2) Will this prevent class reloading from GC'ing the old classes, unless the map is released? For our app, reloading is only a dev feature so not too worried about this. 3) Am I reading my profiler wrong and this shouldn't be a bottleneck? I don't think we can wait long enough for the Jasper refactoring to happen, so am looking for smallish changes currently. Ken. This e-mail message is CONFIDENTIAL and may contain legally privileged information. If you are not the intended recipient you should not read, copy, distribute, disclose or otherwise use the information in this e-mail. Please also telephone or fax us immediately and delete the message from your system. E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or the consequences thereof.
Compiling mod_jk comment fix for Solaris cc
I recently compiled the latest version of mod_jk (jakarta-tomcat-3.2.2-src) using the Sun Workshop v6 cc compiler on Solaris 8. It found three errors in the mod_jk source code having to do with commenting. Turns out this version of cc does not like the double slash comment. To use cc, you must change the // ... comments to /* ... */ comments in the following files/lines: ./src/native/jk/jk_sockbuf.c - line 227 ./src/native/jk/jk_util.c - lines 217 and 233 I also used the -lposix4 option as stated in the documentation just in case. You still get warnings when you compile, but the resulting mod_jk.so works with Tomcat 3.2.2 and Apache 1.3.20. Would someone on the development team please make these minor changes in the mod_jk source for us Solaris users? Thank you.
Re: [tomcat-dev] [J-T-C] What about ajp13 refactory in java ?
On Tue, 19 Jun 2001, Aaron Bannert wrote: Connectors -- * jk: The native and java parts of the ajp12/ajp13 [is this correct?] connector. Both Tomcat 4.0 and Tomcat 3.3 are supported. * webapp: The native and java parts of the ajp14 connector, now known as mod_webapp and warp respectively. ??? AFAIK webapp has nothing to do with ajp14 - it's a different module and protocol. Ajp14 is the successor of ajp13 in mod_jk space, and it'll integrate some of the features of warp ( autoconf of webapps ). * coyote: A reflexion framework +/- of what is needed to handle HTTP requests in Tomcat (in java). These utilities are not intended for user code. They are used internally by Tomcat. This is the first step in the java-side refactoring, togheter with the current implementations of Ajp13 for 4.0 and 3.3 ( which are curently in distinct files, conditionally compiled ). In time both will merge ( maybe as part of a common ajp14 ), probably using coyote. Costin
Re: Missing CGIServlet from nightly build
The nightly uses 1.3 since last week. I changed the build script yesterday so that it automatically checks for which jvm it uses and compiles the CGI code if it uses 1.3. So it should have compiled the cgi files from last night's build. However, it shouldn't give you an exception only because it excludes compiling those cgi dependent files. Which exception do you get? Amy - Original Message - From: Kevin Jones [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 19, 2001 9:43 AM Subject: RE: Missing CGIServlet from nightly build Does this make the nightlies unusable? Only if you want to use tomcat to run cgi scripts. OK. I get an exception and I'm surprised that the exception doesn't stop the application loading, but I can live with that :-) Kevin Jones DevelopMentor www.develop.com -Original Message- From: Reilly, John [mailto:[EMAIL PROTECTED]] Sent: 19 June 2001 17:08 To: '[EMAIL PROTECTED]' Subject: RE: Missing CGIServlet from nightly build Does this make the nightlies unusable? Only if you want to use tomcat to run cgi scripts. Is there a plan to move to 1.3? I think thats up to Craig. jr Kevin Jones DevelopMentor www.develop.com -Original Message- From: Reilly, John [mailto:[EMAIL PROTECTED]] Sent: 19 June 2001 13:28 To: '[EMAIL PROTECTED]' Subject: RE: Missing CGIServlet from nightly build I'm trying to use the Tomcat nightly's, and found that the org.apache.catalina.servlets.CGIServlet class is missing from the 16th, 17th and 18th June builds, although it (an its related classes) is in the earlier nightlys, As far as I know the build environment for the nightly builds is still using jdk1.2 but CGIServlet requires 1.3 - therefore it is not built. jr
RE: Missing CGIServlet from nightly build
The full exception was a ClassNotFoundException. From the 18th June nightly CGIServlet.class is definitely not in catalina.jar I've just downloaded the latest nightly and it's fine. Thank you, Kevin Jones DevelopMentor www.develop.com
Redirect to empty
Hi, In jserv when you did a resp.sendRedirect(); you get an empty page. Since then this has changed and it is very annoying behaviour, because this redirect redirects to itself without any parameters. Since our urls are (thank god!) not hardcoded, but freely configurable, it could be that people make a mistake, which can lead to a horrible hit on your server (that servlet redirects when certain conditions are met and those conditions are allways met when no parameters are provided, so you get an infinite loop in redirecting. I know it's best to solve that programmatically, but it's easy to make a mistake in a complicated system. I would prefer the page to turn up blank when a redirect to is done (or an exception). Is this behaviour supposed to act like that, or is it something that may be fixed ? If you say fix it : I'm doing it asap ;-)) (saves a lot of time in debugging..) Mvgr, Martin
Re: [t4] yet another classloader muckup...
Quoting Jon Stevens [EMAIL PROTECTED]: I haven't tried a recent snapshot of Catalina (after remy's recent classloader changes)...but, this is something that is being reported on the Turbine mailing list as well as I have seen it on my own... What happens is that when the classloader reloads, for some reason, Village is not found in the WEB-INF/lib directory (even though it is there) and we get a NCDFE... This problem would have been very easy to fix anyway (I got a report on it two days ago, and I already had fixed it for the thread which checks for classes modification), but ... Craig/Remy, think you can help? Will Remy's recent changes fix this problem? Yes, the problem will be fixed. Remy Without doing anything else, approximately 5 to 20 seconds later the following exception appears in the Catalina console window: java.lang.NoClassDefFoundError: com/workingdogs/village/KeyDef at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1631) at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1578) at org.apache.turbine.om.security.peer.TurbineUserPeer.doUpdate(TurbineUserPeer .java:463) at org.apache.turbine.services.security.db.DBUserManager.store(DBUserManager.ja va:272) at org.apache.turbine.services.security.BaseSecurityService.saveUser(BaseSecuri tyService.java:379) at org.apache.turbine.services.security.TurbineSecurity.saveUser(TurbineSecurit y.java:261) at org.apache.turbine.om.security.TurbineUser.valueUnbound(TurbineUser.java:649 ) at org.apache.catalina.session.StandardSession.removeAttribute(StandardSession. java:953) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:551) at org.apache.catalina.session.StandardManager.processExpires(StandardManager.j ava:744) at org.apache.catalina.session.StandardManager.run(StandardManager.java:815) at java.lang.Thread.run(Thread.java:484) This class appears to exist in village-1.5.1.jar so I don't see why the exception is occurring or if it relates to my screen transition problem.
'localhost' v '127.0.0.1' in workers.properties
Has anyone else found that NT/2000 can't resolve 'localhost' in a line like worker.ajp13.host=localhost in conf/workers.properties? I had the problem when I was developing the domino connector and someone else has just reported the same problem to me. On the machine where I had the problem nslookup localhost was fine, and the problem persisted whether or not there was a localhost entry in hosts. I haven't tried other hostnames there. -- Andy Armstrong, Tagish
Re: Some clean up of the jakarta-tomcat tree for Tomcat 3.3
+1 (cleaning is good -- I love deleting stuff) Mike Anderson wrote: +1 Mike Anderson [EMAIL PROTECTED] 06/19/01 03:49PM Hi, Does anyone have any objection to my deleting the following folders from the jakarta-tomcat head: proposals/jasper34 proposals/tomcat-4.0 proposals/web-connector src/jasper34 They all have projects elsewhere and, as Henri noted earlier, would make a noticeable reduction in the size of the source file. Cheers, Larry -- Andy Armstrong, Tagish
[Fwd: RE: 'localhost' v '127.0.0.1' in workers.properties]
This just in from Jay. I think he's probably right that it's 2000 only
-- I had thought I had the problem on NT too, but I can't now remember
the chronology of seeing the problem on a particular machine and
replacing NT with 2000 on the same machine -- it may be that I'd already
upgraded it to 2k when I saw the problem.
Original Message
Subject: RE: 'localhost' v '127.0.0.1' in workers.properties
Date: Tue, 19 Jun 2001 16:48:07 -0500
From: Burgess, Jay [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
I've got problems sending to the newsgroup, but I thought I'd reply
personally, in case it helps.
Are you definitely having problems with both 2000 and NT, or maybe just
2000? I found a bug with InetAddress.getLocalHost() on WIN2000, and
maybe it's related to the way Tomcat works internally. The code below
shows it best:
try {
localHost = InetAddress.getLocalHost();
//
// Because of a bug on WIN 2000, getLocalHost() may
// return 0.0.0.0, for this machine. Clear localHost
// flag so we can try again below.
//
if (localHost.getHostAddress().equals(0.0.0.0)) {
localHost = null;
}
}
catch (UnknownHostException e) {
}
//
// If we haven't succeeded yet, try the loopback address.
//
if (localHost == null) {
try {
localHost = InetAddress.getByName(127.0.0.1);
}
catch (UnknownHostException e2){
throw (new Exception(Unable to resolve local host name.));
}
}
Jay
-- Jay Burgess
Delano Technology Corporation
mailto:[EMAIL PROTECTED]
(913) 438-9444 x154
-Original Message-
From: Andy Armstrong [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 19, 2001 4:39 PM
To: Tomcat Dev
Subject: 'localhost' v '127.0.0.1' in workers.properties
Has anyone else found that NT/2000 can't resolve 'localhost' in a line
like
worker.ajp13.host=localhost
in conf/workers.properties?
I had the problem when I was developing the domino connector and someone
else has just reported the same problem to me. On the machine where I
had the problem
nslookup localhost
was fine, and the problem persisted whether or not there was a localhost
entry in hosts. I haven't tried other hostnames there.
--
Andy Armstrong, Tagish
Re: Some clean up of the jakarta-tomcat tree for Tomcat 3.3
I heard that. Get rid of it. -casey Andy Armstrong wrote: +1 (cleaning is good -- I love deleting stuff) Mike Anderson wrote: +1 Mike Anderson [EMAIL PROTECTED] 06/19/01 03:49PM Hi, Does anyone have any objection to my deleting the following folders from the jakarta-tomcat head: proposals/jasper34 proposals/tomcat-4.0 proposals/web-connector src/jasper34 They all have projects elsewhere and, as Henri noted earlier, would make a noticeable reduction in the size of the source file. Cheers, Larry -- Andy Armstrong, Tagish
RE: Some clean up of the jakarta-tomcat tree for Tomcat 3.3
+1 Saludos , Ignacio J. Ortega -Mensaje original- De: Larry Isaacs [mailto:[EMAIL PROTECTED]] Enviado el: martes 19 de junio de 2001 23:49 Para: '[EMAIL PROTECTED]' Asunto: Some clean up of the jakarta-tomcat tree for Tomcat 3.3 Hi, Does anyone have any objection to my deleting the following folders from the jakarta-tomcat head: proposals/jasper34 proposals/tomcat-4.0 proposals/web-connector src/jasper34 They all have projects elsewhere and, as Henri noted earlier, would make a noticeable reduction in the size of the source file. Cheers, Larry
[t4] weird build error...
With Jikes... build-main: [javac] Compiling 280 source files to /Users/jon/checkout/jakarta-tomcat-4.0 /catalina/build/classes [javac] /Users/jon/checkout/jakarta-tomcat-4.0/catalina/src/share/org/apache /catalina/loader/WebappLoader.java:806: class org.apache.catalina.loader.Context Notifier is defined in StandardLoader.java. Because it is used outside of its so urce file, it should be defined in a file called ContextNotifier.java. [javac] ContextNotifier notifier = new ContextNotifier((Context) contain er); [javac] ^ [javac] Note: 13 files use or override a deprecated API. Recompile with -d eprecation for details. [javac] 2 warnings -jon
RE: Missing CGIServlet from nightly build
On Tue, 19 Jun 2001, Kevin Jones wrote: Thanks John. Does this make the nightlies unusable? Is there a plan to move to 1.3? I thought that I had already :-( ... I will check as soon as I get home from a trip (Thursday). The nightlies are built on my home server, and it's behind a firewall. Kevin Jones DevelopMentor www.develop.com Craig -Original Message- From: Reilly, John [mailto:[EMAIL PROTECTED]] Sent: 19 June 2001 13:28 To: '[EMAIL PROTECTED]' Subject: RE: Missing CGIServlet from nightly build I'm trying to use the Tomcat nightly's, and found that the org.apache.catalina.servlets.CGIServlet class is missing from the 16th, 17th and 18th June builds, although it (an its related classes) is in the earlier nightlys, As far as I know the build environment for the nightly builds is still using jdk1.2 but CGIServlet requires 1.3 - therefore it is not built. jr
cvs commit: jakarta-tomcat/src/native/apache1.3 mod_jk.c
mmanders01/06/19 15:45:01
Modified:src/native/apache1.3 Tag: tomcat_32 mod_jk.c
Log:
Added a check for the workers.properties file to allow Apache to come down clean if
the path/file doesn't exist.
Fixed memory leaks when using VirtualHost sections in Apache.
Revision ChangesPath
No revision
No revision
1.7.2.5 +22 -7 jakarta-tomcat/src/native/apache1.3/Attic/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/apache1.3/Attic/mod_jk.c,v
retrieving revision 1.7.2.4
retrieving revision 1.7.2.5
diff -u -r1.7.2.4 -r1.7.2.5
--- mod_jk.c 2001/05/19 04:23:41 1.7.2.4
+++ mod_jk.c 2001/06/19 22:44:57 1.7.2.5
@@ -483,8 +483,11 @@
server_rec *s = cmd-server;
jk_server_conf_t *conf =
(jk_server_conf_t *)ap_get_module_config(s-module_config, jk_module);
+struct stat statbuf;
conf-worker_file = worker_file;
+if (stat(worker_file, statbuf) == -1)
+return Can't find the workers file specified;
return NULL;
}
@@ -904,14 +907,26 @@
static void exit_handler (server_rec *s, ap_pool *p)
{
- jk_server_conf_t *conf =
- (jk_server_conf_t *)ap_get_module_config(s-module_config, jk_module);
+server_rec *tmp = s;
- wc_close(conf-log);
- uri_worker_map_free((conf-uw_map), conf-log);
- map_free((conf-uri_to_context));
- if (conf-log)
- jk_close_file_logger((conf-log));
+/* loop through all available servers to clean up all configuration
+ * records we've created
+ */
+while (NULL != tmp)
+{
+jk_server_conf_t *conf =
+(jk_server_conf_t *)ap_get_module_config(tmp-module_config,
jk_module);
+
+if (NULL != conf)
+{
+wc_close(conf-log);
+uri_worker_map_free((conf-uw_map), conf-log);
+map_free((conf-uri_to_context));
+if (conf-log)
+jk_close_file_logger((conf-log));
+}
+tmp = tmp-next;
+}
}
static const handler_rec jk_handlers[] =
Re: [t4] weird build error...
With Jikes... build-main: [javac] Compiling 280 source files to /Users/jon/checkout/jakarta-tomcat-4.0 /catalina/build/classes [javac] /Users/jon/checkout/jakarta-tomcat-4.0/catalina/src/share/org/apache /catalina/loader/WebappLoader.java:806: class org.apache.catalina.loader.Context Notifier is defined in StandardLoader.java. Because it is used outside of its so urce file, it should be defined in a file called ContextNotifier.java. [javac] ContextNotifier notifier = new ContextNotifier((Context) contain er); [javac] ^ [javac] Note: 13 files use or override a deprecated API. Recompile with -d eprecation for details. [javac] 2 warnings It builds ok with javac, though. I'll try to fix it. Remy
cvs commit: jakarta-tomcat/src/native/jk jk_jni_worker.c
mmanders01/06/19 15:57:25
Modified:src/native/jk Tag: tomcat_32 jk_jni_worker.c
Log:
Even though Apache is documented as only calling the module initializer function
(jk_init) once, it actually calls it multiple times, at least on Windows. A couple of
times it is called on the same process which causes open_jvm to fail on the second
pass because the jvm was alread instantiated on the first pass. In open_jvm2, we can
catch this and try to get the instatiated jvm and attach to it, preventing a hard
failure (a call to jk_error_exit()) which also shuts down the webserver.
Revision ChangesPath
No revision
No revision
1.7.2.3 +28 -7 jakarta-tomcat/src/native/jk/Attic/jk_jni_worker.c
Index: jk_jni_worker.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/jk/Attic/jk_jni_worker.c,v
retrieving revision 1.7.2.2
retrieving revision 1.7.2.3
diff -u -r1.7.2.2 -r1.7.2.3
--- jk_jni_worker.c 2000/09/13 23:06:25 1.7.2.2
+++ jk_jni_worker.c 2001/06/19 22:57:23 1.7.2.3
@@ -57,7 +57,7 @@
* Description: In process JNI worker *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Based on: *
- * Version: $Revision: 1.7.2.2 $ *
+ * Version: $Revision: 1.7.2.3 $ *
***/
#if !defined(WIN32) !defined(NETWARE)
@@ -89,6 +89,7 @@
jint (JNICALL *jni_get_default_java_vm_init_args)(void *) = NULL;
jint (JNICALL *jni_create_java_vm)(JavaVM **, JNIEnv **, void *) = NULL;
+jint (JNICALL *jni_get_created_java_vms)(JavaVM **, int, int *) = NULL;
#define JAVA_BRIDGE_CLASS_NAME (org/apache/tomcat/service/JNIEndpoint)
@@ -688,10 +689,13 @@
(FARPROC)jni_create_java_vm =
GetProcAddress(hInst, JNI_CreateJavaVM);
+(FARPROC)jni_get_created_java_vms =
+GetProcAddress(hInst, JNI_GetCreatedJavaVMs);
+
(FARPROC)jni_get_default_java_vm_init_args =
GetProcAddress(hInst, JNI_GetDefaultJavaVMInitArgs);
-if(jni_create_java_vm jni_get_default_java_vm_init_args) {
+if(jni_create_java_vm jni_get_default_java_vm_init_args
jni_get_created_java_vms) {
return JK_TRUE;
}
@@ -711,9 +715,10 @@
}
if (0 != javaNlmHandle) {
jni_create_java_vm = ImportSymbol(GetNLMHandle(), JNI_CreateJavaVM);
+jni_get_created_java_vms = ImportSymbol(GetNLMHandle(),
JNI_GetCreatedJavaVMs);
jni_get_default_java_vm_init_args = ImportSymbol(GetNLMHandle(),
JNI_GetDefaultJavaVMInitArgs);
}
-if(jni_create_java_vm jni_get_default_java_vm_init_args) {
+if(jni_create_java_vm jni_get_default_java_vm_init_args
jni_get_created_java_vms) {
return JK_TRUE;
}
#else
@@ -729,9 +734,10 @@
dlerror());
} else {
jni_create_java_vm = dlsym(handle, JNI_CreateJavaVM);
+jni_get_created_java_vms = dlsym(handle, JNI_GetCreatedJavaVMs);
jni_get_default_java_vm_init_args = dlsym(handle,
JNI_GetDefaultJavaVMInitArgs);
-if(jni_create_java_vm jni_get_default_java_vm_init_args) {
+if(jni_create_java_vm jni_get_default_java_vm_init_args
jni_get_created_java_vms) {
jk_log(l, JK_LOG_DEBUG,
In load_jvm_dll, symbols resolved, done\n);
return JK_TRUE;
@@ -909,7 +915,7 @@
int optn = 0, err;
char* tmp;
-*env = NULL;
+*env = penv = NULL;
jk_log(l, JK_LOG_DEBUG,
Into open_jvm2\n);
@@ -970,10 +976,25 @@
}
jk_log(l, JK_LOG_DEBUG, In open_jvm2, about to create JVM...\n);
+
+err=jni_create_java_vm((p-jvm), penv, vm_args);
+
+if (JNI_EEXIST == err)
+{
+int vmCount;
+ jk_log(l, JK_LOG_DEBUG, JVM alread instantiated. Trying to attach
instead.\n);
+
+jni_get_created_java_vms((p-jvm), 1, vmCount);
+if (NULL != p-jvm)
+penv = attach_to_jvm(p, l);
-if((err=jni_create_java_vm((p-jvm), penv, vm_args)) != 0) {
+if (NULL != penv)
+err = 0;
+}
+
+if(err != 0) {
jk_log(l, JK_LOG_EMERG, Fail- could not create JVM, code: %d \n, err);
-return JK_FALSE;
+return JK_FALSE;
}
jk_log(l, JK_LOG_DEBUG, In open_jvm2, JVM created, done\n);
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappLoader.java
remm01/06/19 16:03:33
Modified:catalina/src/share/org/apache/catalina/loader
WebappLoader.java
Log:
- Use the local context notifier. Should fix build failure with Jikes reported
by Jon.
Revision ChangesPath
1.3 +6 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java
Index: WebappLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- WebappLoader.java 2001/06/19 17:38:00 1.2
+++ WebappLoader.java 2001/06/19 23:03:30 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
1.2 2001/06/19 17:38:00 remm Exp $
- * $Revision: 1.2 $
- * $Date: 2001/06/19 17:38:00 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
1.3 2001/06/19 23:03:30 remm Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/06/19 23:03:30 $
*
*
*
@@ -119,7 +119,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.2 $ $Date: 2001/06/19 17:38:00 $
+ * @version $Revision: 1.3 $ $Date: 2001/06/19 23:03:30 $
*/
public class WebappLoader
@@ -803,7 +803,8 @@
*/
private void notifyContext() {
- ContextNotifier notifier = new ContextNotifier((Context) container);
+ WebappContextNotifier notifier =
+new WebappContextNotifier((Context) container);
(new Thread(notifier)).start();
}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ServletWrapper.java
mmanders01/06/19 16:04:39
Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
ServletWrapper.java
Log:
Syncronized around call to loader.shouldReload to prevent getting the loader in an
invalid state. Fixes Bug # 1628.
Revision ChangesPath
No revision
No revision
1.60.2.6 +38 -32
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/ServletWrapper.java
Index: ServletWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/ServletWrapper.java,v
retrieving revision 1.60.2.5
retrieving revision 1.60.2.6
diff -u -r1.60.2.5 -r1.60.2.6
--- ServletWrapper.java 2001/01/12 04:39:05 1.60.2.5
+++ ServletWrapper.java 2001/06/19 23:04:38 1.60.2.6
@@ -422,38 +422,44 @@
if( isReloadable ) {// ! invoker.equals( getServletName())) {
ServletLoader loader=context.getServletLoader();
if( loader!=null) {
- // XXX no need to check after we remove the old loader
- if( loader.shouldReload() ) {
- // workaround for destroy
- try {
- destroy();
- } catch(Exception ex ) {
- context.log( Error in destroy , ex );
- }
- initialized=false;
- loader.reload();
-
- ContextManager cm=context.getContextManager();
- cm.doReload( req, context );
-
- servlet=null;
- servletClass=null;
- /* Initial attempt to shut down the context and sessions.
-
-String path=context.getPath();
-String docBase=context.getDocBase();
-// XXX all other properties need to be saved
-// or something else
-ContextManager cm=context.getContextManager();
-cm.removeContext(path);
-Context ctx=new Context();
-ctx.setPath( path );
-ctx.setDocBase( docBase );
-cm.addContext( ctx );
-context=ctx;
-// XXX shut down context, remove sessions, etc
- */
- }
+// We need to syncronize here so that multiple threads don't
+// try and reload the class. The first thread through will
+// create the new loader which will make shouldReload return
+// false for subsequent threads.
+synchronized(this) {
+// XXX no need to check after we remove the old loader
+if( loader.shouldReload() ) {
+// workaround for destroy
+try {
+destroy();
+} catch(Exception ex ) {
+context.log( Error in destroy , ex );
+}
+initialized=false;
+loader.reload();
+
+ContextManager cm=context.getContextManager();
+cm.doReload( req, context );
+
+servlet=null;
+servletClass=null;
+/* Initial attempt to shut down the context and sessions.
+
+ String path=context.getPath();
+ String docBase=context.getDocBase();
+ // XXX all other properties need to be saved
+ // or something else
+ ContextManager cm=context.getContextManager();
+ cm.removeContext(path);
+ Context ctx=new Context();
+ ctx.setPath( path );
+ ctx.setDocBase( docBase );
+ cm.addContext( ctx );
+ context=ctx;
+ // XXX shut down context, remove sessions, etc
+*/
+}
+}
}
}
}
cvs commit: jakarta-tomcat/src/native/jk jk_sockbuf.c jk_util.c
mmanders01/06/19 16:21:04
Modified:src/native/jk Tag: tomcat_32 jk_sockbuf.c jk_util.c
Log:
Changed c++ style comments to c style comments.
Submitted by: Scott E. Reinhart [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.1.2.3 +2 -2 jakarta-tomcat/src/native/jk/Attic/jk_sockbuf.c
Index: jk_sockbuf.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/jk/Attic/jk_sockbuf.c,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- jk_sockbuf.c 2001/02/02 16:55:34 1.1.2.2
+++ jk_sockbuf.c 2001/06/19 23:21:01 1.1.2.3
@@ -56,7 +56,7 @@
/***
* Description: Simple buffer object to handle buffered socket IO *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.1.2.2 $ *
+ * Version: $Revision: 1.1.2.3 $ *
***/
#include jk_global.h
@@ -224,7 +224,7 @@
sb-buf + sb-end,
SOCKBUF_SIZE - sb-end, 0);
- // 0 is EOF/SHUTDOWN, -1 is SOCK_ERROR
+ /* 0 is EOF/SHUTDOWN, -1 is SOCK_ERROR */
if (ret = 0) {
return ret;
}
1.6.2.4 +3 -3 jakarta-tomcat/src/native/jk/Attic/jk_util.c
Index: jk_util.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/jk/Attic/jk_util.c,v
retrieving revision 1.6.2.3
retrieving revision 1.6.2.4
diff -u -r1.6.2.3 -r1.6.2.4
--- jk_util.c 2001/01/11 21:33:35 1.6.2.3
+++ jk_util.c 2001/06/19 23:21:02 1.6.2.4
@@ -56,7 +56,7 @@
/***
* Description: Utility functions (mainly configuration) *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.6.2.3 $ *
+ * Version: $Revision: 1.6.2.4 $ *
***/
@@ -214,7 +214,7 @@
#ifdef WIN32
used = _snprintf(buf, HUGE_BUFFER_SIZE, [%s (%d)]: , f, line);
-#elif defined(NETWARE) // until we get a snprintf function
+#elif defined(NETWARE) /* until we get a snprintf function */
buf = (char *) malloc(HUGE_BUFFER_SIZE);
if (NULL == buf)
return -1;
@@ -230,7 +230,7 @@
va_start(args, fmt);
#ifdef WIN32
rc = _vsnprintf(buf + used, HUGE_BUFFER_SIZE - used, fmt, args);
-#elif defined(NETWARE) // until we get a vsnprintf function
+#elif defined(NETWARE) /* until we get a vsnprintf function */
rc = vsprintf(buf + used, fmt, args);
#else
rc = vsnprintf(buf + used, HUGE_BUFFER_SIZE - used, fmt, args);
RE: Some clean up of the jakarta-tomcat tree for Tomcat 3.3
+1. Costin On Wed, 20 Jun 2001, Ignacio J. Ortega wrote: +1 Saludos , Ignacio J. Ortega -Mensaje original- De: Larry Isaacs [mailto:[EMAIL PROTECTED]] Enviado el: martes 19 de junio de 2001 23:49 Para: '[EMAIL PROTECTED]' Asunto: Some clean up of the jakarta-tomcat tree for Tomcat 3.3 Hi, Does anyone have any objection to my deleting the following folders from the jakarta-tomcat head: proposals/jasper34 proposals/tomcat-4.0 proposals/web-connector src/jasper34 They all have projects elsewhere and, as Henri noted earlier, would make a noticeable reduction in the size of the source file. Cheers, Larry
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loaderWebappLoader.java
on 6/19/01 4:03 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: remm01/06/19 16:03:33 Modified:catalina/src/share/org/apache/catalina/loader WebappLoader.java Log: - Use the local context notifier. Should fix build failure with Jikes reported by Jon. build-main: [javac] Compiling 1 source file to /Users/jon/checkout/jakarta-tomcat-4.0/ca talina/build/classes Fixed it. :-) Thanks Remy. -jon
Re: cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loaderWebappClassLoader.java
on 6/18/01 7:30 PM, Remy Maucherat [EMAIL PROTECTED] wrote: Obviously, the side effect is not that huge. Try it first, and complain later if it's really a problem :) I'm not sure I like a hack like this that is clearly winblows specific. Can you do this conditionally depending on platform? It's not a hack, it's just about robustness. Maybe it would be a problem on some other platform, I just don't know. Remy Ok, I guess I can't complain because this doesn't seem to extract any WEB-INF/lib jars into the work directory. :-) I'm using the latest cvs of tomcat... -jon
Re: cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loaderWebappClassLoader.java
on 6/18/01 7:30 PM, Remy Maucherat [EMAIL PROTECTED] wrote: Obviously, the side effect is not that huge. Try it first, and complain later if it's really a problem :) I'm not sure I like a hack like this that is clearly winblows specific. Can you do this conditionally depending on platform? It's not a hack, it's just about robustness. Maybe it would be a problem on some other platform, I just don't know. Remy Ok, I guess I can't complain because this doesn't seem to extract any WEB-INF/lib jars into the work directory. :-) I'm using the latest cvs of tomcat... ... ... ? And it's still loading the classes ? When it's been proven that it's working as it should under Unix without copying away the JARs, then we can consider not moving away the JARs. At least under Windows, it's definitely needed, though. We could also not copy the JARs when reloading is disabled. Remy
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappLoader.java
remm01/06/19 19:29:14
Modified:catalina/src/share/org/apache/catalina/loader
WebappLoader.java
Log:
- Add some temporary traces which could help debug the setup of the
repositories.
Revision ChangesPath
1.4 +6 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java
Index: WebappLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- WebappLoader.java 2001/06/19 23:03:30 1.3
+++ WebappLoader.java 2001/06/20 02:29:13 1.4
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
1.3 2001/06/19 23:03:30 remm Exp $
- * $Revision: 1.3 $
- * $Date: 2001/06/19 23:03:30 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
1.4 2001/06/20 02:29:13 remm Exp $
+ * $Revision: 1.4 $
+ * $Date: 2001/06/20 02:29:13 $
*
*
*
@@ -119,7 +119,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.3 $ $Date: 2001/06/19 23:03:30 $
+ * @version $Revision: 1.4 $ $Date: 2001/06/20 02:29:13 $
*/
public class WebappLoader
@@ -936,7 +936,9 @@
} catch (NamingException e) {
// Silent catch: it's valid that no /WEB-INF/lib directory
//exists
+e.printStackTrace();
} catch (IOException e) {
+e.printStackTrace();
}
}
jasper34 - status
FYI, I'm not planning any major changes in the near future for jasper34. I'm reasonably happy with the first round of cleanup and refactoring, and I think we are moving in a good direction with the toolkit-isation of jasper and the various optimizations we discussed. I want to let the code stabilize a bit and get more feedback before I start the next step. I'll keep doing small changes and fixes, probably finish the line number mapping and start restoring what was broken during the first step ( jspc is one, jspservlet needs a bit more testing after the class loader changes ), plus some improvements in the runtime. I think the I/O changes, the Liaisons, the overal structure are 'under control', it's just a matter of finding the time to implement them. The big one is the internal API to be used for the tree and generators - it has to be as simple as possible in order to be able to move fast in creating inline versions for common tags and to allow various optimizations in taglibs. I think we can start experimenting in the current version with generating special code for some tags - and use this to learn more about it. ( I expect some more major jasper34 changes after 3.3 beta ) Costin
Re:cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loaderWebappClassLoader.java
on 6/19/01 7:21 PM, Remy Maucherat [EMAIL PROTECTED] wrote: Ok, I guess I can't complain because this doesn't seem to extract any WEB-INF/lib jars into the work directory. :-) I'm using the latest cvs of tomcat... ... ... ? And it's still loading the classes ? Yup, everything is running fine... I'm serious...nothing is going into my work/localhost/scarab (the only directories in the work directory) directory... -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
Re: Re:cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loaderWebappClassLoader.java
And it's still loading the classes ? Yup, everything is running fine... Weird. I'm serious...nothing is going into my work/localhost/scarab (the only directories in the work directory) directory... Do you have version 1.63 of StandardContext, as well as 1.4 (or 1.3, it's the same minus the traces mentioned below) of WebappLoader, and 1.2 of WebappClassLoader ? I added some e.printStackTrace() in WebappLoader to display if something bad happens when actually copying the files. It may be some platform specific file-related bug. I don't think I have hardcoded anything as work-only-on-windows, though ;-) Remy
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http Parameters.java
costin 01/06/19 22:24:47
Modified:util/java/org/apache/tomcat/util/buf ByteChunk.java
UDecoder.java
util/java/org/apache/tomcat/util/http Parameters.java
Log:
Few fixes related with decoding 8859_1.
Replaced default encoding from UTF8 to 8859_1. While I think it would be
better to default to UTF8 in low-level utils like MessageBytes, fact is that
most of the uses for MB is in servlet container where 8859_1 is required
as default impl. That's pretty bad as most RFCs and recent standards seem to be
moving to UTF.
( we could make it non-final, but than it would be even worse ).
The solution is to make sure the encoding is propagated and set by the caller
( we could throw an exception - just to make sure the problem is handled )
Also removed an extra log.
Revision ChangesPath
1.4 +8 -2
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ByteChunk.java2001/06/03 20:34:25 1.3
+++ ByteChunk.java2001/06/20 05:24:47 1.4
@@ -100,7 +100,13 @@
}
//
-
+
+/** Default encoding used to convert to strings. It should be UTF8,
+ as most standards seem to converge, but the servlet API requires
+ 8859_1, and this object is used mostly for servlets.
+*/
+public static final String DEFAULT_CHARACTER_ENCODING=ISO-8859-1;
+
// byte[]
private byte[] buff;
@@ -409,7 +415,7 @@
}
String strValue=null;
try {
- if( enc==null ) enc=UTF8;
+ if( enc==null ) enc=DEFAULT_CHARACTER_ENCODING;
return new String( buff, start, end-start, enc );
/*
Does not improve the speed too much on most systems,
1.3 +2 -2
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/UDecoder.java
Index: UDecoder.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/UDecoder.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- UDecoder.java 2001/06/12 14:52:01 1.2
+++ UDecoder.java 2001/06/20 05:24:47 1.3
@@ -119,7 +119,7 @@
}
mb.setEnd( idx );
-
+
return;
}
@@ -131,7 +131,7 @@
public void convert( CharChunk mb )
throws IOException
{
- log( Converting a char chunk );
+ // log( Converting a char chunk );
int start=mb.getOffset();
char buff[]=mb.getBuffer();
int cend=mb.getEnd();
1.4 +5 -1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/Parameters.java
Index: Parameters.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/Parameters.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Parameters.java 2001/06/11 20:07:02 1.3
+++ Parameters.java 2001/06/20 05:24:47 1.4
@@ -115,6 +115,7 @@
public void setEncoding( String s ) {
encoding=s;
+ if(debug0) log( Set encoding to + s );
}
public void recycle() {
@@ -168,6 +169,7 @@
// the head will be the new element.
currentChild=currentChild.child;
+ currentChild.setEncoding( encoding );
}
/** Discard the last child. This happens when we return from a
@@ -255,7 +257,8 @@
*/
public void handleQueryParameters() {
if( didQueryParameters ) return;
-
+
+ queryMB.setEncoding( encoding );
didQueryParameters=true;
if( debug 0 )
log( Decoding query + queryMB + + encoding);
@@ -265,6 +268,7 @@
try {
decodedQuery.duplicate( queryMB );
+ decodedQuery.setEncoding(encoding);
} catch( IOException ex ) {
}
if( debug 0 )
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Request.java
costin 01/06/19 22:29:28
Modified:src/share/org/apache/tomcat/core Request.java
Log:
Propagate the encoding ( set it on queryString before processing ).
Make sure we set 8859_1, as requested by servlet api, to make sure MessageBytes
behave as expected.
( few recent bugs were caused by the fact that valid 8859_1 chars where
lost in UTF8 conversion )
Revision ChangesPath
1.102 +6 -1 jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java
Index: Request.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java,v
retrieving revision 1.101
retrieving revision 1.102
diff -u -r1.101 -r1.102
--- Request.java 2001/05/26 17:51:15 1.101
+++ Request.java 2001/06/20 05:29:27 1.102
@@ -418,7 +418,12 @@
}
public void handleQueryParameters() {
- params.setEncoding( getCharacterEncoding() );
+ // set the encoding for query parameters.
+ getCharacterEncoding();
+ if( charEncoding != null )
+ params.setEncoding( getCharacterEncoding() );
+ else
+ params.setEncoding( DEFAULT_CHARACTER_ENCODING );
params.handleQueryParameters();
}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config AutoWebApp.java
costin 01/06/19 22:36:20
Modified:src/share/org/apache/tomcat/modules/config AutoWebApp.java
Log:
Fix for 2199 - dot files added as webapps. Most of the time dot files are
special, and may contain private info - it's better to be safe and disable
by default.
It's an option, so you can re-enable if you like .dirs as webapps.
Revision ChangesPath
1.4 +13 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoWebApp.java
Index: AutoWebApp.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoWebApp.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AutoWebApp.java 2001/02/06 06:42:01 1.3
+++ AutoWebApp.java 2001/06/20 05:36:20 1.4
@@ -85,6 +85,7 @@
String appsD=webapps;
String defaultHost=null;
boolean flat=true;
+boolean ignoreDot=true;
// encoding scheme - XXX review, customize, implement
char hostSeparator='@'; // if support for vhost configuration is enabled
@@ -117,6 +118,12 @@
defaultHost=h;
}
+/** Ignore directories starting with a .
+ */
+public void setIngoreDot( boolean b ) {
+ ignoreDot=b;
+}
+
/** Not implemented - default is true. If flat==false, virtual
hosts will be configured using the hierarchy in webapps.
@@ -166,6 +173,8 @@
if( flat ) {
for (int i = 0; i list.length; i++) {
String name = list[i];
+ if( ignoreDot name.startsWith( . ))
+ continue;
File f=new File( webappD, name );
if( f.isDirectory() ) {
String appHost=defaultHost;
@@ -188,7 +197,10 @@
String name = list[i];
File f=new File( webappD, name );
if( f.isDirectory() ) {
- addVHost( cm, webappD, name );
+ if( ignoreDot name.statsWith(. )) {
+ continue;
+ } else
+ addVHost( cm, webappD, name );
}
}
}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config AutoWebApp.java
costin 01/06/19 22:55:07
Modified:src/share/org/apache/tomcat/modules/config AutoWebApp.java
Log:
Forgot an 'r'.
Revision ChangesPath
1.5 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoWebApp.java
Index: AutoWebApp.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoWebApp.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- AutoWebApp.java 2001/06/20 05:36:20 1.4
+++ AutoWebApp.java 2001/06/20 05:55:06 1.5
@@ -197,7 +197,7 @@
String name = list[i];
File f=new File( webappD, name );
if( f.isDirectory() ) {
- if( ignoreDot name.statsWith(. )) {
+ if( ignoreDot name.startsWith(. )) {
continue;
} else
addVHost( cm, webappD, name );
