cvs commit: jakarta-tomcat/src/admin/WEB-INF/scripts watchdog-servlet.xml

costin 01/02/12 21:36:22 Modified:src/admin/WEB-INF/scripts watchdog-servlet.xml Log: Another small build fix - this time running watchdog's servlet tests was failing ( moo not included in classpath ) Revision ChangesPath 1.2 +4 -0 jakarta-tomcat/src/admin/

cvs commit: jakarta-tomcat README

larryi 01/02/12 20:37:27 Modified:.README Log: Update section on testing, since the sanity-test is no longer build by default. Revision ChangesPath 1.13 +18 -12jakarta-tomcat/README Index: README

cvs commit: jakarta-tomcat/src/doc readme

larryi 01/02/12 20:35:02 Modified:src/doc readme Log: Update to document some major changes from Tomcat 3.2 Revision ChangesPath 1.10 +88 -1 jakarta-tomcat/src/doc/readme Index: readme ===

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config IISConfig.java

larryi 01/02/12 20:30:16 Modified:src/share/org/apache/tomcat/modules/config IISConfig.java Log: Add missing engineInit() method. Revision ChangesPath 1.2 +7 -2 jakarta-tomcat/src/share/org/apache/tomcat/modules/config/IISConfig.java Index: IISConfig.ja

Re: adding webappsDir attribute to ContextManager?

Hi Scott, > I wanted to know the interest in adding an additional attribute to > ContextManager in server.xml to specify a webapps directory, in much the > same way that the work directory can be specified. This would override the For 3.3 - it's already customizable ( you can even specify multi

Updating Tomcat3 Bugzilla items

I realize that the voting on Tomcat 3.2.2 is not complete yet, but I want to get a head start on reviewing/updating Bugzilla reports against Tomcat 3. There are currently 248 reports in the open/reopened/new states. All of these need to be reviewed and addressed prior to finalizing 3.2.2. I wil

adding webappsDir attribute to ContextManager?

