RE: CVS / mod_webapp / web-connector sub-project

2001-04-19 Thread GOMEZ Henri

>I think Dan is right on this one - improving the configuration 
>of mod_jk
>is probably the most important thing, and merging with mod_webapp and
>porting it's protocol and config mechanism would be a good way 
>to do that. 

I agree that integrating mod_webapp functionnalities is not 
a priority for the 3.x branch. We could add the autoconf stuff 
or may be also use APR which will hide all OS complexity.

The problem today, is that there is 2 version of mod_jk :

*) mod_jk in Tomcat 3.3

  Latest code, maintainers, bugs fixed and Apache 1.3/2.0 support

*) mod_jk in Tomcat 3.2.x

  The same code since 3.2, no much maintainers, some bugs fixed in 3.3
  are not in 3.2, only Apache 1.3 support.

If a user have problem using mod_jk against it's Tomcat 3.2.1
release (or upcoming Tomcat 3.2.2), we'll ask him to use the 
mod_jk from Tomcat 3.3 CVS !

Problems could be using Apache 2.0 or Apache restart needed 
after Tomcat shutdown/restart when using ajp13, .

>I think the best way to do that would be a revolution ( like 
>jasper34 ),
>and when it's ready propose it as either a replacement for 
>both mod_jk and
>mod_webapp, or as a top level project ( if enough people will 
>contribute 
>on it ). Combining mod_jk and mod_webapp is likely to result 
>in something
>better than both, so the vote to replace mod_jk and mod_webapp 
>will be a
>formality  :-)

I strongly think we must have the connectors in a separate project
so I'll follow your proposal and start a revolution. 

>( making it a top level project now is not a good idea right 
>now, neither
>to do the development in the main tree - there are just few 
>big bugs to be
>fixed before a 3.3 beta. )

Yep, I'll keep maintain the code in 3.3 tree and in parallel
start the proposed revolution :

* native code extracted => connector
* java code moved from tomcat core/utils => org.apache.connector 

>P.S. It's fun beeing a "revolutionar" !

Let's go, there were not much revolution from France since 1789



sample code to add interception to url access in tomcat 3.2.1

2001-04-19 Thread Teitelman, Chen
Title: sample code to add interception to url access in tomcat 3.2.1





I am looking for sample code to add interception to URL access in tomcat 3.2.1

Chen Teitelman  

Computer Associates

Manager/ Development

tel: +972 3 645

fax: +972 3 6450001

mailto:[EMAIL PROTECTED] 





[PATCH] T4/catalina/build.sh

2001-04-19 Thread Ceki Gülcü


Hello,

Here is a small patch to make jakarta-tomcat-4.0/catalina/build.sh
a bit more cygwin friendly. Best regards, Ceki

Index: build.sh
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.sh,v
retrieving revision 1.8
diff -u -u -r1.8 build.sh
--- build.sh2000/12/23 21:41:14 1.8
+++ build.sh2001/04/19 10:59:39
@@ -123,6 +123,10 @@
   CP=$CLASSPATH:$CP
 fi
 
+if [ "$OSTYPE" = "cygwin32" ] || [ "$OSTYPE" = "cygwin" ] ; then
+  CP=`cygpath --path --windows "$CP"`
+fi
+
 # - Execute The Requested Build ---
 
 $JAVA_HOME/bin/java $ANT_OPTS -classpath $CP org.apache.tools.ant.Main 
-Dcatalina.jaxp.home=$CATALINA_JAXP_HOME 
-Dcatalina.jaxp.parser.jar=$CATALINA_JAXP_PARSER_JAR -Djsse.home=$JSSE_HOME 
-Djmx.home=$JMX_HOME -Djndi.home=$JNDI_HOME -Dregexp.home=$REGEXP_HOME 
-Dservletapi.home=$SERVLETAPI_HOME -Djava.home=$JAVA_HOME "$@"





Problem with "isEncodeable"

2001-04-19 Thread Luise Massimo

Hi all.
I have noticed a strange thing with isEncodeable/toAbsolute
(HttpServletResponseFacade.java) in Tomcat 3.2.1.
I'm using encodeURL into a RequestDispatcher.forward and i'm forwarding a
request from a servlet to a JSP.
The context is "/servizi" and he URL to which i'm forwarding the request is
"/templates/page.jsp", which is a directory inside the context "/servizi"
(so the URL is relative to the context).

The URL i'm forwarding requests is changed by toAbsolute into
"http://server/templates/page.jsp" which does not contain the servlet
context (the right for me it would be
"http://server/servizi/templates/page.jsp").

The method isEncodeable test if the URL start with the context path, so in
my case this does not happens !!

