RE: Error? org/apache/ajp/tomcat4/Ajp13Connector createProcessor()

seems like a bug. either way, I believe the org.apache.ajp package is deprecated. > -Original Message- > From: eric scroger [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 02, 2002 12:40 PM > To: Tomcat Developers List > Subject: Error? org/apache/ajp/tomcat4/Ajp13Connector > crea

RE: AJP13,Tomcat404 and SSL

the ajp13 protocol does not support ssl. the "isssl" flag you are refering to is probably the ajp request attribute that indicates whether or not the request to the web server was using https. > -Original Message- > From: Gernot Lepuschitz [mailto:[EMAIL PROTECTED]] > Sent: Thursday,

RE: servlet authentication

i could be wrong, but i think once you call sendError(), the response is committed and you cannot set any more headers. try reversing the order of the sendError()/setHeader() calls: response.setHeader("WWW-Authenticate", "BASIC realm=\"test\""); response.sendError(response.SC_UNAUTHORIZED);

RE: isapi_redirector2 build using static APR

> > > IMO it would be better to build the non Apache connectors using static > APR builds. That way we don't need to ship the extra dll's with the > connector. > The dll builds are ok for mod_jk2 since Apache is already there. > +1 (speaking more as a user than a developer these days ...) > I

RE: [PROPOSAL] tag mod_jk 1.2.1

+1 > -Original Message- > From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 03, 2002 5:16 AM > To: Tomcat Developers List > Subject: [PROPOSAL] tag mod_jk 1.2.1 > > > Hi to all, > > What about tagging the current mod_jk (may be after the latest > lb patches) to 1.2.1 ? >

[coyote/tomcat 3.3.1] content-length header never set?

i was playing around with coyote (v1.0-b8) and tomcat 3.3.1 and i noticed that setting a content-length header had absolutely no effect. in other words, if i set a content-length header in a servlet, the http client would never see this header. i dug around through the code a little and disco

RE: [4.1.0] Anyone testing it ?

> > > i've done some minimal testing. i see the following exception > > a lot, but that's about it: > > The JMX stuff doesn't like you having a custom component > defined in your > server.xml (you do have one, right ?). So the exception you > see indicates > the JMX features, including the ad

RE: [4.1.0] Anyone testing it ?

i've done some minimal testing. i see the following exception a lot, but that's about it: ServerLifecycleListener: processContainerAddChild: MBeanException java.lang.Exception: ManagedBean is not found with NonLoginAuthenticator at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBean

RE: How can I install Tomcat 4.0 as a plug-in of IIS 5.1?

at one point there was a tomcat-util.jar that was missing some resource bundles (some LocalStrings.properties files) i can't remember exactly what the error(s) looked like for this, but you might try the latest tomcat 4.0.4 beta 2 release. -kevin. > -Original Message- > From: Luca

RE: ISAPI or IIS ?

i think the isapi directory was an experiment that was never followed through on. pretty sure you want to go with the stuff in the iis directory. i don't think you need both. -kevin. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 02, 2

RE: [VOTE] Tomcat 4.0.4 Beta 2 / Coyote 1.0 Beta 4 release

> Tomcat 4.0.4 Beta 2 release: > > +1 [ ] I support the release, and I will help > +0 [ ] I support the release > -0 [ ] I don't support the release > -1 [ ] I'm against the release because: > > > > +0 > Inclusion of the Coyote binaries: > > +1 [ ] Yes > -1 [ ] No > > +1 -- To unsubsc

RE: j-t-c standalone releases ?

+1 > -Original Message- > From: Remy Maucherat [mailto:[EMAIL PROTECTED]] > Sent: Sunday, March 10, 2002 4:00 PM > To: [EMAIL PROTECTED] > Subject: j-t-c standalone releases ? > > > If I remember well, it was decided some time ago it was ok to release > connectors as modules for Tomcat.

RE: Jk2 config

> > 1. JkSet NAME VALUE > Will have exactly the same behavior as NAME=VALUE in a > workers.properties file. > All settings that you can do in workers.properties today > could be done by JkSet, in httpd.conf. Or all settings > could be done in workers.properties. > > For example JkLogLevel DEBU

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java Ajp13Processor.java

seguin 02/02/20 08:12:42 Modified:jk/java/org/apache/ajp Ajp13.java RequestHandler.java jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java Ajp13Processor.java Added: jk/java/org/apache/ajp Logger.java Log: logging improvements

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/logger FileLogger.java

seguin 02/02/20 07:58:04 Modified:catalina/src/share/org/apache/catalina/logger FileLogger.java Log: keep timestamps and log messages from different threads from getting mixed up in the log file. went with the string concatentation approach instead

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/logger FileLogger.java

seguin 02/02/20 07:55:44 Modified:catalina/src/share/org/apache/catalina/logger Tag: tomcat_40_branch FileLogger.java Log: keep timestamps and log messages from different threads from getting mixed up in the log file. went with the string

RE: isapi.log

> > isapi.log: > [Wed Feb 20 12:28:19 2002] [jk_connect.c (143)]: > jk_open_socket, connect() failed errno = 61 > [Wed Feb 20 12:28:19 2002] [jk_ajp12_worker.c (152)]: In > jk_endpoint_t::service, Error sd = -1 > [Wed Feb 20 12:28:19 2002] [jk_isapi_plugin.c (716)]: > HttpExtensionProc erro

RE: [PATCH] log output can get messed up with org.apache.catalina.logger.FileLogger

> > Another way to fix this would be to use String concatenation. > The question > is, which is more expensive, the synchronization or the > String concatenation? > yeah, that occurred to me too... anybody have an answer? > This is how the code would be with String concatenation: > >

[PATCH] log output can get messed up with org.apache.catalina.logger.FileLogger

if a lot of log messages are being written to a file by a lot of threads using org.apache.catalina.logger.FileLogger, the output can get messed up so that you get things like this: [timestamp-1] [timestamp-2] [message-1] [message-2] instead of this: [timestamp-1] [message-1] [timestamp-2] [me

RE: DO NOT REPLY [Bug 5735] - HTTP connector running out of processors under heavy load

efore it calls > connector.recycle(this) to make itself available to process > another Ajp request. > that would be somewhere in Ajp13Processor.process()... if you can reproduce this consistently, can you turn up the logging for the ajp13 connector, then send me (seguin at apache.org) th

RE: Fix for AJP13 Connector Authentication Bug !!!

i've tested the patch remy checked in and it's now working for me too. very cool. thanks guys :) > -Original Message- > From: Jonathan Pierce [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 14, 2002 6:40 PM > To: [EMAIL PROTECTED] > Subject: Fix for AJP13 Connector Authentication

RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java

> > > > > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > Enviado el: viernes 15 de febrero de 2002 1:55 > > > > Perhaps is better to have explicit control over that, to disable or > > enable the control of the native auth honoring..the infamous > > tomcatAuthentication attribute.. > > I

RE: native connectors for iis and netscape/solaris available

> > >> i've uploaded native jk1 connectors for iis and netscape/solaris. > > 1. How did you build it? There were files referenced by the > Visual Studio > projects that were missing in the > jakarta-tomcat-connectors-4.0.2-src.zip. When > I tried to build it, I needed to add some files from th

native connectors for iis and netscape/solaris available

fyi - i've uploaded native jk1 connectors for iis and netscape/solaris. -- To unsubscribe, e-mail: For additional commands, e-mail:

cvs commit: jakarta-tomcat-connectors KEYS

seguin 02/02/13 11:45:11 Modified:.KEYS Log: added my key. Revision ChangesPath 1.4 +29 -0 jakarta-tomcat-connectors/KEYS Index: KEYS === RCS file: /home/cvs/jakarta-tomcat

RE: Native Connector Builds - When?

i have builds of the iis connector and the netscape connector on solaris (built on 2.6) for jk1. if somebody can tell me what i need to do - how to sign the binaries, where to upload files to - i can provide these. -kevin. -- To unsubscribe, e-mail: For additional

RE: [4.0.2] [VOTE] Final release

+0 actually, +0.5 -- i'll help out if i can :) > -Original Message- > From: Remy Maucherat [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 08, 2002 12:32 PM > To: [EMAIL PROTECTED] > Subject: [4.0.2] [VOTE] Final release > > > Hi, > > I'd like to propose to release the current cod

RE: [4.0.2] [4.1] [PROPOSAL] Binaries packaging

> > > ZIP/TGZ packaging: > [ ] Do A > [X] Do B > [ ] Do C > > -- To unsubscribe, e-mail: For additional commands, e-mail:

RE: Header handling bug in class org.apache.Ajp13

the fix for this is already in cvs and will be part of the next 4.0.2 beta release. > -Original Message- > From: Jianliang Zhao [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 04, 2002 4:26 PM > To: Tomcat-dev (E-mail) > Subject: Header handling bug in class org.apache.Ajp13 > > > I

RE: DO NOT REPLY [Bug 5647] - AJP13 connector will not pass authentication requests

> > --- Additional Comments From [EMAIL PROTECTED] 2002-01-31 > 04:14 --- > I have seen the same problem. > > I applied Adam's patch to jakarta-tomcat-connectors from CVS > updated tonight, > and HTTP Basic Authentication worked, even over SSL. This was using a > build of Tomcat 4.1-

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common HandlerRequest.java

seguin 02/01/26 06:14:35 Modified:jk/java/org/apache/jk/common HandlerRequest.java Log: port fix for bug 5861. Revision ChangesPath 1.3 +9 -1 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java Index: HandlerRequest.java

RE: mod_jk bug ?

> > > > Hi, > > > > > > I encountered the following error when accessing any java > > > servlet(e.g.http://localhost/servlet/SnoopServlet) through > > > Internet Explorer > > > of PocketPC : > > > > Maybe IE for PocketPc is sending some kind of malformed > HTTP Request? > > > > Or mod_jk native

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp RequestHandler.java

seguin 02/01/25 20:58:29 Modified:jk/java/org/apache/ajp RequestHandler.java Log: fix for bug 5861 -- NumberFormatException when non-standard HTTP header with length of 8 characters and non-numeric value is part of request. patch submitted by ruediger.pluem vodafone

RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp Ajp13.java

> > > > > > total_read = readN(in, b, H_SIZE, len); > > - > > -if (total_read <= 0) { > > + > > +// it's ok to have read 0 bytes when len=0 -- this means > > +// the end of the stream has been reached. > > +if (total_read < 0) {

RE: Native2: proposed interface change

> > What I want is to make the C code implement the > same abstractions with the java side and to get JNI to use the > same transport abstraction. > > > What do you think ? Henri, JFC, Kevin - I hope for an quick answer :-) > it sounds like you're heading towards a good deal of symmetry betwe

RE: [j-t-c] building jtc/jk (WAS RE: [Tomcat 4.0.2-b2] Java binaries uploaded)

> > as a side note, the new java code in jtc/jk still doesn't > build because of > > dependencies on things like PoolTcpConnector, which i > assume are being moved > > into jtc/util? costin? > > No, there are some unused imports. I fixed it - please check > and let me > know if there are stil

RE: [Tomcat 4.0.2-b2] Java binaries uploaded

> > > there is a problem with the tomcat-util.jar in this > distribution. it does > > not contain the message resources (LocalStings.properties, etc.). > > > > i fixed this in j-t-c/jk/build.xml on friday (the 18th), > and this file is > > tagged properly with tomcat_402_b2 > > > > did

[j-t-c] building jtc/jk (WAS RE: [Tomcat 4.0.2-b2] Java binaries uploaded)

> > > there is a problem with the tomcat-util.jar in this > distribution. it does > not contain the message resources (LocalStings.properties, etc.). > > i fixed this in j-t-c/jk/build.xml on friday (the 18th), and > this file is > tagged properly with tomcat_402_b2 > > did the tomcat

RE: [Tomcat 4.0.2-b2] Java binaries uploaded

> > I've uploaded the Java binaries for 4.0.2-b2. The official release > announcement will be made on Monday (as well as the update of > the website). > > http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.2-b2/ > > Please upload the RPMs and builds of JK and webapp ASAP. > > Th

RE: [j-t-c] post bug in latest ajp (a.k.a. jk1) code

> > > fyi: i have found and fixed this bug. > > The code for jk and webapp needs to be tagged then. Please > let me know when > it's done. > from my perspective, it's done. don't know about costin, jf, et al, though. -kevin. -- To unsubscribe, e-mail: For addi

RE: [j-t-c] HexUtils.java no longer compiles for me...

> > > without explicitly casting each entry in the HEX array to a > byte, like > this: > > > > public static final byte[] HEX = > > { (byte)'0', (byte)'1', (byte)'2', (byte)'3', > > (byte)'4', (byte)'5', (byte)'6', (byte)'7', > > (byte)'8', (byte)'9', (byte)'a', (byte)'b', >

RE: [j-t-c] post bug in latest ajp (a.k.a. jk1) code

fyi: i have found and fixed this bug. > > i think i've just run into a bug with doing posts using the > latest code > found in jtc/jk/java/org/apache/ajp that i'd really like to fix before > tomcat 4.0.2b2. > > although this code will eventually be deprecated by the stuff > costin is > wor

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp Ajp13.java

seguin 02/01/18 19:23:17 Modified:jk/java/org/apache/ajp Ajp13.java Log: reverting to previous logic - when doing Ajp13.receive(), it's ok for a packet to have 0 length and thus total_read=0 -- this means the end of the stream when the web server has been re

[j-t-c] post bug in latest ajp (a.k.a. jk1) code

i think i've just run into a bug with doing posts using the latest code found in jtc/jk/java/org/apache/ajp that i'd really like to fix before tomcat 4.0.2b2. although this code will eventually be deprecated by the stuff costin is working on, it is currently the only ajp code that will work wit

cvs commit: jakarta-tomcat-connectors/jk build.xml

seguin 02/01/18 14:02:06 Modified:jk build.xml Log: added copy task for jkutil target so that resource files from util are included in tomcat-util.jar. Revision ChangesPath 1.21 +8 -0 jakarta-tomcat-connectors/jk/build.xml Index: build.xml

[j-t-c] HexUtils.java no longer compiles for me...

without explicitly casting each entry in the HEX array to a byte, like this: public static final byte[] HEX = { (byte)'0', (byte)'1', (byte)'2', (byte)'3', (byte)'4', (byte)'5', (byte)'6', (byte)'7', (byte)'8', (byte)'9', (byte)'a', (byte)'b', (byte)'c', (byte)'d', (byt

RE: [VOTE] Tomcat 4.0.2 b2 release

> > > [X] +1 Make the release > [ ] +0 Good idea, but I can't help > [ ] -0 Bad idea > [ ] -1 No, because: > > > > > -- To unsubscribe, e-mail: For additional commands, e-mail:

RE: Todo list for 4.0.2 b2

> - Did jk from j-t-c for TC 4.0.2B2 will support load balancing ? > I didn't see the use of getJvmRoute/setJvmRoute in latest > TC 4.0 CVS. > nope :( it's never been clear to me exactly what has to be done to support load balancing, so i've never attempted to add the functionality. and i

RE: Apache mod_jk Ajp13 Tomcat 4 shutdown delay, bug?

> > I am using Apache mod_jk and Ajp13 to connect to Tomcat 4. > When shutting down Tomcat 4 it takes about 15 seconds when > using apache for the tomcat process to complete, > when using Tomcat 4 standalone shutdown and termination of > the process happens almost immediately. > > Has anyone el

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java

seguin 02/01/09 19:03:59 Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java Log: a quick patch to attempt to shorten shutdown time, plus some additional logging. the idea is simple: set a flag when the processor is handling a request, then when stopping, only

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java

seguin 02/01/09 18:53:40 Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java Log: if the connector has been stopped, don't reopen server socket when an IOException is thrown. Revision ChangesPath 1.11 +18 -6 jakarta-tomcat-connectors/jk/jav

RE: Apache mod_jk Ajp13 Tomcat 4 shutdown delay, bug?

> Now the question is... > > How hard would it be to get the worker threads to block on either the > socket OR some type of shutdown event, with either satisfying > the wait? > ideally :) i think the problem might be that once you're blocked reading on a socket, other than shutting down the s

RE: Apache mod_jk Ajp13 Tomcat 4 shutdown delay, bug?

> > I am using Apache mod_jk and Ajp13 to connect to Tomcat 4. > When shutting down Tomcat 4 it takes about 15 seconds when > using apache for the tomcat process to complete, > when using Tomcat 4 standalone shutdown and termination of > the process happens almost immediately. > > Has anyone el

RE: Todo list for 4.0.2 b2

> Here goes the list: > - Tag the JK + util directories in j-t-c with some tag > (Costin proposed > jk_14) > - Build the corresponding JK binaries i've successfully built and used the following, and can provide binaries if necessary (all jk1, btw): - iis connector - netscape connector on solar

cvs commit: jakarta-tomcat-connectors/jk/native/netscape Makefile.solaris

seguin 02/01/06 14:33:31 Modified:jk/native/netscape Makefile.solaris Log: a makefile that properly builds the nsap redirector on solaris Revision ChangesPath 1.6 +18 -14jakarta-tomcat-connectors/jk/native/netscape/Makefile.solaris Index

RE: tomcat 4.0.2 and jakarta-tomcat-connectors

> > > I think we should tag the code with jk_1_4 ( considering > the jk that was > > included with 3.1 == jk1.1, etc ). It seems jk_1_4 will work > > with 3.3, 4.0.x and 4.1 ( and the C code can be used for > 3.2.x for bug > > fixes ). > > +1. > When it's done and when you can confirm it's work

RE: tomcat 4.0.2 and jakarta-tomcat-connectors

> I think we should tag the code with jk_1_4 ( considering the > jk that was > included with 3.1 == jk1.1, etc ). It seems jk_1_4 will work > with 3.3, 4.0.x and 4.1 ( and the C code can be used for 3.2.x for bug > fixes ). > jk_1_4 is fine with me -- as long as it is tagged with something :)

tomcat 4.0.2 and jakarta-tomcat-connectors

there was a thread a couple weeks ago regarding what to do with j-t-c and tomcat 4.0.2. i believe it was decided that the 4.0.2 release would contain the same jars from j-t-c (tomcat-ajp.jar, tomcat-util.jar) as 4.0.1 did. well, i just did some quick tests with the 4.0.2-b1 dist and the head of

cvs commit: jakarta-tomcat-connectors/jk/native/iis isapi_install.vbs

seguin 02/01/03 20:35:52 Modified:jk/native/iis isapi_install.vbs Log: update to use correct dll name (isapi_redirector.dll rather than isapi_redirect.dll). Revision ChangesPath 1.2 +4 -4 jakarta-tomcat-connectors/jk/native/iis/isapi_install.vbs Index

RE: Connector compatibility between TC 4.0 and 4.1

> My thinking ( for 4.1/3.3 ) was to have j-t-c built as a > 'standalone module', a trusted/priviledged webapp that can be > deployed and > is self-contained. > can you provide some more detail? i'm quite interested in learning more. thanks, -kevin. -- To unsubscribe, e-mail:

RE: JK binaries

> > > > I'm trying to figure out what I should do with the AJP > > binaries, as the CVS > > is a bit messy at the moment (and it includes two versions of > > the sources). > > > > I can: > > - keep the current binary for b1 > > - try to upgrade, but I'd like to know which one I should use > >

RE: Connector compatibility between TC 4.0 and 4.1

> > Hi, > > After a lot of efforts, it turns out the connectors (in > j-t-c) still can't > be compiled against both the 4.0 branch and the HEAD branch > of the Tomcat > CVS. > > There are a few solutions to this: > > 1) Force the connectors to be built against the HEAD branch. > They should

RE: JK binaries

> > I'm trying to figure out what I should do with the AJP > binaries, as the CVS > is a bit messy at the moment (and it includes two versions of > the sources). > > I can: > - keep the current binary for b1 > - try to upgrade, but I'd like to know which one I should use > (and the build > sc

RE: Configuring Multiple Tomcat JVMs with Apache - Load Balancing

> > >there hasn't been done anything on that topic yet ? What's > >the status of > >loadbalacing, either mod_jk or mod_webapp ? > >Is that political due to if loadbalacing is working properly > >there won't be > >any reason to take (buy) anything else than TC ? > > State of the art is that

RE: [j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/ jk_a jp_common.c

> > The patch seems valid and the pmsg was passed for this > purpose in previous release of J-T-C but some folks > (didn't remember who) make modifications in mod_jk > part of code and the update was lost. > > Seems ok, you could commit :) > done. > This patch fix a real problem and should be

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c

seguin 01/12/17 07:29:38 Modified:jk/native/common jk_ajp_common.c Log: actually send post data beyond the first ~8K to the servlet container. if a client request contains post data, the first chunk of it is sent to the container directly after the forward request is sent

RE: org.apache.tomcat.util.net package in tomcat 3.x

> > Catch me if I'm wrong, but currently j-t-c is dependent on tomcat > code, right? I make this statement without having actually looked at > the code for the connectors. I'm going by recent discussions about > how an API change in Catalina broke the build for a connector. > some very smal

RE: org.apache.tomcat.util.net package in tomcat 3.x

> > If we move more and more logic and code in j-t-c, we may need > to have soon a specific jakarta-tomcat-connectors dev-list ? > > There is today low java in jtc, mainly native code. > If all the 'ORB' java code is moved to j-t-c, for jk, > next maybe warp, and coyote also, we'll need to split

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp RequestHandler.java

seguin 01/12/13 15:32:54 Modified:jk/java/org/apache/ajp RequestHandler.java Log: added check for and handling of empty packet in refillReadBuffer. the empty packet signals the end of the stream from the web server to the serlvet container. Revision ChangesPath

RE: [j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/jk_a jp_common.c

> > this patch fixes a problem when posting with more than about > 8K of data. it > seems that when the java side of the ajp connection has to > ask the webserver > (jk) side for more data, it goes into an infinite loop > because the next > chunk of data isn't actually sent. > > i'm 97% sure

RE: [j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/jk_a jp_common.c

> > i'm 97% sure about this patch, but since i don't know this > code as well as > > some, i'd like someone else to review it. > > This seems to be the main problem we had so far with jk - > buffers beeing > reused before they're ready. For jk2 we must make sure we have more > control over that

cvs commit: jakarta-tomcat-connectors/jk/native/iis jk_isapi_plugin.c

seguin 01/12/13 14:31:30 Modified:jk/native/iis jk_isapi_plugin.c Log: added a semi-colon so this would build (not sure how/if it was building for anybody else...). Revision ChangesPath 1.11 +2 -2 jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c

[j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c

this patch fixes a problem when posting with more than about 8K of data. it seems that when the java side of the ajp connection has to ask the webserver (jk) side for more data, it goes into an infinite loop because the next chunk of data isn't actually sent. i'm 97% sure about this patch, but s

RE: org.apache.tomcat.util.net package in tomcat 3.x

> > +1 ( part of it has already been moved ). > by part, you mean o.a.t.util.buf|collections|http|res, right? > But if we do that, I would propose to _move_ it, not copy. > ideally, you'd move the rcs archives to maintain history. however, doing that would presumably break all tomcat 3.x bu

RE: Jk2: error handling and method signatures

> One more change I want to do in jk2 is better error handling. > Most of us > spent enough time with java that using an 'int' is very > uncomfortable :-) > error handling good :) whether this is done by return codes, exceptions, etc., personally, i don't care. what i do care about is consis

org.apache.tomcat.util.net package in tomcat 3.x

it seems like a bunch of the stuff in the org.apache.tomcat.util.net package in tomcat 3.x would be useful outside the scope of tomcat 3. most notably, things like TcpConnection, TcpConnectionHandler, PoolTcpEndpoint. what would people think about moving (or at least copying for now) this packag

tomcat 4 and response buffer size

i just happened to notice that the behaviour of tomcat 4 response buffers might not be as expected with respect to buffer size. below is some code from org/apache/catalina/connector/ResponseBase.java: --- snip --- public void write(byte b[], int off, int len) throws IOException { if

RE: [j-t-c] ajp and headaches

> > I think we agreed ( Henri had some doubts ) that ajp14 will > consist only > on additional messages, but all the low-level messaging stuff will be > ajp13. > > For that we only need a mechanism to register new message > handlers, and to > have a dispatcher that calls the right handler when

[j-t-c] ajp and headaches

after many months of being away, i've recently gotten back into the fray of jakarta-tomcat-connectors. my goal is as it was many months ago - an ajp (v1.3) connector for tomcat 4. after discovering that things are not working entirely correctly on the HEAD of cvs, i started digging into the co

[j-t-c] problem in ajp_process_callback (in jk_ajp_common.c)

in ajp_process_callback, here is the block of code that handles sending the next chunk of data from the webserver to tomcat: --- snip --- case JK_AJP13_GET_BODY_CHUNK: { unsigned len = (unsigned)jk_b_get_int(msg); jk_log(l, JK_LOG_DEBUG, "receiv

RE: JK in TC 4.0 ?

g it, we could bundle the binaries with the > release distribution. > > mod_webapp will stay as the default native connector, as it has better > integration with Tomcat 4. > > The Catalina wrapper for JK supports version 1.3, and was > written by Kevin > Seguin. The sour

RE: FW: configuration of mod_jk and tomcat-4.0

> > > > > There are documents for using tomcat-4.0 with mod_jk? > > Those would be very useful. > > > > The only thing that is Tomcat-4-specific is the > entry, which > is documented in "jk/README.txt" in the jakarta-tomcat-connectors > repository. All of the configuration files for JK are, >

RE: [VOTE] New commiter Ryan Bloom

> > I would like to propose Ryan Bloom as commiter > in Tomcat, and particulary on jakarta-tomcat-connector. > > Ryan is one of the dev leader in Apache 2.0 and > contributed many patch for both mod_jk and mod_webapp, > showing us that connectors avoid politics :) > > Vote, please > +1

RE: [VOTE] Bug Notification E-Mails

+1 there's a couple reasons i'd like to see notifications sent to tomcat-dev: 1) i might be able to (help) fix the bug 2) the bug may affect me, and i don't even know it (yet) and, of course, i'm just plain nosy :) > Whenever a bug is entered or modified on Nagoya Bugzilla, > should Tomcat-De

RE: isapi_redirect.dll

see the following: http://jakarta.apache.org/site/binindex.html i believe what you are looking for is this: http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.3/bin/win32/i38 6/ > -Original Message- > From: Golash Rahul [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 27, 2001

RE: tomcat 4 and CLIENT-CERT auth (maybe) not working properly

never mind. i answered my own question. i didn't have a Realm from which i could authenticate a principal based on certs. what i'm trying to do is force client auth for a given uri pattern but not have to use the servlet spec's notion of roles, principals, etc.. i'm attempting to get the same

tomcat 4 and CLIENT-CERT auth (maybe) not working properly

when i attempt to use CLIENT-CERT auth with the tomcat 4 manager webapp, tomcat appears to still be looking for basic auth credentials. for example, if i change web.xml in the manager webapp to look like this: --- snip --- Entire Application /* *

jakarta-tools/javac.jar

does anybody know if it is legal to redistribute this jar file? if it is legal to redistribute this jar, but not tools.jar, why? thanks for any info, -kevin.

RE: Adding another protocol

> > > > On Tue, 21 Aug 2001 [EMAIL PROTECTED] wrote: > > > Craig, > > > > Can you point to some reference (or additional some information > > ) if I want to Implement a HTTP Extension on tomcat4. > > > > Thanks In Advance, > > Kumar. > > > > The only information that exists is in the C

RE: tomcat 4 request/response instrumentation

> > > also, would it be possible to use a Valve to accomplish this? > > Yes... > > > how are valves processed? are they stacked such that the > first valve entered > > is the last one exited? > > Correct. > > > or are they chained such that one valve is processed after > the next, and once

tomcat 4 request/response instrumentation

something that i've started thinking about recently is how to provide hooks in tomcat 4 so that some statistics regarding request processing time could be collected. off of the top of my head, a couple of interesting stats might be average request processing time for all contexts (or webapps) a

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

seguin 01/08/14 13:52:43 Modified:jasper/src/share/org/apache/jasper/compiler JikesJavaCompiler.java Log: two fixes: 1) normalize the classpath jikes is invoked with so that it doesn't contain file urls like "/c:/tomcat/webapps/..

RE: cvs commit: jakarta-tomcat-service/winnt/supcalls_nt vdenv.c

it sounds like cygwin is required for this to run. is this true? is it only because jsvc depends on it? thanks! > > It creates the registry values needed for the environment > to start jsvc.exe > JAKARTA_HOME > CYGWIN (You have to set it to your cygwin directory home). >

RE: [tomcat 4] using jikes to compile jsp's

so, i have two "fixes" to the problem mentioned below, and i wanted to run them by somebody... both fixes involve "normalizing" the paths that make up the classpath by essentially passing them through File objects. the big difference is where this normalization takes place. one place to do it i

[patch] small "enhancement" to JikesJavaCompiler

the attached patch makes JikesJavaCompiler output error information in a format that can be parsed so that the information shows up in the browser. basically, the patch just adds +E to the jikes command line options so that errors are listed in emacs form. Index: jasper/src/share/org/apache/jas

[tomcat 4] using jikes to compile jsp's

has anybody tried using jikes to compile jsp's with tomcat 4 on windows recently? i have. it barfed :) basically what's happening is the classpath is getting messed up. more specifically, the entry in the classpath that points at WEB-INF/classes/ is getting messed up. the classpath ends up lo

RE: ISAPI redirector

the code is all in cvs. you can browse the repositories from here: http://jakarta.apache.org/site/cvsindex.html see these: jakarta-tomcat-connectors/jk/native/ jakarta-tomcat/src/native/ -kevin. > > > I searched the archives for this list and found a few > references to the > Visual Studio

RE: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java

> > > [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: > > > > [...] > > > > public interface Service { > > public void load(ServiceContext context) throws Exception; > > public void start() throws Exception; > > public void stop() throws Exception; > > } > > I keep going back and fo

RE: Standalone SSL Problem (was: Re: [DOC] TC4 Status)

i have seen this. little background first... i had some webapps that needed to use jsse, plus catalina needed it for https. so, i figured i'd put the jsse jars somewhere in the tc4 dist tree so that both the webapps and catalina could find them. i believe that was $TC4_HOME/common/lib. well,

RE: Sources in Binary Distributions

> > > -Original Message- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > > >[...] > > For Tomcat 4, what do folks think of omitting the sources > from the binary > > distribution? This would knock the size of the binary > distributions down > > by around 2 megabytes (which

  1   2   3   >