I'm brand new to this list, so forgive me if this has been dealt with before.  I've searched the archives, and although this has been brought up before (http://mikal.org/interests/java/tomcat/archive/view?mesg=1003), I don't think it has been resolved.   I wanted to know the interest in addi

cvs commit: jakarta-tomcat build.xml

costin 01/02/12 19:13:45 Modified:.build.xml Log: Fixed another build problem. Nacho - I think we need a bit more work on the class loader, like spliting jasper into runtime and compiler and something similar with some of the utils. Revision ChangesPath 1

Re: charset used for parameters decoding on HTTP request Tomcat3.x,4

> You will still need to fix the actual parameter parsing routine to delay > applying the encoding until the name and parameter are parsed out of the > input stream... Yes, most of this is already done. It also has a very nice performance implication - since the String is converted and alocated o

Re: charset used for parameters decoding on HTTP request Tomcat3.x,4

You will still need to fix the actual parameter parsing routine to delay applying the encoding until the name and parameter are parsed out of the input stream... - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 12, 2001 1:14 PM Subject: Re: cha

Re: charset used for parameters decoding on HTTP request Tomcat3.x,4

Title: charset used for parameters decoding on HTTP request Tomcat3.x,4 Because of the way byte values are URL encoded, (and the way tomcat decodes them.) What you usually receive with get parameters is a byte stream one byte per character.  You can post process the string obtained by getParam

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java

remm01/02/12 17:24:59 Modified:catalina/src/share/org/apache/catalina/core StandardContext.java Log: - Fix for an initialization problem, where listeners and filters couldn't be loaded if either : - They were inside a JAR file - They were in t

cvs commit: jakarta-tomcat build.xml

costin 01/02/12 16:47:46 Modified:.build.xml Log: 2 small fixes to generate the correct build Revision ChangesPath 1.114 +9 -3 jakarta-tomcat/build.xml Index: build.xml === RCS fil

Re: mod_jk TC 3.2.2 != TC 3.3

GOMEZ Henri <[EMAIL PROTECTED]> wrote: >> Sorry I'm getting back into this late. That bloody email >> virus had our mail >> server off line for a while. > > I seems to be an attack against the majority of Apache list (xml / jakarta). And the majority of the world itself http://www.cnn.com/2001

Regular expressions in JkMount

I'm not sure if feature requests go here but it seems better than tomcat-user. Anyway... I have seen numerous requests for mapping specific URI's to a specific tomcat worker through mod_jk and I would like to do that as well. The need arises when the simple pattern matching used by JkMount i

Re: mod_jk TC 3.2.2 != TC 3.3

Craig R. McClanahan <[EMAIL PROTECTED]> wrote: > GOMEZ Henri wrote: > >>> Agreed, i'm reluctant too to adding features to TC3.2, only bugfixes on >>> TC3.2.. so any bug fixed on TC3.3 that must be done , no more nor less >>> than that.. and it's a big piece of work only with maintenance >>> of a

cvs commit: jakarta-tomcat/src/build readme.common readme.container readme.shared

costin 01/02/12 15:09:36 Modified:.build.xml src/tests build.xml Added: src/build readme.common readme.container readme.shared Log: Few changes to the build scripts ( preparing for M1 ). - the test apps are no longer included in the dist ( since

RE: mod_jk TC 3.2.2 != TC 3.3

>Sorry I'm getting back into this late. That bloody email >virus had our mail >server off line for a while. I seems to be an attack against the majority of Apache list (xml / jakarta). >The intent of 3.2.2 is to release bug fixes for existing functionality. >Since Tomcat 3.2.1 doesn't support

RE: mod_jk TC 3.2.2 != TC 3.3

Sorry I'm getting back into this late. That bloody email virus had our mail server off line for a while. The intent of 3.2.2 is to release bug fixes for existing functionality. Since Tomcat 3.2.1 doesn't support Apache 2.0 then it is completely valid for 3.2.2 not to support it. Adding new func

Re: mod_jk TC 3.2.2 != TC 3.3

GOMEZ Henri wrote: > >Agreed, i'm reluctant too to adding features to TC3.2, only bugfixes on > >TC3.2.. so any bug fixed on TC3.3 that must be done , no more nor less > >than that.. and it's a big piece of work only with maintenance > >of actual > >code... > > If we didn't upgrade mod_jk, Tomcat

RE: mod_jk TC 3.2.2 != TC 3.3

>Agreed, i'm reluctant too to adding features to TC3.2, only bugfixes on >TC3.2.. so any bug fixed on TC3.3 that must be done , no more nor less >than that.. and it's a big piece of work only with maintenance >of actual >code... If we didn't upgrade mod_jk, Tomcat 3.2.x couldn't be use with Apa

RE: mod_jk TC 3.2.2 != TC 3.3

> I don't particularly want to multiply the codebases we > support (and the > differences between them), but, especially since we're nearing a 3.3 > release, my instinct is to vote against applying all the 3.3 > work to the 3.2 > branch. > Agreed, i'm reluctant too to adding features to TC3.2,

Re: mod_jk TC 3.2.2 != TC 3.3

[I meant to send this to the list on Sunday, but apparently sent it only to Henri -- I'm sending it here just to keep you all up to date on the conversation.] I'm not sure if I support this -- the 3.2.2 release is supposed to be purely bug fixes. Some of the work which has gone into mod_jk 3.3 a

Re: Tomcat 4 mod_webapp segmentation fault bug

Glenn Nielsen <[EMAIL PROTECTED]> wrote: > Tomcat 4 mod_webapp segmentation fault bug. > > If I start apache, then start tomcat 4, the apache process will > seg fault when a request gets mapped to tomcat. If I reload apache, > the problem is fixed. Ok... It seems a problem in the initializatio

Re: What about mod_jk/ajp as tomcat sub-project

To me, having a separate project doesn't make a lot of sense (yet, at least). There are different "levels" of mod_jk in TC 3.2 and TC 3.3 as you say, but it's really just the same as having new code in the 3.3 in general. Bug fixes should be committed in the 3.2 branch, but new features, perform

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java

remm01/02/12 13:27:32 Modified:catalina/src/share/org/apache/catalina/startup Bootstrap.java Log: - Fix for bug #556. Won't add bin/jndi.jar to the Catalina classoader if the JNDI classes can be loaded from the system classloader. Revision Chang

Tomcat 4 Apache mod_webapp/Warp NPE

With latest Tomcat 4 with Apache mode_webapp/Warp I get a NPE when accessing /examples/jsp/ or examples/servlets/. From looking at the code it looks like the HttpRequest Scheme may be null. A Servlet Exception Has Occurred Exception Report: javax.servlet.ServletException: Servlet execution thr

Tomcat 4 mod_webapp segmentation fault bug

Tomcat 4 mod_webapp segmentation fault bug. If I start apache, then start tomcat 4, the apache process will seg fault when a request gets mapped to tomcat. If I reload apache, the problem is fixed. [Mon Feb 12 14:55:08 2001] [notice] child pid 19336 exit signal Segmentation Fault (11) Apache 1

Re: Karma

Fixed. Craig Kief Morris wrote: > I'm trying to commit a patch for Tomcat 3.2.2 to fix bug #504, but > I'm getting told off for insufficient karma. I'm pretty sure I've got my > SSL tunnels working, maybe I don't have commit privs on the > jakarta-tomcat project?? > > Access denied: Insuff

FW: broken link

Whops... :) Pier -- Pier P. Fumagalli -- Forwarded Message From: Chalasani Ashant <[EMAIL PROTECTED]> Date: Mon, 12 Feb 2001 02:14:14 -0800 (PST) To: [EM

Karma

I'm trying to commit a patch for Tomcat 3.2.2 to fix bug #504, but I'm getting told off for insufficient karma. I'm pretty sure I've got my SSL tunnels working, maybe I don't have commit privs on the jakarta-tomcat project?? Access denied: Insufficient Karma (kief|jakarta-tomcat/src/share/

Re: Session-expiry bug? getLastAccessedTime

Hi, I debugged thru Tomcat3.2.1 source code this morning and it too has the same problem: Session.access() is called only once per request, before the request is processed (called by findSession in StandardManager) This would mean that getLastAccessedTime() always gives the time of (last-1) req

Error: in web.xml

Hope this is the right location for reporting errors... I've just started working with Tomcat 3.2.1. I wrote to web.xml: servlet_1 pattern_1 servlet_2 pattern_2 instead of: servlet_1 pattern_1 servlet_2 pattern_2 Tomcat did not find servlet_1 then. It took me a long tim

RE: [PATCH] encryption support in SimpleRealm.java

That's not to say that providing a tool isn't a good thing. Just that as long as the hash is well defined (and the text encoding of the hash), it's easy to write tools to do so. They don't require any secret knowledge, like an embedded key. -Original Message- From: Steve Downey [mailto:[E

Modules subproject ( was: Re: [PATCH] CatalinaBlock.java )

> > Actually, I was thinking starting a modules subprojects for things like that > in 4.1. It would be really great to have a module subproject !!! ( as long as it will host 3.3 modules too :-) This will keep the release more focused on the core functionality, and simplify the testing and rel

Re: charset used for parameters decoding on HTTP request Tomcat3.x,4

> I would like to know the policy for the request's parameters decoding in > Tomcat 3.x. AFAIK there are still problems in both 3.2.x and 3.3(dev). Fixing this is one of the highest things on my todo list, and you should expect a solution before 3.3 beta ( i.e. in about a month ). The solution w

Re: [PATCH] CatalinaBlock.java

* Sam Ruby ([EMAIL PROTECTED]) wrote on Mon Feb 12, 2001 at 01:39:07PM -0500: > Aaron Mulder wrote: > > > > It's always going to be the case that the Avalon and Tomcat releases > > don't sync up perfectly. How would you feel about making any Tomcat > > changes necessary to support the Avalon patc

Re: [PATCH] CatalinaBlock.java

Aaron Mulder wrote: > > It's always going to be the case that the Avalon and Tomcat releases > don't sync up perfectly. How would you feel about making any Tomcat > changes necessary to support the Avalon patch, but maintaining the > Avalon block itself outside of the main Tomcat 4.0 module? Tha

Re: [PATCH] CatalinaBlock.java

> It's always going to be the case that the Avalon and Tomcat releases > don't sync up perfectly. How would you feel about making any Tomcat > changes necessary to support the Avalon patch, but maintaining the > Avalon block itself outside of the main Tomcat 4.0 module? That way the > Avalon sup

Re: [PATCH] CatalinaBlock.java

Aaron Mulder wrote: > It's always going to be the case that the Avalon and Tomcat releases > don't sync up perfectly. How would you feel about making any Tomcat > changes necessary to support the Avalon patch, but maintaining the > Avalon block itself outside of the main Tomcat 4.0 modul

RE: [PATCH] encryption support in SimpleRealm.java

It's not really encryption, just a one way hash function. So you can't recover the password from the text in the password file. To check validity you hash the provided password and compare with the stored hash. In theory you could have a collision, but it's the same order of complexity, or harder,

charset used for parameters decoding on HTTP request Tomcat3.x,4

Title: charset used for parameters decoding on HTTP request Tomcat3.x,4 Hi all, I would like to know the policy for the request's parameters decoding in Tomcat 3.x. In Servlet 2.3 specifications a new method on the HttpServletRequest object was added in order to be able to specify the reques

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

costin 01/02/12 08:58:28 Modified:src/facade22/org/apache/tomcat/facade HttpServletResponseFacade.java Log: Recycle the writer, thanks Nacho for finding that. Revision ChangesPath 1.16 +1 -1 jakarta-tomcat/src/facade22/org/apache/tomca

bye

Title: bye unsubscribe -Original Message- From:   Christian Langmann [SMTP:[EMAIL PROTECTED]] Sent:   Monday, February 12, 2001 4:30 PM To: [EMAIL PROTECTED] Subject:    bye unsubscribe - To unsubscribe,

cvs commit: jakarta-tomcat README

larryi 01/02/12 07:06:18 Modified:.README Log: Update to current build procedure. Document how to run the current sanity-test. Still needs more info about how to use Watchdog. Revision ChangesPath 1.12 +66 -22jakarta-tomcat/README Index: RE

cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF/classes Unavailable.java

larryi 01/02/12 07:01:34 Modified:src/tests/webpages/WEB-INF test-tomcat.xml src/tests/webpages/WEB-INF/classes Unavailable.java Log: Update test script and Unavailable.java so test can be re-run without generating errors. Revision ChangesPath 1.22

Re: [PATCH] CatalinaBlock.java

It's always going to be the case that the Avalon and Tomcat releases don't sync up perfectly. How would you feel about making any Tomcat changes necessary to support the Avalon patch, but maintaining the Avalon block itself outside of the main Tomcat 4.0 module? That way the Avalon s

RE: mod_jk TC 3.2.2 != TC 3.3 => was RE: [PROPOSAL] Tomcat 3.2.2 Rele ase Plan

>No, it was decided to not start changing the 3.2.x tree. >If people want the fixes, they can always upgrade. Sorry but adding bug corrections is not changing the tree. People may also want to use the mod_jk stuff with Apache 2.0. If we didn't back port corrections on mod_jk / ajp from 3.3 to 3

RE: mod_jk TC 3.2.2 != TC 3.3 => was RE: [PROPOSAL] Tomcat 3.2.2 Rele ase Plan

No, it was decided to not start changing the 3.2.x tree. If people want the fixes, they can always upgrade. Keith -Original Message- I think that both Dan and Keith have each time back ported the Java corrections in tomcat_32 but it must be validated with them. -

Re: [PATCH] CatalinaBlock.java

Remy Maucherat wrote: > > For these reasons, I'd like to see an official Avalon wrapper > introduced in Tomcat 4.1, but not in Tomcat 4.0. I also > propose to remove the current Avalon wrapper from the Tomcat > 4.0 repository, to avoid the maintenance related issues. +1 - Sam Ruby ---

bye

unsubscribe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]

Re: [VOTE] Tomcat 3.2.2 Release Plan

Marc Saegesser typed the following on 09:21 AM 2/11/2001 -0600 ><- Please return this portion with your vote -> > >Tomcat 3.2.2 Release Plan Ballot: > > [X] +1 I am in favor of this plan and will help > [ ] +0I am in favor of this plan, but am unable to help > [ ] -0I am n

RE: mod_jk TC 3.2.2 != TC 3.3 => was RE: [PROPOSAL] Tomcat 3.2.2 Rele ase Plan

I didn't received replies to my post on mod_jk differences between TC 3.3 and TC 3.2.2. I've proposed to copy all the mod_jk native code from TC 3.3 to TC 3.2.2 before release. They were many bugs fixed in both native and java parts, and it will be a pitty to let the release goes without that fi

What about mod_jk/ajp as tomcat sub-project

My proposal come from the constat we have now 2 differents Tomcat distro 3.2.x and 3.3.x each one with a different level of mod_jk. Tomcat 4.x could also benefits from a port of mod_jk even if they have started working on mod_webapp. May be via a merge of both parts in mod_jk/mod_webapp. So why