String contextPath = request.getContext().getPath();
if ((contextPath != null) && (contextPath.length() > 0)) {
String file = url.getFile();
if ((file == null) || (!file.startsWith(contextPath))
return( false );
}

contextPath = "/servizi"
url=http://server/templates/page.jsp"
url.getFilte() = "/templates/page.jsp"

The URL is changed by toAbsolute method with:

Request req = response.getRequest();
String requrl = HttpUtils.getRequestURL( request.getFacade() ).toString();
try {
url = new URL( new URL( requrl ), location );
}


HttpUtils.getRequestURL(..) = http://server/servizi/servlet/myServlet


All this it's to explain that the encodeURL does not work when used inside
RequestDispatcher.forward().

Does anyone can explain me what i'm doing of wrong ?

Thanks in advance.  Max




mod_jk on HP-UX11

2001-04-19 Thread Matthias Juchem

Hi there,

yesterday I played around with the source code of mod_jk because it does
not work for HP-UX 11. In order to test some things, I need to know
something about the expected behaviour (the Faq-O-Matic is out of order
at the moment):

Does the module start Tomcat automatically? I remember having read about
this, but I do not recall everything.

Regards,
 Matthias





Re: mod_jk on HP-UX11

2001-04-19 Thread cmanolache


Hi,

> yesterday I played around with the source code of mod_jk because it does
> not work for HP-UX 11. In order to test some things, I need to know
> something about the expected behaviour (the Faq-O-Matic is out of order
> at the moment):

That's great, can you compile it ? ( there is a bug in bugzilla, it would
be good if we can mark it as fixed - I don't like "doesn't compile" bugs)

> Does the module start Tomcat automatically? I remember having read about
> this, but I do not recall everything.

No, it doesn't. It's one of the features from mod_jserv we didn't ported
( it's not difficult, it is just a "low priority" item waiting for
volunteers ). 

Costin




RE: mod_jk on HP-UX11

2001-04-19 Thread Mike Braden

If you want to start working with mod_jk on HPUX, I'd
highly recommend the mod_jk that comes with TC3.3.

This version of mod_jk will work with other versions
of Tomcat 3 and has the latest changes.

Also note that there is now a build script for mod_jk
for HPUX included with TC3.3.  I think it made it into
the m2 release, but the latest mod_jk-howto did not.

You may also want to look at the CVS for the latest
info.

Also, the module does not start Tomcat.  You should
start Tomcat before starting Apache, however, it is
not a requirement.  With the latest changes to mod_jk,
you should be able to restart Tomcat without restarting
Apache (I haven't tried this, though).

Mike.
--
Mike Braden
[EMAIL PROTECTED]
[EMAIL PROTECTED] 

-Original Message-
From: Matthias Juchem [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 19, 2001 8:06 AM
To: [EMAIL PROTECTED]
Subject: mod_jk on HP-UX11


Hi there,

yesterday I played around with the source code of mod_jk because it does
not work for HP-UX 11. In order to test some things, I need to know
something about the expected behaviour (the Faq-O-Matic is out of order
at the moment):

Does the module start Tomcat automatically? I remember having read about
this, but I do not recall everything.

Regards,
 Matthias





Jasper and taglib

2001-04-19 Thread Luise Massimo

Hi all.

Anyone can tell me why Jasper   assume there is only one entry for
taglib-uri/taglib-location inside taglib node (this in Tomcat 3.2.1) ?




[PATCH] */build.sh

2001-04-19 Thread Ceki Gülcü


Hi,

I found that adding the following lines to the different build.sh files contained in 
the jakarta-tomcat-4.0 CVS module makes the build.sh files cygwin friendly. 

# Here to show context
if [ "$CLASSPATH" != "" ] ; then
  CP=$CLASSPATH:$CP
fi

# To be added:
if [ "$OSTYPE" = "cygwin32" ] || [ "$OSTYPE" = "cygwin" ] ; then
  CP=`cygpath --path --windows "$CP"`
fi

That's it. Ceki Gülcü




Re: Jasper and taglib

2001-04-19 Thread Craig R. McClanahan



On Thu, 19 Apr 2001, Luise Massimo wrote:

> Hi all.
> 
> Anyone can tell me why Jasper assume there is only one entry for
> taglib-uri/taglib-location inside taglib node (this in Tomcat 3.2.1) ?
> 
> 

Because that's what the deployment descriptor DTD requires -- see the
Servlet 2.2 spec at .

If you want to reference more than one tag library in the same web app,
simply use more than one  element.

Craig





Tomcat & Apache experiences

2001-04-19 Thread Ben Hutchison



Hi all,
 
I have been trying to set an Apache 
server with Tomcat under Windows. It hasnt been as easy as it could be. I have a 
few issues with both distributions and docs which Im going to describe here. 

 
First up, I tried running Tomcat 4.0b3 with Apache. 

 
It requires the user to build mod_webapp. I tried 
with Cygwin gcc and it failed. I think it would greatly ease uptake and user 
testing of Tomcat 4.0 betas if a Windows binary was provided by somebody who 
knows how to build it. Windows doesnt have the default tool support or culture 
of unixes for easy building of C source. The most popular windows 
compiler, Visual C++, isnt freely available. Under windows, you cant just type 
"make all" and expect it to work on a standard machine like you can on UNIX. 

 
So then I fell back to Tomcat 3.2.1. 
 
It seems that the bin/startup.bat and 
bin/tomcat.bat scripts are broken by default. They specify Tomcat_Home as '.', 
the current cirectory, not '..', the parent.
 
I found duplication in the Tomcat documentation on 
Apache integration which confused me. In the main user guide, could a link be 
placed across to Tomcat-Apache How To, rather than the current superceeded 
section text?
 
I went to JServ and downloaded the windows .exe 
installer to get the jserv DLL. It demanded the location of the JSDK directory, 
(which no longer exists?) and then deleted all its files when I didnt provide 
it. Workaround: I re-ran it and killed the process when it had unpacked the 
files.
 
After that it worked fine.
 
Regards
Ben


[PATCH] Bug #1400:

2001-04-19 Thread Doug Barnes


The keystore file format allows (and keytool encourages) multiple keys in a
keystore file, with each key encrypted with a different password. It should
be
possible to specify an SSLServerSocketFactory that deals with a keystore
file
that has these properties (currently, it just uses the first key in the file
no matter what.)

This patch adds support for multiple keys in a single keystore, each
encrypted
seperately, by adding the parameters keyAlias and keyPass. In addition, I've
changed the example server.xml to show the new parameters.

If there's only one key, it ignores keyAlias; if keyPass doesn't work, it
tries keystorePass.

This addresses my personal confusion with trying to get this to work with an
existing keystore. It appears to work.

Cheers,

D


Index: SSLServerSocketFactory.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ne
t/SSLServerSocketFactory.java,v
retrieving revision 1.3
diff -u -r1.3 SSLServerSocketFactory.java
--- SSLServerSocketFactory.java 2000/11/08 01:18:54 1.3
+++ SSLServerSocketFactory.java 2001/04/19 17:08:16
@@ -61,6 +61,7 @@
 import java.io.File;
 import java.io.FileInputStream;
 import java.io.IOException;
+import java.util.Enumeration;
 import java.net.InetAddress;
 import java.net.ServerSocket;
 import java.security.KeyStore;
@@ -95,6 +96,10 @@
  * loaded. ["./keystore" in the user home directory]
  * keystorePass - Password for the Key Store file to
be
  * loaded. ["changeit"]
+ * keyAlias - Alias for the key to use in Key Store
+ * file (if multiple keys). ["tomcat"]
+ * keyPass - Password for the Key to be
+ * loaded. ["changeit"]
  * keystoreType - Type of the Key Store file to be
  * loaded. ["JKS"]
  * protocol - SSL protocol to use. [TLS]
@@ -211,9 +216,37 @@
 }


+/**
+ * Alias for the key to use (if multiple keys in KeystoreFile)
+ */
+private String keyAlias = "tomcat";
+
+public String getKeyAlias() {
+return (this.keyAlias);
+}
+
+public void setKeyAlias(String keyAlias) {
+this.keyAlias = keyAlias;
+}
+
+
 /**
- * Storeage type of the key store file to be used.
+ * Password for accessing a particular key
  */
+private String keyPass = "changeit";
+
+public String getKeyPass() {
+return (this.keyPass);
+}
+
+public void setKeyPass(String keyPass) {
+this.keyPass = keyPass;
+}
+
+
+/**
+ * Storage type of the key store file to be used.
+ */
 private String keystoreType = "JKS";

 public String getKeystoreType() {
@@ -384,10 +417,29 @@
 // Create an SSL context used to create an SSL socket factory
 SSLContext context = SSLContext.getInstance(protocol);

+// If multiple entries in keyStore, and specified alias is
+// in keyStore, delete all but keyAlias (otherwise use first
+// entry in keyStore.)
+if ((keyStore.size() > 1) &&
(keyStore.containsAlias(keyAlias))) {
+for (Enumeration aliasList = keyStore.aliases();
+ aliasList.hasMoreElements();) {
+String alias = (String) aliasList.nextElement();
+if(! alias.equals(keyAlias)) {
+keyStore.deleteEntry(alias);
+}
+}
+}
+
 // Create the key manager factory used to extract the server
key
 KeyManagerFactory keyManagerFactory =
 KeyManagerFactory.getInstance(algorithm);
-keyManagerFactory.init(keyStore, keystorePass.toCharArray());
+
+try {
+keyManagerFactory.init(keyStore, keyPass.toCharArray());
+} catch (Exception e) {
+System.out.println("Trying keystore key: " + keystorePass);
+keyManagerFactory.init(keyStore,
keystorePass.toCharArray());
+}

 // Create the trust manager factory used for checking
certificates
 /*
@@ -418,12 +470,13 @@
  * @param ssocket The server socket to be configured
  */
 private void initServerSocket(ServerSocket ssocket) {
+String ciphers[] = {"SSL_RSA_EXPORT_WITH_RC4_40_MD5"};

 SSLServerSocket socket = (SSLServerSocket) ssocket;

 // Enable all available cipher suites when the socket is connected
 String cipherSuites[] = socket.getSupportedCipherSuites();
-socket.setEnabledCipherSuites(cipherSuites);
+socket.setEnabledCipherSuites(ciphers);

 // Set client authentication if necessary
 socket.setNeedClientAuth(clientAuth);
Index: SSLServerSocketFactory.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ne
t/SSLServerSocketFactory.java,v
retrieving revision 1.3
diff -u -r1.3 SSLServerSo

Re: mod_jk on HP-UX11

2001-04-19 Thread Matthias Juchem

On Thu, 19 Apr 2001 [EMAIL PROTECTED] wrote:

>
> Hi,
>
> > yesterday I played around with the source code of mod_jk because it does
> > not work for HP-UX 11. In order to test some things, I need to know
> > something about the expected behaviour (the Faq-O-Matic is out of order
> > at the moment):
>
> That's great, can you compile it ? ( there is a bug in bugzilla, it would
> be good if we can mark it as fixed - I don't like "doesn't compile" bugs)

Here is the patch (GNU diff -urN) against 3.2.1. It uses shl_load() (the
old interface) instead of dlopen(). I can start apache (which did not work
without the patch) and I get answers from Tomcat.

If you have questions, please ask. The patch also went into Bugzilla
([EMAIL PROTECTED] is also me).


Matthias




RE: mod_jk on HP-UX11

2001-04-19 Thread Matthias Juchem

On Thu, 19 Apr 2001, Mike Braden wrote:

I've just read README.hpux and it says that support for JNI was removed in
order to build it on HP-UX 11.
I do not know the internals of Tomcat and where JNI is needed there, but
at least my patch (submitted before) seems to work without remove support
for anything. It just uses another interface for dynamic loading.

I guess the 3.3 release is not too far away, so I'll wait for it before
trying the new version of mod_jk.

 Matthias

> If you want to start working with mod_jk on HPUX, I'd
> highly recommend the mod_jk that comes with TC3.3.
>
> This version of mod_jk will work with other versions
> of Tomcat 3 and has the latest changes.
>
> Also note that there is now a build script for mod_jk
> for HPUX included with TC3.3.  I think it made it into
> the m2 release, but the latest mod_jk-howto did not.
>
> You may also want to look at the CVS for the latest
> info.





R: Jasper and taglib

2001-04-19 Thread Luise Massimo

Sorry.i made a stupid question :( ...sorry again 

-Messaggio originale-
Da: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Inviato: giovedì 19 aprile 2001 18.44
A: '[EMAIL PROTECTED]'
Oggetto: Re: Jasper and taglib




On Thu, 19 Apr 2001, Luise Massimo wrote:

> Hi all.
> 
> Anyone can tell me why Jasper assume there is only one entry for
> taglib-uri/taglib-location inside taglib node (this in Tomcat 3.2.1) ?
> 
> 

Because that's what the deployment descriptor DTD requires -- see the
Servlet 2.2 spec at .

If you want to reference more than one tag library in the same web app,
simply use more than one  element.

Craig




cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_msg_buff.c jk_msg_buff.h

2001-04-19 Thread hgomez

hgomez  01/04/19 14:25:28

  Modified:src/native/mod_jk/common jk_msg_buff.c jk_msg_buff.h
  Log:
  Added jk_dump_msg helper function to help
  dump what's in a jk_buff
  
  Revision  ChangesPath
  1.3   +24 -1 jakarta-tomcat/src/native/mod_jk/common/jk_msg_buff.c
  
  Index: jk_msg_buff.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_msg_buff.c,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- jk_msg_buff.c 2000/11/10 18:48:50 1.2
  +++ jk_msg_buff.c 2001/04/19 21:25:27 1.3
  @@ -57,7 +57,8 @@
* Description: Data marshaling. XDR like  *
* Author:  Costin <[EMAIL PROTECTED]>  *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.2 $   *
  + * Author:  Henri Gomez <[EMAIL PROTECTED]>   *
  + * Version: $Revision: 1.3 $   *
***/
   
   #include "jk_pool.h"
  @@ -65,6 +66,7 @@
   #include "jk_util.h"
   #include "jk_sockbuf.h"
   #include "jk_msg_buff.h"
  +#include "jk_logger.h"
   
   struct jk_msg_buf {
   jk_pool_t *pool;
  @@ -330,3 +332,24 @@
   *dst++ = *(src + 1 );
   *dst= *src;
   }
  +
  +/** Helpie dump function 
  + */
  +void jk_dump_buff(jk_logger_t *l,
  +  const char *file,
  +  int line,
  +  int level,
  +  char * what,
  +  jk_msg_buf_t * msg)
  +{
  +#ifdef USE_ALSO_BODY
  +jk_log(l, file, line, level, "%s #%d %.*s\n",
  +  what,
  +  jk_b_get_len(msg),
  +  jk_b_get_len(msg),
  +  jk_b_get_buff(msg));
  +#else
  +jk_log(l, file, line, level, "%s #%d\n", what, jk_b_get_len(msg));
  +#endif
  +}
  +
  
  
  
  1.3   +9 -1  jakarta-tomcat/src/native/mod_jk/common/jk_msg_buff.h
  
  Index: jk_msg_buff.h
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_msg_buff.h,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- jk_msg_buff.h 2000/11/10 18:48:50 1.2
  +++ jk_msg_buff.h 2001/04/19 21:25:27 1.3
  @@ -57,7 +57,7 @@
* Description: Data marshaling. XDR like  *
* Author:  Costin <[EMAIL PROTECTED]>  *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.2 $   *
  + * Version: $Revision: 1.3 $   *
***/
   
   #ifndef JK_MSG_BUF_H
  @@ -183,6 +183,14 @@
   
   unsigned char jk_b_pget_byte(jk_msg_buf_t *msg, 
int pos);
  +
  +/* - Help  */
  +void jk_dump_buff(jk_logger_t *l, 
  +  const char *file,
  +  int line,
  +  int level,
  +  char * what,
  +  jk_msg_buf_t * msg);
   
   #ifdef __cplusplus
   }
  
  
  



cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_ajp13_worker.c

2001-04-19 Thread hgomez

hgomez  01/04/19 14:26:44

  Modified:src/native/mod_jk/common jk_ajp13_worker.c
  Log:
  The previous patch to solve the Tomcat restart
  problem corrected only GET method.
  This one add POST method support.
  
  Revision  ChangesPath
  1.7   +82 -40jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c
  
  Index: jk_ajp13_worker.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- jk_ajp13_worker.c 2001/03/27 22:42:04 1.6
  +++ jk_ajp13_worker.c 2001/04/19 21:26:43 1.7
  @@ -1,5 +1,5 @@
   /*
  - * Copyright (c) 1997-1999 The Java Apache Project.  All rights reserved.
  + * Copyright (c) 1997-2001 The Java Apache Project.  All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
  @@ -58,7 +58,7 @@
* Author:  Henri Gomez <[EMAIL PROTECTED]>   *
* Author:  Costin <[EMAIL PROTECTED]>  *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.6 $   *
  + * Version: $Revision: 1.7 $   *
***/
   
   #include "jk_pool.h"
  @@ -75,6 +75,8 @@
   #define DEF_CACHE_SZ(1)
   #define JK_INTERNAL_ERROR   (-2)
   #define MAX_SEND_BODY_SZ(DEF_BUFFER_SZ - 6)
  +#define AJP13_HEADER_LEN (4)
  +#define AJP13_HEADER_SZ_LEN  (2)
   
   struct ajp13_operation;
   typedef struct ajp13_operation ajp13_operation_t;
  @@ -196,6 +198,8 @@
   {
   jk_b_end(msg);
   
  +jk_dump_buff(l, JK_LOG_DEBUG, "sending to ajp13", msg);
  +
   if(0 > jk_tcp_socket_sendfull(ep->sd, 
 jk_b_get_buff(msg),
 jk_b_get_len(msg))) {
  @@ -209,11 +213,11 @@
 jk_msg_buf_t *msg, 
 jk_logger_t *l) 
   {
  -unsigned char head[4];
  +unsigned char head[AJP13_HEADER_LEN];
   int rc;
   int msglen;
   
  -rc = jk_tcp_socket_recvfull(ep->sd, head, 4);
  +rc = jk_tcp_socket_recvfull(ep->sd, head, AJP13_HEADER_LEN);
   
   if(rc < 0) {
   jk_log(l, JK_LOG_ERROR, 
  @@ -246,6 +250,7 @@
   return JK_FALSE;
   }
   
  +jk_dump_buff(l, JK_LOG_DEBUG, "received from ajp13", msg);
   return JK_TRUE;
   }
   
  @@ -280,8 +285,8 @@
   
   jk_b_reset(msg);
   
  -read_buf += 4; /* leave some space for the buffer headers */
  -read_buf += 2; /* leave some space for the read length */
  +read_buf += AJP13_HEADER_LEN;/* leave some space for the buffer headers */
  +read_buf += AJP13_HEADER_SZ_LEN; /* leave some space for the read length */
   
   if(read_fully_from_server(r, read_buf, len) < 0) {
   jk_log(l, JK_LOG_ERROR, 
  @@ -564,6 +569,9 @@
ajp13_endpoint_t *p,
ajp13_operation_t *op)
   {
  + /* Up to now, we can recover */
  + op->recoverable = JK_TRUE;
  +
/*
 * First try to reuse open connections...
*/
  @@ -584,7 +592,6 @@
 * After we are connected, each error that we are going to
 * have is probably unrecoverable
 */
  - op->recoverable = JK_FALSE;
if(!connection_tcp_send_message(p, op->request, l)) {
jk_log(l, JK_LOG_ERROR, "Error sending request on a fresh 
connection\n");
return JK_FALSE;
  @@ -599,21 +606,47 @@
 * From now on an error means that we have an internal server error
 * or Tomcat crashed. In any case we cannot recover this.
 */
  - op->recoverable = JK_FALSE;
   
  - if(p->left_bytes_to_send > 0) {
  - unsigned len = p->left_bytes_to_send;
  - if(len > MAX_SEND_BODY_SZ) 
  - len = MAX_SEND_BODY_SZ;
  - if(!read_into_msg_buff(p, s, op->reply, l, len)) 
  - return JK_FALSE;
  - s->content_read = len;
  + jk_log(l, JK_LOG_DEBUG, "send_request 2: request body to send %d - request 
body to resend %d\n", 
  + p->left_bytes_to_send, jk_b_get_len(op->reply) - AJP13_HEADER_LEN);
  +
  + /*
  +  * POST recovery job is done here.
  +  * It's not very fine to have posted data in reply but that's the only easy
  +  * way to do that for now. Sharing the reply is really a bad solution but
  +  * it will works for POST DATA less than 8k.
  +  * We send here the 

RE: [PATCH] */build.sh

2001-04-19 Thread GOMEZ Henri

What about checking also the build.sh for Tomcat 3.3 :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, April 19, 2001 6:36 PM
>To: [EMAIL PROTECTED]
>Subject: [PATCH] */build.sh
>
>
>
>Hi,
>
>I found that adding the following lines to the different 
>build.sh files contained in the jakarta-tomcat-4.0 CVS module 
>makes the build.sh files cygwin friendly. 
>
># Here to show context
>if [ "$CLASSPATH" != "" ] ; then
>  CP=$CLASSPATH:$CP
>fi
>
># To be added:
>if [ "$OSTYPE" = "cygwin32" ] || [ "$OSTYPE" = "cygwin" ] ; then
>  CP=`cygpath --path --windows "$CP"`
>fi
>
>That's it. Ceki Gülcü
>



RE: CVS / mod_webapp / web-connector sub-project

2001-04-19 Thread cmanolache

On Thu, 19 Apr 2001, GOMEZ Henri wrote:

> >I think Dan is right on this one - improving the configuration 
> >of mod_jk
> >is probably the most important thing, and merging with mod_webapp and
> >porting it's protocol and config mechanism would be a good way 
> >to do that. 
> 
> I agree that integrating mod_webapp functionnalities is not 
> a priority for the 3.x branch. We could add the autoconf stuff 
> or may be also use APR which will hide all OS complexity.


Well, it is a priority - but smaller than releasing 3.3 sooner and
keeping it stable.

That's true for many other things - we should be very conservative in
adding any new feature or making any non-bug-fix change that can be done
as a separate module. 


If you think in terms of modules everything is much simpler and safe. A
revolution that implements a merge of the 2 connectors will be a module, 
same for a jasper merge, or for any new fancy features.

The user can use the new module - and if we feel the new code is
stable enough we can include it in a future release ( 3.3.1 ? ), or create
a separate distribution for it. It'll be just like the "update" feature in
many programs ( like xemacs, netbeans, mozilla ).


> The problem today, is that there is 2 version of mod_jk :
> 
> *) mod_jk in Tomcat 3.3
>   Latest code, maintainers, bugs fixed and Apache 1.3/2.0 support
> *) mod_jk in Tomcat 3.2.x
>   The same code since 3.2, no much maintainers, some bugs fixed in 3.3
>   are not in 3.2, only Apache 1.3 support.

3.2.3 is almost released. 

3.3 is getting closer - we have quite a few bugs, but most of them are
present in 3.2 also ( so no regression AFAIK, only "LATER" ). 
It is normal that the next release has more bug fixes than the previous
one.


> 
> I strongly think we must have the connectors in a separate project
> so I'll follow your proposal and start a revolution. 

Having it "separate" is good, the "project" part doesn't seem right for
now.

( at least I would be very -1 on doing the merge of adding new features in
the main tree for 3.3 - but if it is completed and works fine before the 
next release we should be able to include both modules ).

> * native code extracted => connector
> * java code moved from tomcat core/utils => org.apache.connector 

+1

Maybe httpserver ( to match the httpclient in commons ) ?
( I think it should be org.apache.tomcat. - we shouldn't add new
org.apache namespaces )   

Costin




RE: [PATCH] */build.sh

2001-04-19 Thread cmanolache

On Thu, 19 Apr 2001, GOMEZ Henri wrote:

> What about checking also the build.sh for Tomcat 3.3 :)

What about removing the build.sh/build.bat completely ( at least from
3.3).

It used to be a workaround, when ant didn't had support for classpath. 

Proposal: remove build.sh/build.bat, use "ant".

Costin




RE: [PATCH] */build.sh

2001-04-19 Thread Craig R. McClanahan



On Thu, 19 Apr 2001 [EMAIL PROTECTED] wrote:

> On Thu, 19 Apr 2001, GOMEZ Henri wrote:
> 
> > What about checking also the build.sh for Tomcat 3.3 :)
> 
> What about removing the build.sh/build.bat completely ( at least from
> 3.3).
> 
> It used to be a workaround, when ant didn't had support for classpath. 
> 
> Proposal: remove build.sh/build.bat, use "ant".
> 

+1

Our experience with this in both Commons and Struts has been quite
good.  I will be proposing a change to the build procedures for Tomcat 4
to go this way next week.

> Costin
> 
> 

Craig





Re: Tester (was: cvs commit: ...etc)

2001-04-19 Thread Amy Roh



"Craig R. McClanahan" wrote:

> On Wed, 18 Apr 2001, Amy Roh wrote:
>
> > btw, a few tests in the tester fail on my environment.  I get "Unexpected
> > end of file from server" under Authentication, Jndi, and HttpSession tests
> > which result in failing a few of the tests with java.net.SocketException.
> > Is this normal behavior?
> >
> > Amy
> >
>
> No it's not.  I get 100% passing on Linux and Win98, for both JDK 1.2 and
> 1.3.  What are the details of your environment?  Which individual tests
> are failing?  Have you added the "manager" role to the "tomcat" user in
> conf/tomcat-users.xml?
>

I did a clean build and passed all.  All is good.  :-)

Amy

>
> Craig
>
> >
> > > On Wed, 18 Apr 2001, Amy Roh wrote:
> > >
> > > > > I had problems getting the tester going (and gave up on it a few times
> > > > previously),
> > > > > because it seems that, on win2k at least, there are some manual steps
> > > > which
> > > > > must be carried out. In particular, tester.bat tells the code to
> > expect
> > > > tester.xml
> > > > > to be in %catalina_home%/bin, but the build process does not copy it
> > > > there.
> > > > > The same is true for the tester webapp. Should this be handled by the
> > > > build,
> > > > > or documented, or did I miss something?
> > > >
> > > > Yeah, I initially had problems running tester as well since build itself
> > > > doesn't copy files into %catalina_home%/bin (and manually doing it
> > sucks).
> > >
> > > Feel free to fix the default build target :-)
> > >
> > > Craig
> > >
> >
> >

--
Amy Roh
Java 2 Enterprise Edition
Sun Microsystems, Inc.
(408) 517-6837





cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler TagBeginGenerator.java

2001-04-19 Thread horwat

horwat  01/04/19 16:43:17

  Modified:jasper/src/share/org/apache/jasper/compiler
TagBeginGenerator.java
  Log:
  For example, in the jakarta-taglibs xsl tag:
  
  
  
  A bug resulted when the first element value "<%= xmlFile %>" matched up with the 
first attribute's properties. In this case, it would have been "nameXml" as defined in 
the xsl.tld. "nameXml" has its rtexprvalue property set to false.
  
  The bug fix makes sure that attribute properties match up with the correct element.
  
  Bugzilla: #811
  
  Revision  ChangesPath
  1.9   +13 -6 
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagBeginGenerator.java
  
  Index: TagBeginGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagBeginGenerator.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- TagBeginGenerator.java2001/02/04 01:05:35 1.8
  +++ TagBeginGenerator.java2001/04/19 23:43:17 1.9
  @@ -217,13 +217,20 @@
   Class c[] = m.getParameterTypes();
   // assert(c.length > 0)
   
  -if (attributes[i].canBeRequestTime() && 
  -JspUtil.isExpression(attrValue, isXml)) {
  -attrValue = JspUtil.getExpr(attrValue, isXml);
  -} else {
  -attrValue = convertString(c[0], attrValue, writer, attrName,
  -  tc.getPropertyEditorClass(attrName));
  +// match tld defined attribute to its element value
  +for(int j = 0; j < attributes.length; j++) {
  +if (attrs.getLocalName(i).equals(attributes[j].getName())) {
  +if (attributes[j].canBeRequestTime() && 
  +JspUtil.isExpression(attrValue, isXml)) {
  +attrValue = JspUtil.getExpr(attrValue, isXml);
  +} else {
  +attrValue = convertString(c[0], attrValue, writer, 
attrName,
  +  
tc.getPropertyEditorClass(attrName));
  +}
  +}
   }
  +
  +
   writer.println(thVarName+"."+m.getName()+"("+attrValue+");");
   }
   }
  
  
  



cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler TagBeginGenerator.java

2001-04-19 Thread horwat

horwat  01/04/19 17:00:59

  Modified:jasper/src/share/org/apache/jasper/compiler
TagBeginGenerator.java
  Log:
  A tag handler that implemenst BodyTag is treated as one that implements Iteration 
tag except that doStartTag method can return SKIP_BODY, EVAL_BODY_INCLUDE, 
EVAL_BODY_BUFFERED. Remove the run-time error message caused if EVAL_BODY_INCLUDE is 
returned.
  
  Bugzilla: #1344
  
  Revision  ChangesPath
  1.10  +1 -7  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagBeginGenerator.java
  
  Index: TagBeginGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagBeginGenerator.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- TagBeginGenerator.java2001/04/19 23:43:17 1.9
  +++ TagBeginGenerator.java2001/04/20 00:00:59 1.10
  @@ -348,13 +348,7 @@
   //Perhaps, I'll just define an inner classes as necessary for these
   //types of exceptions? -akv
   
  -if (implementsBodyTag) {
  -writer.println("if ("+evalVar+" == Tag.EVAL_BODY_INCLUDE)");
  -writer.pushIndent();
  -writer.println("throw new JspTagException(\"Since tag handler 
"+tc.getTagHandlerClass()+
  -   " implements BodyTag, it can't return 
Tag.EVAL_BODY_INCLUDE\");");
  -writer.popIndent();
  -} else {
  +if (!implementsBodyTag) {
   writer.println("if ("+evalVar+" == BodyTag.EVAL_BODY_BUFFERED)");
   writer.pushIndent();
   writer.println("throw new JspTagException(\"Since tag handler 
"+tc.getTagHandlerClass()+
  
  
  



3.2.2b3 mod_jk gets stuck in readFully

2001-04-19 Thread Pogo Com

I've been testing Tomcat 3.2.2b3 and Apache 1.3 on Solaris, connected with
mod_jk.  Things are generally working, but there is a serious problem that
occurs under load.

The problem is that certain Apache children get stuck talking to Tomcat.  The
children are always requesting JSP pages.  Using the Apache status display, a
stuck child looks like:

141-0 29388 0/1/1 W 0.00 1092 0 0.0 0.01 0.01 154.x.x.x bingoe01.mysite.com
GET /ad/loading-applet.jsp?tabl=1&site=pogo&scrn=motormind&anam 

It is not uncommon to have half of the Apache children stuck like this.  On
the tomcat side, the threads appear at this location:

"Thread-256" (TID:0xd020a0, sys_thread_t:0xd01fd8, state:R, thread_t: t@263,
threadID:0x63cb1dd8, stack_bottom:0x63cb2000, stack_si
ze:0x2) prio=5

[1] java.net.SocketInputStream.socketRead(Native Method)
[2] java.net.SocketInputStream.read(SocketInputStream.java:85)
[3]
org.apache.tomcat.service.connector.TcpConnector.receiveFully(TcpConnector.java:148)
[4]
org.apache.tomcat.service.connector.TcpConnector.receive(TcpConnector.java:118)
[5]
org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:109)
[6] org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:393)
[7] org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:475)
[8] java.lang.Thread.run(Thread.java:478)

Generally, the number of threads inside receiveFully matches the number of
stuck Apache children.

Losing Apache children like this eventually starves the server of ability to
do useful work, even though there is a lot of idle time on the machine.  Is
this a known issue?

Thanks,
Bill Lipa


__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/



Problem with "isEncodeable"

2001-04-19 Thread Luise Massimo

Sorry i forget to say that if i change the url to which i redirect requests
into "/servizi/templates/page.jsp" the encodeURL go right but the forward
does not go (i get 404).





Hi all.
I have noticed a strange thing with isEncodeable/toAbsolute
(HttpServletResponseFacade.java) in Tomcat 3.2.1.
I'm using encodeURL into a RequestDispatcher.forward and i'm forwarding a
request from a servlet to a JSP.
The context is "/servizi" and he URL to which i'm forwarding the request is
"/templates/page.jsp", which is a directory inside the context "/servizi"
(so the URL is relative to the context).

The URL i'm forwarding requests is changed by toAbsolute into
"http://server/templates/page.jsp" which does not contain the servlet
context (the right for me it would be
"http://server/servizi/templates/page.jsp").

The method isEncodeable test if the URL start with the context path, so in
my case this does not happens !!

String contextPath = request.getContext().getPath();
if ((contextPath != null) && (contextPath.length() > 0)) {
String file = url.getFile();
if ((file == null) || (!file.startsWith(contextPath))
return( false );
}

contextPath = "/servizi"
url=http://server/templates/page.jsp"
url.getFilte() = "/templates/page.jsp"

The URL is changed by toAbsolute method with:

Request req = response.getRequest();
String requrl = HttpUtils.getRequestURL( request.getFacade() ).toString();
try {
url = new URL( new URL( requrl ), location );
}


HttpUtils.getRequestURL(..) = http://server/servizi/servlet/myServlet


All this it's to explain that the encodeURL does not work when used inside
RequestDispatcher.forward().

Does anyone can explain me what i'm doing of wrong ?

Thanks in advance.  Max




cvs commit: jakarta-tomcat-4.0/tester/src/bin tester.xml

2001-04-19 Thread amyroh

amyroh  01/04/19 21:37:15

  Modified:tester/src/bin tester.xml
  Log:
  Add additional SSI tests including fsize & config.
  
  Revision  ChangesPath
  1.33  +40 -0 jakarta-tomcat-4.0/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- tester.xml2001/04/18 20:40:31 1.32
  +++ tester.xml2001/04/20 04:37:13 1.33
  @@ -802,6 +802,46 @@
request="${context.path}/SSIInclude08.shtml" debug="${debug}"
 golden="${golden.path}/SSIInclude02.txt"/>
   
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +  
 
   
   
  
  
  



cvs commit: jakarta-tomcat-4.0/tester/web/golden SSIConfig01.txt SSIConfig03.txt SSIFsize02.txt

2001-04-19 Thread amyroh

amyroh  01/04/19 21:37:48

  Added:   tester/web SSIConfig01.shtml SSIConfig03.shtml
SSIFsize01.shtml SSIFsize02.shtml SSIFsize03.shtml
SSIFsize04.shtml SSIFsize05.shtml SSIFsize06.shtml
SSIFsize07.shtml SSIFsize08.shtml index.shtml
   tester/web/golden SSIConfig01.txt SSIConfig03.txt
SSIFsize02.txt
  Log:
  Add additional SSI tests including fsize & config.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-4.0/tester/web/SSIConfig01.shtml
  
  Index: SSIConfig01.shtml
  ===
  
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/SSIConfig03.shtml
  
  Index: SSIConfig03.shtml
  ===
  
  
  
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/SSIFsize01.shtml
  
  Index: SSIFsize01.shtml
  ===
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/SSIFsize02.shtml
  
  Index: SSIFsize02.shtml
  ===
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/SSIFsize03.shtml
  
  Index: SSIFsize03.shtml
  ===
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/SSIFsize04.shtml
  
  Index: SSIFsize04.shtml
  ===
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/SSIFsize05.shtml
  
  Index: SSIFsize05.shtml
  ===
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/SSIFsize06.shtml
  
  Index: SSIFsize06.shtml
  ===
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/SSIFsize07.shtml
  
  Index: SSIFsize07.shtml
  ===
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/SSIFsize08.shtml
  
  Index: SSIFsize08.shtml
  ===
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/index.shtml
  
  Index: index.shtml
  ===
   

   Config command examples 


  
  
  Setting errormsg using:  
   
  
  Trying to access non-existent "foo.shtml" using  
  
  
  
  
  
  
  
  Using 
  
This file ( index.shtml::size-> 2665) is 

   
bytes in size. 
  
  
  
Setting sizefmt to abbrev using : 
  
  
  
  
  
  Size of file "index.shtml ( size->2665)" using sizefmt=abbrev ->
  
  
   
  Size of file "saveindex.shtml(size->464)" using  :   ->
  
  
  
  Size of file "check1.shtml(size->1000)" using  :   ->
  
  
  
  Size of file "check2.html(size->1001)" using  :   ->
  
  
  
  Size of file "check3.shtml(size->1499)" using  :   ->
  
  
  
  Size of file "check4.shtml(size->1500)" using  :   ->
  
  
  
  Size of file "check5.shtml(size->1501)" using  :   ->
  
  
  
  Size of file "checkme ( size->1535)" using :  -> 
  
  
  
  Size of file "check5.html(size->1536)" using  :   ->
  
  
  
  Size of file "check55.html(size->1537)" using  :   ->
  
  
  
  Size of file "check555.html(size->1538)" using  :   ->
  
  
  
  Size of file "check.html(size->1539)" using  :   ->
  
  
  
  Size of file "check6.shtml(size->1988)" using  :   ->
  
  
  
  Size of file "check7.shtml(size->1999)" using  :   ->
  
  

  
  
  
  
timefmt Tests : 
  
   
Using  

  
Day ->  
, 
   
Using 
 

Day of Month -> 
 
  

Using 
 

Month(full) ->  
 
  
 
Using 
 

Month(abbreviated) ->  
 
  
 
Using 
 

 

Which version of JAXP ?

2001-04-19 Thread Pilho Kim

Hi, 

I have builded and tested Tomcat 4.0 beta 3.

But I guess that the file %CATALINA_HOME%/server/lib/jaxp.jar is invalid.
The filesize of jasp.jar is about 6 KB.
(Note that the filesize of jaxp.jar of JAXP 1.1 is about 28 KB.)
It means that the JAXP version is 1.0.1.
With this jaxp.jar I have failed to start catalina.


The error message is as follows:

Catalina.start: java.lang.ClassCastException:
com.sun.xml.parser.SAXParserFactor
yImpl
java.lang.ClassCastException: com.sun.xml.parser.SAXParserFactoryImpl
at
javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:
82)
at
org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:224)
at org.apache.catalina.startup.Catalina.start(Catalina.java:657)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:627)
at org.apache.catalina.startup.Catalina.process(Catalina.java:177)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:177)


