Per all the reasons Mark mentioned:
Keith
Bugs
[X] forward to [EMAIL PROTECTED]
[ ] forward to [EMAIL PROTECTED]
Commits
[X] forward to [EMAIL PROTECTED]
[ ] forward to [EMAIL PROTECTED]
-
To unsubscribe, e-mail:
Remy, you're right, this isn't good--
$ time svn praise CHANGES | wc
svn: Caught signal
real25m56.794s
Side question-- is the website move just waiting to be done by somebody?
I don't mind moving things over and putting a redirect at the old one,
if it is time for that.
Also, I tried
Mladen, one of the features of the the former connector was being able
to handle arbitrary http methods. At the time, a new one was being
added to delta-v or acl every time we turned around. Having a fallback
path of pushing through unknown methods eliminated the need to rebuild
jk for each
:-)
Thanks,
Keith
Mladen Turk wrote:
Keith Wannamaker wrote:
Mladen, one of the features of the the former connector was being able
to handle arbitrary http methods.
I'm not aware such a feature ever existed.
Only the ajp13 http methods can be handled by the ajp protocol,
and that was always. Two
No one has commented so I withdraw my (valid) veto and I'll roll back
5.0 per Remy's wish. I'm disappointed because I remember when Tomcat
was an open-source project.
Keith
My veto of this change still stands, and it would be your responsibility
of finding a fix more compatible with IE. If no
Remy, I have to -1 your change in AuthenticatorBase 1.13. You broke a
larger case than you fixed -- Mozilla may work now but IE doesn't. See
bugs 34083, 27122, 28662, 29336, 29975, and 30618 for the IE problem.
Mozilla should be fixed in a way compatible with IE.
By uncommenting !isSecure,
Remy Maucherat wrote:
Thanks. If you can find precisely what the issue with Mozilla was, and
certify the behavior is now correct in Firefox (= no stupid caching with
SSL), then you can indeed uncomment the isSecure here:
// FIXME: Disabled for Mozilla FORM support over SSL
If no one else weighs in on the root issue in a day or so, and you
disagree with this change, I'll be happy to roll it back and/or backport
5.5 head of tree in its place.
Keith
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
keith 2005/04/18 13:20:46
Modified:
I'd like to omit pragma header by default. What specific client
requires it? The community has identified a specific, widespread
failure with the former code-- it did not work out of the box with IE
under SSL.So, if we want to keep the pragma header the default, what
are the reasons?
us. Are you aware of a client that depends solely on Pragma
for cache instruction? I would argue that being unable to serve pages
to IE under SSL is more significant than a caching problem in a client
that doesn't understand cache-control.
Keith
Remy Maucherat wrote:
Keith Wannamaker wrote
I read:
// FIXME: Disabled for Mozilla FORM support over SSL
// (improper caching issue)
Indeed (I now remember the issue), there would be serious issues should
this not be the default.
The issue here is, apparently, that Mozilla has a caching bug we are
working around,
I haven't heard anything from this, so I plan on replacing the three
headers this code sets with a single cache-control: private header this
weekend in tc 5.0 and 5.5.
Keith
Keith Wannamaker wrote:
Remy, what are your reasons for not using cache-control: private?
We discovered some time ago
Does cache-control: private not achieve the correct behavior for you?
Keith
Remy Maucherat wrote:
Keith Wannamaker wrote:
I haven't heard anything from this, so I plan on replacing the three
headers this code sets with a single cache-control: private header
this weekend in tc 5.0 and 5.5.
Make
Remy, what are your reasons for not using cache-control: private?
We discovered some time ago that the Pragma: no-cache causes IE trouble
when under ssl. Why wouldn't cache-control: private be sufficient? If
we're enabling this behavior by default, it would make sense to use the
most
Here is the link to 4.1.31 and its release notes
http://archive.apache.org/dist/jakarta/tomcat-4/v4.1.31/
Thanks,
Keith
sun fire wrote:
Hi,
Where can I find the enhancements of Tomcat version 4.1.31 over 4.1.29 ? All releases available belong to the 5.x versions and 4.* versions don't seem to
I'd be honored to be part of this transition if others deem it appropriate.
Thanks,
Keith
Yoav Shapira wrote:
NOTE: Who am I missing? Kin-man? Craig? Keith? Others?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
The last time I looked at the Eclipse SVN plugin it just called out to
the native svn binary to do the real work-- I wonder how well anything
but basic operations can be integrated until it is using a java svn
client. Then again, maybe that has been written since I looked at it
last. I'd be
What needs to be done to launch tomcat via reflection?
jdk1.4 gives me java.lang.NoClassDefFoundError:
javax/management/MBeanRegistration.
Why does jmx have to be in the bootstrap loader?
System.setProperty(catalina.home, l_catalinaHome.getAbsolutePath());
URL urls[] = new URL[] {
StandardContext.start throws a (caught) npe for every web application
unless preRegister has been called on the context (line 4151). This is
pretty annoying in Eclipse because it automatically stops on all npes.
For me, preRegister is always called AFTER start, so this stanza always
npes.
Last month I took Yoav's advice and attempted to upgrade our production
server from 4.1 to 5.0. The production server handles 5 - 10 requests a
second across 300 threads. The problem I had then, and the problem I
have now is that the server's accept thread will die within a short time
after
The time window is within about 15 minutes. We run tomcat standalone,
with the standard http/11 connector. The server.xml is minimal. I
agree with the reproduceable angle, that is always a good place to start.
Keith
Shapira, Yoav wrote:
Hi,
There are certainly other sites running Tomcat 5.0
Hey Remy,
Some facts:
- the higher level code cannot cause the accept thread to die
Thread dump from T0 shows the two expected accepts, from main and from
the HttpConnector; thread dump at T(5mins) shows the main accept, many
idle Http handler threads waiting for work, and a few long-running
Hey Remy, by RH 9 bug do you mean the problem with jdk14 and nptl on
RH9? (os is RH9) I am running without nptl.
I did some more tracing and what I am seeing is that notify is called,
the thread is waiting, but it never wakes up.
Keith
Remy Maucherat wrote:
Keith Wannamaker wrote:
Hey Remy
The Jakarta Tomcat team is pleased to announce availability of
Jakarta Tomcat 4.1.31, available for download:
http://jakarta.apache.org/site/binindex.cgi
This is a maintenance release which incorporates a number of bug
fixes which were backported from Tomcat 5. More information is
available in
Hey Amy, would you mind running the TCKs against the 4.1.31 rc?
http://apache.org/~keith/rc2/
How does one go about obtaining these tests?
Thanks,
Keith
Amy Roh wrote:
Thanks Jan for the update.
I have confirmed that all JSP TCK tests pass with the latest
StandardWrapper.java. I have retagged
I have uploaded a Tomcat 4.1.31 release canidate #2 to
http://apache.org/~keith/rc2/
The change from RC1 is to correct the servlet-api doc's path.
Continuing the 4.1.x release pattern-- after a week's worth of voting,
if the outcome is stable, I will mirror and announce this RC as Tomcat
4.1.31.
Hi Kurt, good catch. I'll fix it and build RC2.
Keith
Kurt Miller wrote:
From: Keith Wannamaker [EMAIL PROTECTED]
I have uploaded a Tomcat 4.1.31 release canidate to
http://apache.org/~keith/rc1/
In the binary releases, the servletapi documentation was installed
into /webapps/tomcat-docs
I have uploaded a Tomcat 4.1.31 release canidate to
http://apache.org/~keith/rc1/
Continuing the 4.1.x release pattern-- after a week's worth of voting,
if the outcome is stable, I will mirror and announce this RC as Tomcat
4.1.31.
Please vote on the stability of this release:
Ballot
[ ]
I will be tagging 4.1.31 Saturday in preparation for a 4.1.31 release
canidate release.
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I have a question about the consensus of verion announcements.
My understanding/recollection of the process is to only announce release
canidates on tomcat-dev, then after some time a vote is taken on
a/b/stable, then the resulting version is announced via jakarta-announce
with the appropriate
By setContentLength taking an int instead of a long, even in jsr154,
does this mean the only way to send back files longer than max_int
is to chunk them?
Spec folks, has there ever been dicussion of changing this related
parameters to long?
Keith
The vote carried. I am aiming for the end of the month for
tagging and building a RC for 4.1.31.
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Yoav, I haven't RM'd a release yet but if you or another RM-pro
is willing to show me what is involved I might be willing to wear
the hat for 4.1.31. Here is how I understand the process:
- tag and create a release canidate
- email to announce@
- wait 48 hours for show stoppers
- delcare the RC
Hi Jess, in our case we don't have the resources at this point in
time to certify our product with a completely new code base.
I'm sure different people have different reasons.
Keith
-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Friday, August 20, 2004 10:38 AM
Hi Yoav, thanks for the release documentation. Do you mind if I
check this in to jt-4.0? I think it would be very helpful.
I am aware that 5.0 uses significantly different code which is
in itself a good reason for continuing maintenance releases of 4.1.
Backporting patches would be a nice
Hi,
I propose to apply pending bugzilla 4.1 patches and issue
a 4.1.31 release. The existance of unreleased committed fixes,
unapplied patches, and multiple requests for 4.1.31 on tomcat-dev
clearly represent an interest in a maintenance relase of
4.1.31. I volunteer to be the RM for this
Hi Jeanfrancois, we share enthusiasm but not opinions. I believe
since there are pending 4.1 patches in bugzilla and committed 4.1
fixes then there is clearly an interest in preserving the 4.1
tree in maintenance mode, and that means maintenance releases.
My understanding of the jakarta PMC
I notice that tabs are showing up in some changes, specifically
in jk2, but also in some other places. I want to make sure that
we are all on the same page for using the apache coding standards
which call for no tabs and 4-space indents.
Keith
+1
Keith
-Original Message-
From: Mark Thomas [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 16, 2004 1:37 PM
To: 'Tomcat Developers List'
Subject: Connector bugs
I propose re-assigning all connector bugs currently against TC4 to TC5.
I propose to mark the bugs against the deprecated
Hi Guenter, I don't see any reason not to move it, but I
would be sure to update the devstudio as well as build.xml
files. Probably the best thing to do is delete it and
commit it with a message indicating the original location.
Keith
-Original Message-
From: Günter Knauf [mailto:[EMAIL
Yoav, you might want to remove this.
Thanks,
Keith
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 27, 2004 11:12 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Protocol.java
Does anyone object to me tagging head of this module with TOMCAT_4_1_29 ?
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
| On Tuesday, December 09, 2003 5:56 PM, Keith Wannamaker
| [SMTP:[EMAIL PROTECTED] wrote:
| Does anyone object to me tagging head of this module with TOMCAT_4_1_29 ?
|
| Keith
|
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED
I'd like to commit something along these lines to the
v4 and v5 CoyoteAdaptors:
--- coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java16 Mar 2003
01:56:27 - 1.13.2.3
+++ coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java18 Sep 2003
19:45:09 -
@@
Yes it can be, good catch.
Keith
| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 18, 2003 4:07 PM
| To: Tomcat Developers List
| Subject: Re: [patch] wrong rx to invalid url
|
|
| Keith Wannamaker wrote:
|
| I'd like to commit
I been unsuccessful all afternoon at building j-t-catalina, and end-of-day
has caught me. If this commit gives anyone fits, let me know and I'll be
glad to roll it back.
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 18, 2003
I'm switching to eclipse, so I get to rexamine dependencies
in tc (4.1). Just wanted to make a note for others who may
try to do this: since there are circular dependencies
between j-t-connectors and j-t-4.0, it is important to build
coyote in a separate project which references both of these
Hi Bill, I am partial to handling it in the default servlet.
I agree the root context can't speak definitively for all
contexts, but I think it has a better chance of knowing a
proper response than the connector.
Keith
| -Original Message-
| From: Bill Barker [mailto:[EMAIL PROTECTED]
|
Hi Remy, * does map to the default context. Can you think of any special
downstream handling that we should do for '*'?
Keith
| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]
| Sent: Thursday, July 03, 2003 2:50 AM
| To: Tomcat Developers List
| Subject: Re: cvs
| ballot
| [ ] Alpha
| [ ] Beta
| [X] Stable (GA)
| /ballot
|
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Mark, you can start the vm with -Djavax.net.debug=all to get
under the hood of jsse and see why the handshake is failing.
You may also need to do some conversion as described here:
http://www.comu.de/docs/tomcat_ssl.htm.
Keith
| -Original Message-
| From: [EMAIL PROTECTED]
Hi Bill,
I had closed the bug because Remy told me it was already
fixed in 5.0. I guess it wasn't. If you do any more work
on it you should indicate the bug which is 14616.
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| Sent: Thursday, March 13, 2003
Hi Al, well of course production code is in CVS too. Just use
the appropriate tag when checking out. There might have been
something funny about your tarball, and you can eliminate this
possibility by pulling straight from CVS.
Keith
| -Original Message-
| From: Al [mailto:[EMAIL
Hey Bill, thanks for the input. I am all ears if you can think of
a better way to fix this in 4.1. Rather than forward-porting this
fix to 5.0, I will look at better ways of doing it there since you
indicate they exist.
I think this is the way to go for 4.1 since it will fix both the
most and
Remy,
The fix corrects the bug, which is that credentials are shared
between webapps. As I've asked before, if there is a better way
to correct it, I'm all for it. There are a lot of bugs that have
been in the code for a long time, it doesn't mean they aren't bugs.
The behavior bothers me, and
Hi Joseph,
Try checking out jakarta-tomcat-4.0 and jakarta-tomcat-connectors
with tag TOMCAT_4_1_22 or TOMCAT_4_1_18. The failure is due to a
recent checkin that broke the build. If you extract the fifteen or
so project dependencies into one separate dir, then point your
build.properties to
Greetings,
I brought this up in November. Remy and I have a disagreement
on how important fixing this bug is. I want to see if there is
a quorum of other committers who understand the problem and think
it should be fixed prior to the next stable build release of 4.1.
The immediate problem is
Remy, I don't even know if 4.1.x and 5.0 share the bug or not;
I haven't tested it, though I suspect they do. I do know 4.0.6
has the bug.
I'm not sure what interpretation you are questioning -- if it
is the placement or nature of the fix, sure, I said someone may
want to tweak the location and
Very good eyes Bill, I agree. The correct fix would have to
incorporate both the context name and the constraint URI.
Keith
| -Original Message-
| From: Bill Barker [mailto:wbarker;wilshire.com]
| Sent: Friday, November 08, 2002 2:11 AM
| To: Tomcat Developers List
| Subject: Re: auth
between the tests.
I'm still investigating, but it may be easier for us to
move to 4.0.
Keith
| -Original Message-
| From: Remy Maucherat [mailto:remm;apache.org]
| Sent: Thursday, November 07, 2002 2:22 AM
| To: Tomcat Developers List
| Subject: Re: Coyote/Http11 under load
|
|
| Keith
It turns out TC 4.0.6 has the same auth bug as 3.3--
it challenges prior to redirects. The immediate problem
this causes is that some browsers will cache and send
credentials for the entire domain after being challenged
for a top level directory without a trailing slash.
So 4.0.6 exhibits this
I'm using http11 on a busy site with more or less Tomcat 3.3 head
(3.3.2-dev). I set up the connector with ServerSoTimeout=5000,
SoTimeout=5000, maxThreads 100, maxSpare 50, minSpare 20.
This yields severe performance problems after only a short time in
service. On reverting back to http10, the
Same box, same app, same test, with Tomcat 4.0.6's http10 and 11 adaptor:
coyote/http1137rq/sec, 406kb/sec
http10 30rq/sec, 181kb/sec
I've always held that 3.3 was more lean and mean than 4.0 but
now I'm wondering if this is just indicating some basic architectural
differences.
|
| [X] I don't want the API's split into separate repo's
| [ ] I don't care
| [ ] I want the API's split into separate repo's.
|
TC 4 has too many external module dependencies as it is.
Keith
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
Tomcat 4.x has a problem -- it challenges for auth
prior to any redirects. This is wrong because it causes
most browsers to cache auth info for the entire domain
when hitting top-level directories.
For example:
WRONG way:
GET /foo - 401
GET /foo with auth
= /;
+return(false);
if ((pattern == null) || (pattern.length() == 0))
pattern = /;
I'll apply this fix if someone more versed in 4.x approves it.
Keith
| -Original Message-
| From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, July 03, 2002 7:34 PM
When using CC2 with TC 3.3.2, every request sets both
the content-length and the transfer-encoding, which
is not only wrong, but can confuse some clients.
Content-Length: 9
Transfer-Encoding: chunked
The 4.0 org.apache.catalina.connector.http.HttpConnector
does not have this problem. Any quick
Hmm, you might try taking xerces out the CLASSPATH property
if there is already one in {ant.home}/lib
I would guess there are two copies of an XML provider in
your classpath.. are you using JDK1.4? I did a google on
this error and apparently it comes up a lot.
Keith
| -Original
+1
Keith
| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, May 21, 2002 9:33 PM
| To: [EMAIL PROTECTED]
| Subject: [VOTE] New committer: Denis Benoit
|
|
| I'd like to propose Denis Benoit Denis.Benoit at fbn.ca as a committer on
| the Tomcat
FYI The ant jspc testcases are failing with head of j-t-j/jasper2:
Using Jasper in jakarta-tomcat/
[wannamak@piper jsp]$ java org.apache.jasper.JspC -v
-d /usr/local/cvs/jakarta-ant/src/etc/testcases/taskdefs/optional/jsp/java
Ah, I thought the JspC task had been around longer.
I agree. The build should now ignore that task unless
an appropriate version of Ant is installed.
Keith
| -Original Message-
| From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
| Sent: Saturday, May 18, 2002 12:03 PM
| To: 'Keith
Yes, put build/tomcat/ant/tomcat-ant.jar in your classpath
and do something like:
property name=jspc value=org.apache.tomcat.ant.Tomcat3Precompiler /
taskdef resource=ant.properties /
target name=jsp
jspc srcdir=/foo/jsps
destdir=tomcat_work_path/webapps/foo
uriroot=/foo/jsps
It's already checked in to Tomcat, so the jar is created
when you do a build.
Keith
| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Friday, May 17, 2002 8:26 AM
| To: Tomcat Developers List
| Subject: RE: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt
|
No, for a Tomcat which has already been installed,
you should use the JspC tomcat option to precompile
JSPs.
What I did is to create an Ant task with the same
functionality as the already-present JspC option,
for use in build environments.
Keith
| -Original Message-
| From: Jason
I agree that's why I wrote the task :-)
Maybe I misuderstood Jason,.. thought he wanted to use
the ant tool post-installation-- tomcat recompile would
be a better option in that case, IMO. But, of course,
the ant tool can be used, if ant is available.
Keith
| -Original Message-
|
You've got it. I thought you were talking post-install, but,
again, if Ant's available you can use the task whenever you
wanted to.
Keith
| -Original Message-
| From: Jason Corley [mailto:[EMAIL PROTECTED]]
| Sent: Friday, May 17, 2002 9:50 AM
| To: Tomcat Developers List
| Subject:
Remember last week when I mentioned the thread problem in 3.3-head?
In PoolTcpEndpoint, when there is a SocketException, we log a
non-fatal error message. The problem began when Remy pointed
the string manager to an empty bundle. StringManager.getString
will return a null rather than throw a
This is why-- in PoolThreadEndpoint, a new thread is
started only when a socket is accepted. Since the npe
happened before this, the whole thing shut down without
running another thread.
So, we need to wrap for Throwable, and I think the best
place to do it is around the accept in PTE.runIt.
I've written some ant tools that allow builds to populate
the Tomcat work directories with precompiled JSPs. I'm
trying to decide a home for them, if any, and was thinking
of a new package org.apache.tomcat.ant .. any other
preference?
code is @ http://apache.org/~keith/
Keith
--
To
:[EMAIL PROTECTED]]
| Sent: Wednesday, May 15, 2002 7:06 PM
| To: Tomcat Developers List
| Subject: Re: ant tools for 3.3
|
|
| On Wed, 15 May 2002, Keith Wannamaker wrote:
|
| I've written some ant tools that allow builds to populate
| the Tomcat work directories with precompiled JSPs. I'm
Hey folks,
There seems to be a threading issue introduced between
3.3 and current 3.3.2-dev head. When running the code
under heavy load with four tcp endpoints (2 http10, ajp12,
ajp13) eventually one of the http connectors disappears
from thread dumps. In going through diffs the most
Costin, et al, if you folks know of a faster way to check for this,
by all means
-Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, April 23, 2002 2:50 PM
| To: [EMAIL PROTECTED]
| Subject: cvs commit:
|
I haven't heard from any 4.0 folks -- any interest
in me doing something similar for that tree?
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Thursday, April 18, 2002 8:58 AM
| To: [EMAIL PROTECTED]
| Subject: cvs commit:
Greetings,
There is a bug in ByteChunk.indexOf which manifests itself
in the safe url parsing. That is, BC.indexOf returns an
offset relative to the start of the byte buffer, rather
than the internal starting point.
So, when safe url checks for indexOf('%'), depending on the
length of the
A 4.x person might want to take a look to make sure this
doesn't happen there, too. The performance and stability
of Netscape is like night and day with this...
Keith
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 20, 2001 2:57 PM
To:
I've been debugging a socket problem in ajpv12 (NT) where bits
are being written by Tomcat to the socket (back to mod_jk), but
jk's read fails with a SHUTDOWN. It's as if the bits don't
quite make it onto the wire, and the socket closure is a hard close.
I thought the point of so_linger was to
this solves the problem, but at least the fix is now
documented for posterity.
Keith
| -Original Message-
| From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, December 12, 2001 2:59 PM
| To: [EMAIL PROTECTED]
| Subject: ajpv12 socket closure
|
|
| I've been debugging a socket
Hi Costin,
Yes, I verified that this does indeed do the trick.
Wonder if Sun is going to fix ResourceBundle to handle this?
Hope so! At any rate, thanks for the tip.
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Monday, November 26, 2001 6:49
I think there may be a problem with resource loading in TC3.3.
If I add a property file to the app class path by setting
org.apache.tomcat.apps.classpath, then the call to
ResourceBundle.getBundle(foo) doesn't find it. Nor does
it get located if I place the said property file in
It would be nice also to display the command that is used
to initialize the jk web config files, jkconf or whatever.
Keith
| -Original Message-
| From: Jeff Turner [mailto:[EMAIL PROTECTED]]
| Sent: Sunday, October 21, 2001 2:44 AM
| To: [EMAIL PROTECTED]
| Subject: [PATCH][3.3]
Henri, I do not think this will be useful
or necessary with the planned changes. I'd
be -1.
r-uri will be used, making the mod_rewrite
folks happy, and the facade will encode the
uri, which implements the spec correctly.
Does this plan break something, the reason
you want to add an Option?
What whould happen in 3.3 if ForwardEscapedURI was chosen?
Wouldn't the facade escape it again?
Keith
| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Monday, October 01, 2001 10:10 AM
| To: [EMAIL PROTECTED]
| Subject: RE: Volunteers for: - RE: TC 3.3:
Why can't we implement the 3.3 collaborative solution in 4.0 ?
That would maintain compatibility.
I just hate to provide an option which could result
in wrong (double escaped) behavior. At the least,
it's one more variable to debug, at worst, it will
generate erroneous bug reports. I'd
I thought you were talking about the mod_jk in the TC3.3
branch. If you're talking j-t-c only, then I don't mind an
Option, as long as it defaults to the 3.3 behavior.
Keith
| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Monday, October 01, 2001 11:24 AM
|
I thought what we decided to do was use
s-uri = r-uri (a URI decoded already in Apache)
and in the facade, re-encode it. So
JK_OPT_FWDURICOMPAT should be the default.
| -Original Message-
| + * We use JkOptions to determine which method to be used
| + *
| + *
I'm not sure I understand why the session id was not
also showing up with r-unparsed_uri. I'm doing some
experimenting now..
Keith
|/login/login.vm%3bjsessionid=q95pbsuof1
| Probably not. It's a side of effect of the last change which was
| to use s-req_uri = ap_escape_uri(r-pool, r-uri);.
Are you using mod_jk?
| -Original Message-
| From: Bill Barker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, September 26, 2001 1:17 PM
| To: [EMAIL PROTECTED]
| Subject: Re: TC 3.3: getRequestURI()
|
|
| I don't get this with RC1. From tomcat-log with debugging enabled for
Hi Bill, would you resubmit a patch that makes use of either
Apache or jk's pools? ie ap_strdup or jk_pool_strdup.
That would be a better way to solve the problem. Apache
modules should and do avoid os memory-allocation routines
like the plague. I think uw_map-p would be ok, but please
do some
I'm +1 for this. It is the best solution.
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
|
| 3. Revert to the use of uri ( i.e. the decoded uri ), and
| change the getRequestURI ( the facade ) to generated a
| 'canonical' encoding.
| Problems:
I was afraid of that... guess os memory allocation it is, then.
Keith
| It looked to me like
| uw_map-p wasn't suitable for per-request allocations (i.e. it would just
| eat memory until the server was re-started), and since this is in common, I
| couldn't use ap_strdup since that breaks all
1 - 100 of 150 matches
Mail list logo
