Re: Classpath Ordering: Questions, and possible contrib.

Thanks everybody for some excellent answers on the classloading topic. The security issues are not something I had considered, in naturally thinking that 'look then delegate' is the logical way to go. On the issue of classpath ordering via my .properties file, I was thinking that it would not

Ajp14 - seems to work :-)

Ok, I've got the first request served via Ajp14. There are probably few details to resolve ( like the fact that the connection is closed after authentication - I'm not sure why ). I can now start playing with some of the fun callbacks I want ( and maybe abstract a bit the marshling and callbacks

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java

On Sun, 24 Jun 2001, kevin seguin wrote: > i've been thinking about this, and, well, isn't this BaseRequest you're > talking about kind of what org.apache.coyote.Request is? does it make > sense to have two of these kinds of objects hanging around? is > o.a.c.Request roughly equivalent to core.

Re: [jtc] tabs policy??

[EMAIL PROTECTED] wrote: > > On Sun, 24 Jun 2001, Justin Erenkrantz wrote: > > > That just leads to formatting problems because people don't understand > > that. If you must have tabs, they should be the same as the indention > > level, not some factor of the indention level. This doesn't ha

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java

> > I think we should move AjpRequest to o.a.tomcat.util.http.BaseRequest, > and have o.a.t.core.Request extend it. > > ( the util.http package contains low-level utils. The BaseRequest will > have the base fields for a http request, with various protocols > setting them. The core.Requ

Re: Anyone know why the ISAPI redirector works how it does?

[EMAIL PROTECTED] wrote: > > That would work in the first instance. I also have some metabase management code to >set this up properly for an auto installer - let me know if you want it. > Cheers...Pete I'm sure that'll be useful -- the setup could usefully be more automated. -- Andy Armstro

Re: Anyone know why the ISAPI redirector works how it does?

Thanks Pete -- I'll watch for that. I've already had some experience of this sort of thing. Not nice. [EMAIL PROTECTED] wrote: > > You're right - it can't for filters - hence why it defaults to "Low". > > A word of advice, if you are doing this on Win2K you also get into some hairy >security i

RE: Anyone know why the ISAPI redirector works how it does?

That would work in the first instance. I also have some metabase management code to set this up properly for an auto installer - let me know if you want it. Cheers...Pete -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Monday,25 June 2001 8:53 To: '[EMAIL PR

Re: URL Decoding for %XX%XX%XX

Thank you for your reply. > The above URL should work in tomcat33 ( M4 and after ), > assuming the encoding is passed ( either you are in a > session, and use the session encoding, or an hipotetical > browser that sends the encoding - don't know any, or you > override the default encoding for the

RE: Anyone know why the ISAPI redirector works how it does?

Hola a todos, Peter: It seems from your messages that the actual architecture of the isapi plugin is another form of the only filter solution ? A easy way to solve it can be to simply separate the filter part from the extension part of the isapi plugin without adding the thread pool? could let

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

[EMAIL PROTECTED] wrote: > > On Sun, 24 Jun 2001, kevin seguin wrote: > > > hey costin, one of the things i've been planning on doing is changing > > o.a.ajp.AjpRequest to make use of o.a.coyote.Request. basically, wrap > > Request in AjpRequest. does this conflict with your plans? > > Yes,

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/net PoolTcpEndpoint.java

costin 01/06/24 15:44:16 Modified:src/share/org/apache/tomcat/util/net PoolTcpEndpoint.java Log: Added the test in the base class, to avoid duplicating it in all subclasses. Revision ChangesPath 1.12 +6 -3 jakarta-tomcat/src/share/org/apache/tomcat/util/net/P

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

costin 01/06/24 15:43:11 Modified:src/share/org/apache/tomcat/modules/server Ajp13Interceptor.java Log: Added a small comment that the file is not to be "developed", only fixes should go in. Revision ChangesPath 1.9 +8 -3 jakarta-to

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

costin 01/06/24 15:42:39 Added: src/share/org/apache/tomcat/modules/server Ajp13Packet.java Log: Moved from Ajp13. Revision ChangesPath 1.1 jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Packet.java Index: Ajp13Packet.java

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

costin 01/06/24 15:42:20 Modified:src/share/org/apache/tomcat/modules/server Ajp13.java Log: Merged a change from j-t-c: the Packet is now a separated class ( it's easier to read and migrate eventual bug fixes, the active development will happen in j-t-c but some fixes might be

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

costin 01/06/24 15:41:16 Modified:src/share/org/apache/tomcat/modules/server PoolTcpConnector.java Log: Merged a fix from j-t-c, the isSameAddress is here to avoid Ajp13->Ajp12 deps. Revision ChangesPath 1.5 +33 -0 jakarta-tomcat/src

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Request.java

costin 01/06/24 15:40:35 Modified:src/share/org/apache/tomcat/core Request.java Log: Change from package level to protected few fields, other small fixes to allow it to be better wrapped. Revision ChangesPath 1.103 +4 -4 jakarta-tomcat/src/share/org/apache/to

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java

On Sun, 24 Jun 2001, kevin seguin wrote: > hey costin, one of the things i've been planning on doing is changing > o.a.ajp.AjpRequest to make use of o.a.coyote.Request. basically, wrap > Request in AjpRequest. does this conflict with your plans? Yes, a bit, as I'm going to wrap AjpRequest in

RE: Anyone know why the ISAPI redirector works how it does?

You're right - it can't for filters - hence why it defaults to "Low". A word of advice, if you are doing this on Win2K you also get into some hairy security issues and what is happenning under IUSR, IWAM etc. accounts. Keep it in mind if you start to see some strange behaviour in you tests.

cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade ServletHandler.java

costin 01/06/24 15:33:14 Modified:src/facade22/org/apache/tomcat/facade ServletHandler.java Log: An old change that wasn't commited - we want all logs related with a webapp to go into the webapp log file ( if set ). The "container" log should be used only for global messages.

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

costin 01/06/24 15:29:02 Modified:jk/java/org/apache/ajp AjpRequest.java jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java Log: Started to implement the adapter. I think we should move AjpRequest to o.a.tomcat.util.http.BaseRequest, and have o.a.t.core.Req

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java

kevin seguin wrote: > > [EMAIL PROTECTED] wrote: > > > > costin 01/06/24 14:17:13 > > > > Modified:jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java > > Log: > > Fixes for the code move. > > > > One big missing chunk is the adapter between o.a.ajp.AjpRequest and > > tomcat3

Re: Anyone know why the ISAPI redirector works how it does?

[EMAIL PROTECTED] wrote: > > Hi, I'm a new, late starter on this thread... > > My understanding is that IIS runs about 15 threads and for filters it runs it on one >of the threads, and for extension procs it uses the model defined in the application >setup of the virtual directory (Low [iis th

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java

[EMAIL PROTECTED] wrote: > > costin 01/06/24 14:17:13 > > Modified:jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java > Log: > Fixes for the code move. > > One big missing chunk is the adapter between o.a.ajp.AjpRequest and > tomcat33 request ( similar with the one for tom

Re: URL Decoding for %XX%XX%XX

On Mon, 25 Jun 2001, Jun Inamori wrote: > IE (at least IE 5.5 on Windows95) encodes the request URL by the way of: >one Japanese character --> %XX%XX%XX > And this results in the corrupted URL String. > I'm not sure, but I remenber that Costin pointed this is the bad > behavior of IE. No, th

cvs commit: jakarta-tomcat build.xml

costin 01/06/24 14:53:17 Modified:.build.xml Log: Use the new build.xml in j-t-c Revision ChangesPath 1.137 +8 -17 jakarta-tomcat/build.xml Index: build.xml === RCS file: /home/cvs/

RE: Anyone know why the ISAPI redirector works how it does?

Hi, I'm a new, late starter on this thread... My understanding is that IIS runs about 15 threads and for filters it runs it on one of the threads, and for extension procs it uses the model defined in the application setup of the virtual directory (Low [iis thread], Medium [pool thread], High [

URL Decoding for %XX%XX%XX

Hello, Thank you for all your effort and enthusiasm on cool software. IE (at least IE 5.5 on Windows95) encodes the request URL by the way of: one Japanese character --> %XX%XX%XX And this results in the corrupted URL String. I'm not sure, but I remenber that Costin pointed this is the bad be

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

costin 01/06/24 14:19:22 Modified:jk build.xml Log: Renamed the target to build the tomcat33 adapter as build-tomcat33. Added tomcat_modules in the classpath for the Ajp14Interceptor ( needed for the base module - the PoolTcpConnector ) Revision ChangesPath

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

costin 01/06/24 14:17:49 Modified:jk/java/org/apache/ajp Ajp13.java Ajp13Packet.java Log: Merged the new methods and code that was added in o.a.ajp.tomcat33. Revision ChangesPath 1.7 +44 -20jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java Index

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

costin 01/06/24 14:17:13 Modified:jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java Log: Fixes for the code move. One big missing chunk is the adapter between o.a.ajp.AjpRequest and tomcat33 request ( similar with the one for tomcat4 ). I'm working on this. Revisi

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14.java Ajp14Packet.java

costin 01/06/24 14:15:57 Removed: jk/java/org/apache/ajp/tomcat33 Ajp14.java Ajp14Packet.java Log: Moved in o.a.ajp

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 AjpPacket.java PoolTcpConnector.java

costin 01/06/24 14:14:50 Removed: jk/java/org/apache/ajp/tomcat33 AjpPacket.java PoolTcpConnector.java Log: Moved Ajp14 in o.a.a, Ajp14Interceptor will use PoolTcpConnector from tomcat33 ( no need to duplicate it here ).

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

costin 01/06/24 14:13:35 Removed: jk/java/org/apache/ajp/tomcat33 Ajp13.java Ajp13Packet.java Log: Removed ajp13, ajp13packet - the code has been merged into o.a.ajp

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

costin 01/06/24 14:12:49 Removed: jk/java/org/apache/ajp/tomcat33 Ajp13Interceptor.java Log: Removed Ajp13Interceptor. For ajp13 we could use either the old interceptor, in tomcat33 ( that will remain stable/unchanged until ajp14 is ready ), or ajp14Interceptor ( assuming backw

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

costin 01/06/24 13:44:49 Added: jk/java/org/apache/ajp Ajp14.java Ajp14Packet.java Log: Moved Ajp14 and Ajp14Packet to the common dir. Did the changes to make it compile ( it will not work right now, there are few more fixes - to wrap AjpRequest into a Request in the inter

cvs commit: jakarta-tomcat/src/shell tomcat.bat

marcsaeg01/06/24 12:27:16 Modified:src/shell Tag: tomcat_32 tomcat.bat Log: Making tomcat.bat consistent with tomcat.sh in how files are added to the classpath. Tomcat.bat only added jar files while tomcat.sh added all files in tomcat/lib. This made it more difficult for users

cvs commit: jakarta-tomcat/src/etc server.xml

costin 01/06/24 11:58:38 Modified:src/etc server.xml Log: Reverted to Ajp13 from the jakarta-tomcat workspace ( ajp13 implementation is "frozen", only bug fixes go in - we want to keep this as stable as possible) Added the Ajp14 interceptor ( experimental so far - will be e

Re: [jtc] tabs policy??

> > It just mean that stupid > programmers decided it's easier to add a panel that changes the number of > spaces equivalent with TAB instead of implementing code that uses spaces > for indentations < 8, and replaces 8 spaces with a tab symbol. > so, the programmers who wrote emacs are *not* st

Re: [jtc] tabs policy??

On Sun, 24 Jun 2001, Justin Erenkrantz wrote: > That just leads to formatting problems because people don't understand > that. If you must have tabs, they should be the same as the indention > level, not some factor of the indention level. This doesn't have to be > complicated. One tab == on

Re: JSP -en- masse mapping

Not easy - you may need a modified mod_jk for that. The handler name is jakarta-servlet, but the current module does some work in translate(), to determine which protocol and tomcat instance to use. The change is probably easy, configure/use a default protocol and instance and use it. The origi

Re: [jtc] tabs policy??

On Sun, Jun 24, 2001 at 08:52:03AM -0500, kevin seguin wrote: > GOMEZ Henri wrote: > > > > I'm using tab = 4 so +1 there. > > > > it's important to make the distinction between indent level and number > of spaces per tab -- they are totally different. i'm for 4 space indent > level, tabs set t

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

andya 01/06/24 08:37:44 Modified:jk/native/iis jk_isapi_plugin.c Log: Defer jk initialisation until server name is known (which means when the filter or extension proc has been called). Builds, loads but not extensively tested. Revision ChangesPath 1.6 +152 -106

Re: Anyone know why the ISAPI redirector works how it does?

Marc Saegesser wrote: > > Again, threads don't improve performance, in fact they degrade performance > and on some platforms (namely, Windows) they can degrade performance very > quickly. Context switching between threads on Win32 is *really, really* > expensive (several hundred instructions in

RE: Anyone know why the ISAPI redirector works how it does?

Again, threads don't improve performance, in fact they degrade performance and on some platforms (namely, Windows) they can degrade performance very quickly. Context switching between threads on Win32 is *really, really* expensive (several hundred instructions in kernel space). Without processor

Re: Anyone know why the ISAPI redirector works how it does?

(sorry to follow myself up, but I've just found some more evidence about this) Andy Armstrong wrote: [snip] > > Yeah, well I'm not entirely convinced myself. I'm guessing, from what > I've read on the MS site, that IIS actually runs with quite a small, > fixed size, pool of threads and relies on

Re: [jtc] tabs policy??

GOMEZ Henri wrote: > > I'm using tab = 4 so +1 there. > it's important to make the distinction between indent level and number of spaces per tab -- they are totally different. i'm for 4 space indent level, tabs set to 8 spaces (the standard). tabs set to 4 spaces is bad. when some people use

Re: Anyone know why the ISAPI redirector works how it does?

Marc Saegesser wrote: > > I don't have any problem with the experiment, and couldn't stop the > *experiment* even if I wanted to. By all means, scratch the itch. > > I am curious though, what it takes to cause the thread starvation in a > normal environment (what ever that is). Adding the comp

RE: Anyone know why the ISAPI redirector works how it does?

I don't have any problem with the experiment, and couldn't stop the *experiment* even if I wanted to. By all means, scratch the itch. I am curious though, what it takes to cause the thread starvation in a normal environment (what ever that is). Adding the complexity of a thread pool will slow d

Re: Anyone know why the ISAPI redirector works how it does?

OK, I've done a bit more digging. From what I've read about ISAPI it seems that thread exhaustion can be a problem both for filters /and/ extensions[1]. The advice on this page /is/ to avoid filters, but I assume that's just because filters will be invoked for every request -- unfortunately that's

[GUMP] Build Failure - Tomcat 3.x

This email is autogenerated from the output from: Buildfile: build.xml detect: msg.jdk12: [echo] Detected JDK1.2

Re: [jtc] anybody build iis plugin lately

GOMEZ Henri wrote: > > >I've fixed isapi.dsp and added an nmake Makefile (isapi.mak). > >I also had > >to fix a vouple of syntax errors in jk_isapi_plugin.c that I think were > >changes that Henri made in an attempt to bring the IIS > >connector in line > >with the latest jk code. > > Right and

RE: [jtc] tabs policy??

I'm using tab = 4 so +1 there. When you take a look in Apache projects, native and java, you could find many sources with spaces and many with tab(4). - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo...

RE: [jtc] anybody build iis plugin lately

>I've fixed isapi.dsp and added an nmake Makefile (isapi.mak). >I also had >to fix a vouple of syntax errors in jk_isapi_plugin.c that I think were >changes that Henri made in an attempt to bring the IIS >connector in line >with the latest jk code. Right and in the IIS case I still didn't tried