So I have removed the file %CATALINA_HOME%/server/lib/jaxp.jar
and succeeded to start catalina.

In other way, I have put both of  crimpson.jar and jasp.jar of JAXP 1.1
at %CATALINA_HOME%/server/lib/ and succeeded to start catalina, too.


It should be clear which version of JAXP Catalina uses.
(JAXP 1.1 ?  or  JAXP 1.0.1 ?)


Thanks,
Kim






I made some changes in Tomcat's sources....

2001-04-19 Thread Arkadiusz Rychlinski

I made some changes in (maybe not exacly) Tomcat's sources. How can I make
it public?

I've added support for encoding different than ISO-8859-1 in form data from
GET/POST request and processing multipart forms and file upload.

What should I do to present these changes to tomcat team?



Arek





BEGIN:VCARD
VERSION:2.1
N:Rychliñski;Arkadiusz
FN:Arkadiusz Rychliñski
ORG:Exell - Systemy Informatyczne;Programiœci
TITLE:Projektant
TEL;WORK;VOICE:(0-22) 862-53-55 (w. 113)
TEL;WORK;FAX:(0-22) 862-53-55
ADR;WORK:;;ul. Narbutta 47/26;Warszawa;Mazowieckie;02-536;Polska
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:ul. Narbutta 47/26=0D=0AWarszawa, Mazowieckie 02-536=0D=0APolska
URL:
URL:http://www.exell.com.pl
KEY;X509;ENCODING=BASE64:
MIIDZjCCAs+gAwIBAgIDAd0tMA0GCSqGSIb3DQEBBAUAMEMxCzAJBgNVBAYTAlBMMRswGQYD
VQQKExJVbml6ZXRvIFNwLiB6IG8uby4xFzAVBgNVBAMTDkNlcnR1bSBMZXZlbCBJMB4XDTAx
MDEwMjEwMDg0MVoXDTAxMDcwMTEwMDg0MVowgcgxCzAJBgNVBAYTAlBMMRQwEgYDVQQIEwtN
YXpvd2llY2tpZTEXMBUGA1UEBxMOU3RhcmUgWmFsdWJpY2UxFjAUBgNVBAoTDVByaXZhdGUg
RW1haWwxKTAnBgNVBAsTIFVuaXpldG8ocikgUGVyc29uYWwgQ2VydGlmaWNhdGVzMR0wGwYD
VQQDExRBcmthZGl1c3ogUnljaGxpbnNraTEoMCYGCSqGSIb3DQEJARYZYS5yeWNobGluc2tp
QGV4ZWxsLmNvbS5wbDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDqQqac/safN4WBz4eYyPZb
Tv/qDLK/CBx+ALtkB0HfG3QPdVIjU3l5kVSgS1tvkSYAnrUQuBl7Hc3oh/eNMGIFAgMBAAGj
ggEkMIIBIDAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgNVHR8EKTAnMCWgI6Ah
hh9odHRwOi8vY3JsLmNlcnR1bS5wbC9jbGFzczEuY3JsMIHNBgNVHSAEgcUwgcIwgb8GCyqE
aAGG9ncCAgEBMIGvMCQGCCsGAQUFBwIBFhhodHRwOi8vd3d3LmNlcnR1bS5wbC9DUFMwgYYG
CCsGAQUFBwICMHowGRYSVW5pemV0byBTcC4geiBvLm8uMAMCAQEaXUVtYWlsIElEIGZvciBQ
ZXJzb25hIE5vdCBWYWxpZGF0ZWQuIENvcHlyaWdodCAoYykgMTk5OSBVbml6ZXRvIFNwLiB6
IG8uby4gQWxsIHJpZ2h0cyByZXNlcnZlZDANBgkqhkiG9w0BAQQFAAOBgQCDB0lvf1TK4TF2
OSq/TqxGCE3bGbB8XpX0uYTedBgoSHZgABdMp8z7uaFzvo5Bx0DETtt8SmtGW6jnnM4HgQL3
cWmuKkMnLH6cJA7IDF1utHKnvjh9DxfdOGsvibizVzwN6TWBpXiv/wtURGX6rE1VlUgIB6/z
nsMRwTtOet37do==


