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
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
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 not in
unsubscribe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
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
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
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
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
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
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
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?
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? That
* 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 patch, but
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
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
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-mapping
servlet-nameservlet_1/servlet-name
url-patternpattern_1/url-pattern
servlet-nameservlet_2/servlet-name
url-patternpattern_2/url-pattern
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)
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
Whops... :)
Pier
--
Pier P. Fumagalli mailto:[EMAIL PROTECTED]
-- Forwarded Message
From: Chalasani Ashant [EMAIL PROTECTED]
Date: Mon, 12 Feb 2001 02:14:14 -0800 (PST)
To: [EMAIL
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:
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
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
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
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,
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 initialization
[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
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, only
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 Apache
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 3.2.x
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
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
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
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 actual
code...
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
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
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
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
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
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:
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
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
I'mbrand 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 adding
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
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
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:
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
===
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
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
48 matches
Mail list logo
