cvs commit: jakarta-tomcat/src/native/jk jk_ajp13.c

danmil 01/01/29 21:47:48 Modified:src/native/jk Tag: tomcat_32 jk_ajp13.c Log: Fixing off by one error for expanding the status code integer into full name. (Doesn't actually visibly break anything in the 3.2 branch, because of a mistake on the Java side in Ajp13ConnectorR

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

danmil 01/01/29 21:38:36 Modified:src/native/mod_jk/common jk_ajp13.c Log: Fixing off by one error for expanding the status code integer into full header name. Was breaking on WWW-Authenticate headers. Revision ChangesPath 1.4 +4 -3 jakarta-tomcat/src/nati

Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?

Thom May wrote: > I posted a patch against the workers howto to the list a week or so ago, but > I'd love to help with documentation. Sorry that it took me a while to get around to applying that patch. Any help with the documentation would be great. I don't have the best sense of how much of it

cvs commit: jakarta-tomcat/src/doc Tomcat-Workers-HowTo.html

danmil 01/01/29 20:29:00 Modified:src/doc Tag: tomcat_32 Tomcat-Workers-HowTo.html Log: Cleaning up some basic mistakes in descriptions of different types of workers. Contributed by Thom May ([EMAIL PROTECTED]). Revision ChangesPath No revision

cvs commit: jakarta-tomcat/src/doc Tomcat-Workers-HowTo.html

danmil 01/01/29 20:27:38 Modified:src/doc Tomcat-Workers-HowTo.html Log: Cleaning up some basic mistakes in descriptions of different types of workers. Contributed by Thom May ([EMAIL PROTECTED]). Revision ChangesPath 1.2 +7 -7 jakarta-tomcat/src/doc/

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service/connector Ajp13ConnectorRequest.java

danmil 01/01/29 20:17:53 Modified:src/share/org/apache/tomcat/service/connector Tag: tomcat_32 Ajp13ConnectorRequest.java Log: Fixed (yet another) bug with File Upload. Tomcat was returning signed data to servlets (via ServletInputStream.read()), which wa

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util RequestUtil.java

remm01/01/29 20:14:49 Modified:catalina/src/share/org/apache/catalina/connector HttpRequestBase.java catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java catalina/src/share/org/apache/ca

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java

danmil 01/01/29 20:13:14 Modified:src/share/org/apache/tomcat/modules/server Ajp13.java Log: More bug fixes from Keith Wannamaker ([EMAIL PROTECTED]): - Enabled http status text - Fixed (yet another) bug with File Upload. Tomcat was returning signed data to servlets (v

Re: problem in using SecurityManager with tomcat

Hi, > 1. Edited server.xml to use Policy: > > 2. Edited tomcat.policy > 3. Started tomcat with the "-security" option. >>> tomcat.sh start -security Are you sure you granted the right permission the the right codebase ? It is very important to have TOMCAT_HOME set before running the server

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java

remm01/01/29 19:50:09 Modified:catalina/src/share/org/apache/catalina/servlets DefaultServlet.java Log: - Will now encode all unsafe characters on the URL. Revision ChangesPath 1.22 +84 -28 jakarta-tomcat-4.0/catalina/src/share/org/ap

Re: Tomcat 4 Jasper ClassLoading changes to support SecurityManager

I have done some work in this area that may be of interest. I've created a package of 8 classes that extend the Jasper compiler (as of Tomca 3.2.1) to provide: - dynamic recompiling/reloading of jsp pages - recursive detection of changes to static includes - support for inner classes - custo

Re: TOMCAT + mod_jk or mod_webapp

Pier, Glad to hear that you're willing/interested in integrating the mod_webapp protocol into mod_jk. I don't know exactly how easy it would be, but I think it *would* be a big win (you'd get lots of tested C code, load balancing for free, easy upgrade path for users, etc). I've recently discov

problem in using SecurityManager with tomcat

Hi, I am having problems in using the SecurityManager with tomcat 3.2.1. There seems to be a bug or documention mismatch. Please let me know if you have any ideas on fixing this: I am using Tomcat 3.2.1 to run a servlet that acts as an RMI client. Based on the documentation (http://jakarta.ap

Re: mod_jk.so build problems with SunOS 5.6

sorry.I don't know more UNIX so I don't know how can I do when I got error message. my work station: Solaris 2.6 Apache1.3.14 TOMCAT3.2.1 what I done: apxs -o mod_jk.so -DSOLARIS -I../jk -I${JAVA_HOME}/include -I${JAVA_HOME}/include/so laris -L/lib -lposix4 -c *.c ../jk/*.c and I

RE: Thread-safety

>Depends on the JVM - later JVMs from sun actually deal better with creation >of small short-lived objects. Better, but its still a significant performance issue. See my article in JavaWorld which has some hard numbers for this across JVMs: http://www.javaworld.com/javaworld/jw-11-2000/jw-111

RE: [PROPOSAL] Tomcat 3.3 Release Plan

> -Original Message- > From: Sam Ruby > To: [EMAIL PROTECTED] > Sent: 1/29/01 3:35 PM > Subject: RE: [PROPOSAL] Tomcat 3.3 Release Plan > > Larry Isaacs wrote: > > > I think we will need a "go" from the PMC before the vote can > > take place. Issues about voting I don't think have been >

RE: [PATCH] Ajpv13 webdav support

Aha, I see. I'll look forward to 3.3 then. Thanks, Jamey -Original Message- From: Keith Wannamaker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 29, 2001 12:54 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [PATCH] Ajpv13 webdav support In 3.2 I don't think this

RE: [PATCH] Ajpv13 webdav support

In 3.2 I don't think this is possible without changing code. Try searching for ApacheConfig. In 3.3, the auto-gen classes are now modules to be specified in server.xml as ContextInterceptors. Currently only Apache is enabled, and can be disabled by modifying server.xml. Keith -Original Mess

RE: [PATCH] Ajpv13 webdav support

I know this is rather tangential but I was unaware that it was possible to turn on and off the auto generation of configuration files by Tomcat. How do I control this? Many thanks, Jamey -Original Message- From: danmil [mailto:danmil]On Behalf Of Dan Milstein Sent: Sunday, Januar

[PATCH] enable Ajpv13 http status text

This patch enables ajpv13 http status text http://www.apache.org/~keith/jk/status.txt Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]

RE: [PROPOSAL] Tomcat 3.3 Release Plan

Larry Isaacs wrote: > > I think we will need a "go" from the PMC before the vote can > take place. Issues about voting I don't think have been > finalized. While issues about voting have not been finalized (and like code, may never be "final"), this has not held up other votes on releases in the

[PATCH] Ajpv13 read() bug

Ajpv13's read() is returning signed data to the servlet. This is a problem (especially with, how did you guess, binary file uploads) because byte 0xFF will be mistaken as EOF. The solution is to return legal data bytes unsigned by casting to char. The 3.3 patch is here- http://www.apache.org/~

RE: mod_jk.so build problems with SunOS 5.6

Here's a makefile that's been working for me on Solaris 2.7. -Jamey -Original Message- From: Timothy S. Tsai [mailto:[EMAIL PROTECTED]] Sent: Monday, January 29, 2001 8:03 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_jk.so build problems with SunOS 5.6 Hello, Has any

RE: mod_jk.so build problems with SunOS 5.6

Check apxs to see if the shared object-related definitions are there. The error looks like your linker was not defined, which is a common problem in this respect. What version of Apache? Keith -Original Message- From: Timothy S. Tsai [mailto:[EMAIL PROTECTED]] Sent: Monday, January 29,

Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?

* Dan Milstein ([EMAIL PROTECTED]) wrote on Fri Jan 26, 2001 at 01:27:09PM -0500: > Thom, > > Thanks for the feedback. > > 1) The mod_jk howto / vhosts > > The mod_jk user docs are (as far as I can tell) kind of a mess. I have a > medium-term goal of overhauling them and cleaning them up, bu

Re: Thread-safety

on 1/29/01 3:52 AM, "Klemme, Robert, myview" <[EMAIL PROTECTED]> wrote: > i cannot believe that people at sun would risk these consequences, > do they? LOL! That is the funniest thing I have read in a long time! :-) People are not perfect and they make human errors. This is clearly one of them

Re: mod_jk.so build problems with SunOS 5.6

Hello, Has anyone gotten an answer for this post? I ran into the same problem also. tt At 03:45 PM 1/29/01 +0900, you wrote: >hi, >I failed to build mod_jk.so.what can tell me how can I do. >I get a error message when I use apxs >-o mod_jk.so jk_worker.o jk_util.o jk_uri_worker_map.o jk_so

RE: Thread-safety

thank you paul to point me at an omission. > -Original Message- > From: Paul Speed [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 29, 2001 11:54 AM > To: [EMAIL PROTECTED] > Subject: Re: Thread-safety > [...] > The problem is that the point of the code block is to be > sure tha

Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?

* Dan Milstein ([EMAIL PROTECTED]) wrote on Fri Jan 26, 2001 at 01:27:09 -0500: > Thom, > > Thanks for the feedback. > > 1) The mod_jk howto / vhosts > > The mod_jk user docs are (as far as I can tell) kind of a mess. I have a > medium-term goal of overhauling them and cleaning them up, but

Re: Thread-safety

"Klemme, Robert, myview" wrote: > > hi all! > > > -Original Message- > > From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]] > > Sent: Friday, January 26, 2001 6:14 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Thread-safety > > > > > > > Does this mean that the following code would be t

RE: FW: Thread-safety

hi all! > -Original Message- > From: Brian Goetz [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 27, 2001 3:15 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: FW: Thread-safety > [...] > Assuming jspx_init() might create an object (what else would > an init() > r

RE: Thread-safety

hi all! > -Original Message- > From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 26, 2001 6:14 PM > To: [EMAIL PROTECTED] > Subject: Re: Thread-safety > > > > Does this mean that the following code would be thread safe? > NO, it's not! sorry to intervene here.