KEY;X509;ENCODING=BASE64:
MIIC3TCCAkagAwIBAgIBAjANBgkqhkiG9w0BAQQFADCBpzELMAkGA1UEBhMCUEwxFDASBgNV
BAgTC01hem93aWVja2llMQ8wDQYDVQQHEwZXYXJzYXcxJjAkBgNVBAoTHUV4ZWxsIC0gU3lz
dGVteSBJbmZvcm1hdHljem5lMRQwEgYDVQQLEwtEZXZlbG9wbWVudDERMA8GA1UEAxMIRXhl
bGwgQ0ExIDAeBgkqhkiG9w0BCQEWEWluZm9AZXhlbGwuY29tLnBsMB4XDTAxMDQxMzExMjIw
MloXDTAyMDQxMzExMjIwMlowSTEdMBsGA1UEAxMUQXJrYWRpdXN6IFJ5Y2hsaW5za2kxKDAm
BgkqhkiG9w0BCQEWGWEucnljaGxpbnNraUBleGVsbC5jb20ucGwwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBAMAL1qpYTqG8KWHxs+9z5y9AsmM9J8O9r4BdHnQ1ex2ChtnCboY7/Wte
d43aN4KGXa14yttq3kJBwnezAQyP3TCcD9xu6PDgxeveo13iV+QMIOpr5AFmZwon/5f1vATa
cNnFd5E1w03fycPHe++kDXN35RahaX167AS8yGudch+hAgMBAAGjdjB0MCQGA1UdEQQdMBuB
GWEucnljaGxpbnNraUBleGVsbC5jb20ucGwwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBRg
soY9yJv6SRV+dnxXo5xP2ang/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJ
KoZIhvcNAQEEBQADgYEAfrwaiAECzYTgm1tGaPkhIrKrfUy5t75qvvtPRil1kURauHaEB/Vd
cv41p4b52qvli5zEWKtPqiQeHSfEsgj7RVsfNPpxKnYgrm7w56Il/NPvCdPJtigUMOpVb7ak
eG54/z7+E9Krlr+d1mocEpcsSqGjAhaXJhexRdZ1p/2m+Dx=


EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20010420T065243Z
END:VCARD



Turn off cookies, enable URL Rewriting?

2001-04-19 Thread Sheldon Wosnick

I am working with Tomcat 4.0 and I just wanted to know whether it is 
possible to turn off cookies and use URL rewriting instead. There logically 
must be a way through the configuration but how this change can actually be 
done in the config files is a mystery.

Any help is appreciated,

Sheldon Wosnick

_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.




[PATCH] context ClassLoader not set before init(ServletConfig)

2001-04-19 Thread Kyle F. Downey

I think there's another place the context ClassLoader should be
set: right before init(ServletConfig) is called. Attached is a
patch that sets the current Thread's ContextClassLoader and then to the 
servlet context's ClassLoader and restores it after init() completes.
This ensures that the webapp is able to use the context ClassLoader
to refer to its own ClassLoader during init() phase as well as 
service(). I tested this with the latest from CVS, and it worked.

--kd

Index: StandardWrapper.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.18
diff -u -r1.18 StandardWrapper.java
--- StandardWrapper.java2001/04/07 22:33:01 1.18
+++ StandardWrapper.java2001/04/19 16:24:29
@@ -749,6 +749,8 @@
(sm.getString("standardWrapper.missingLoader", getName()));
}
ClassLoader classLoader = loader.getClassLoader();
+ 
ClassLoader oldCtxClassLoader = Thread.currentThread().
+ 
 getContextClassLoader();

  // Special case class loader for a Catalina internal servlet
if (isContainerServlet(actualClass)) {
@@ -800,6 +802,7 @@
try {
instanceSupport.fireInstanceEvent(InstanceEvent.BEFORE_INIT_EVENT,
 
  servlet);
+ 
 Thread.currentThread().setContextClassLoader(classLoader);
servlet.init((ServletConfig) this);
instanceSupport.fireInstanceEvent(InstanceEvent.AFTER_INIT_EVENT,
 
  servlet);
@@ -821,6 +824,9 @@
// said so, so do not call unavailable(null).
throw new ServletException
(sm.getString("standardWrapper.initException", getName()), f);
+ 
} finally {
+ 
 // restore the context ClassLoader
+ 
 Thread.currentThread().setContextClassLoader(oldCtxClassLoader);
}

// Register our newly initialized instance