DO NOT REPLY [Bug 21529] New: - Bug in org.apache.catalina.authenticator.DigestAuthenticator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21529

Bug in org.apache.catalina.authenticator.DigestAuthenticator

   Summary: Bug in
org.apache.catalina.authenticator.DigestAuthenticator
   Product: Tomcat 4
   Version: 4.1.24
  Platform: All
OS/Version: All
Status: UNCONFIRMED
  Severity: Blocker
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


line 317:
  qop = removeQuotes(currentTokenValue);
needs to be:
  qop = currentTokenValue;

I was using the Tomcat 4.1.24 code as an example for Digest Authentication and
discovered that the hashes weren't matching in my code.  Since "auth" was being
stripped to "ut", the hashes were screwed up.  I checked the RFC 2617 spec
http://asg.web.cmu.edu/rfc/rfc2617.html#sec-3.5 and qop doesn't have quotes.

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

Re: [5.0] [PROPOSAL] Make output buffer size limit configurable

[Bill Barker]

- Original Message -
From: "Jan Luehe" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, July 11, 2003 10:11 AM
Subject: Re: [5.0] [PROPOSAL] Make output buffer size limit configurable


> Remy,
>
> > Jan Luehe wrote:
> >
> >> Currently, the limit up to which the size of an
> >> org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
> >> original buffer size:
> >>
> >> public OutputBuffer(int size) {
> >>
> >> bb = new ByteChunk(size);
> >> bb.setLimit(size);
> >> ...
> >> cb = new CharChunk(size);
> >> cb.setLimit(size);
> >> }
> >>
> >> As a result of this, if the response does not fit in the output
> >> buffer, the buffer is flushed, and the response does no longer include
> >> a "Content-Length" header. Instead, it includes a "Transfer-Encoding"
> >> header whose value is "chunked":
> >>
> >>   Transfer-Encoding: chunked
> >>
> >> It may be useful (e.g., for some benchmarks such as TPC-W) to be able
> >> to configure a connector such that the buffer size of its responses
> >> grows infinitely, in which case the above "setLimit" calls would not
> >> occur and the response would always include a "Content-Length" header,
> >> no matter how big.
> >>
> >> I am proposing a CoyoteConnector attribute "outLimited" (I am open to
> >> other naming suggestions), whose possible values may be "TRUE"
> >> (default) or "FALSE": if "TRUE", the output buffer size limit is set
> >> to the output buffer size (current behaviour), and if "FALSE", an
> >> output buffer may grow infinitely.
> >>
> >> Comments?
> >
> >
> > -1. The performance impact of chunking on the server side is zero. If
> > you client bench program is dumb and its performance degrades with
> > chunking, fine, but please keep this "optimization" for SunOne ;-) Your
> > change basically does an automatic DoS condition on the server (simply
> > request a big file and boom).
>
> How about making the output buffer size limit configurable?
> (A value of "-1" could mean indefinite growth, if people know what they
> are doing.)
>

I also dislike the proposal, but since it's configurable, and off by default
I can limit myself to -0.  The biggest problem I see is that "if people know
what they are doing", then they would never dream of enabling the option :).

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

This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

Re: [RFC] Handling the '*' URL

[Bill Barker]

Well, it seems that the consensus is for the default servlet.  That's where
I'll make the changes for 3.3.

- Original Message -
From: "Keith Wannamaker" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, July 11, 2003 5:35 AM
Subject: RE: [RFC] Handling the '*' URL


> 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]
> | Sent: Friday, July 11, 2003 2:08 AM
> | To: Tomcat Developers List
> | Subject: [RFC] Handling the '*' URL
> |
> |
> | This is really a Request-For-Comments, I'm not proposing anything.  I'm
> | looking into resolving Bug #21454.
> |
> | At the moment, requests for e.g:
> |   OPTIONS * HTTP/1.1
> |   TRACE * HTTP/1.1
> | get properly handled by TC 5 (thanks to Keith's patch), buy passing them
to
> | DefaultServlet.  However, the '*' URL is really a HTTP Protocol URL, so
it
> | seems to me that it really should be handled by the Connector instead of
the
> | Servlet.  On the other hand, we have access to the rich Servlet-API
> | implementations (Ok, so I don't in 3.3-land, but I can fake it ;-).  So
my
> | problem is that I can't see the correct route to go here.
> |
> | Opinions?
> |
> |
> | -
> | To unsubscribe, e-mail: [EMAIL PROTECTED]
> | For additional commands, e-mail: [EMAIL PROTECTED]
> |
> |
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

Trying to make a patch, confused by Tomcat's CVS setup

[David Wood]

Hi, I have two patches for outstanding bugs of 4.1.24. I'm trying to pull 
down sources via CVS, both to make sure these patches are still needed, 
and to build the patch files themselves. I followed the instructions here:

http://jakarta.apache.org/site/cvsindex.html

I pulled out files tagged TOMCAT_4_1_24. But, when I happened to compare 
what I pulled down to what is in the 4.1.24 source archive distributed 
from the Tomcat site, I found radical differences. 

What am I doing wrong? IOW, what repository are the source release 
archives built from, and how can I get at it? 


P.S. On the file that I checked, the majority of the text was different, 
but the most interesting difference to me was at the top; I include it 
here in case it may this more clear. The first block is from the CVS 
checkout I did (labeled TOMCAT_4_1_24), the second is from the archive 
jakarta-tomcat-4.1.24-LE-jdk14.zip:

2,4c2,4
<  * $Header: 
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java,v 
1.15 2002/05/16 00:41:26 kinman Exp $
<  * $Revision: 1.15 $
<  * $Date: 2002/05/16 00:41:26 $
---
>  * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v 
1.12.2.6 2003/03/17 20:53:39 costin Exp $
>  * $Revision: 1.12.2.6 $
>  * $Date: 2003/03/17 20:53:39 $

Re: tomcat job opportunity

[Bob Lee]

Steven,

I did modify Jasper (Tomcat's JSP engine) a couple years back to 
support scripting languages in the JSP scriptlets. Though I don't have 
intimate knowledge of the Tomcat internals, they are pretty well 
documented, I do use it, and this type of low-level development is my 
specialty (and my favorite ;)). Is the client looking for extensions, 
performance tweaks, web services integration, etc.?

My cel. number is 314-537-6570.

Thanks,
Bob
On Friday, July 11, 2003, at 10:40 AM, Steven Pincus wrote:

Greetings.I work for an executive search firm in NY and am 
currently
looking, on behalf of my client, for a Tomcat software engineering 
with a
solid understanding of Tomcat internals. I can provide more details 
about
the role and the client when we speak.

I was hoping you or someone you know might be interested in speaking 
with me
about this job opportunity.

I appreciate your consideration in advance and hope to hear back from 
you
soon. Thanks - Steven




Steven Pincus
R.W. Davis & Co.
90 Park Avenue
New York, NY 10016
Tel.  (212)231-4400 ext. 216
Fax  (212)993-8080
Cell  (973)722-2163
[EMAIL PROTECTED]
www.rwdavisco.com









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

Re: java Date related classes synchronization bottlenecks

[David Rees]

On Fri, Jul 11, 2003 at 08:57:54AM -0700, David Rees wrote:
> 
> System 4:
> Dual Mips R10k 225MHz, SGI Java 1.4.1 SGI IRIX

I was mistaken about the CPU freq of this machine, it really has 2 R10k
180MHz CPUs, not 225MHz.

-Dave

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

Re: java Date related classes synchronization bottlenecks

[David Rees]

On Fri, Jul 11, 2003 at 10:10:21AM -0700, James Courtney wrote:
> I didn't see an attachment that time.  Thanks as this is interesting
> stuff for Java development of any kind, not just Tomcat!

Stupid me.  Is attached now.

-Dave
import java.sql.*;
import java.util.*;

public class TestDatePerf
extends Thread
{
int iterations;
Timestamp date = null;

public TestDatePerf(int iterations) {
this.iterations = iterations;
date = new Timestamp(System.currentTimeMillis());
}

public void run() {
for (int i = 0; i < iterations; i++) {
date.toString();
}
}

public static void main(String args[]) {
int threads = Integer.parseInt(args[0]);
int iterations = Integer.parseInt(args[1]);
for (int i = 0; i < threads; i++) {
TestDatePerf tdp = new TestDatePerf((int)iterations/threads);
tdp.start();
}
}
}

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

DO NOT REPLY [Bug 21524] New: - Thread Leak

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21524

Thread Leak

   Summary: Thread Leak
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have isolated this problem in the CoyoteConnector thread pooling. Upon every 
HTTP request the thread count goes up and never gets cleaned by the GC. I am 
able to monitor this through the windows task manager (added thread count 
column). Tomcat initially starts with 45 threads; let the server run for 24 
hours (about 70 to 80 HTTP requests) and the thread count is > 230. This 
eventually results in server crash when the VM runs out of heap. Thread pool 
configuration is ...minProcessors="5" maxProcessors="25 acceptCount="10 
enableLookups="false". Increasing JMV memory only delays the crash. This is 
turning out to be a serious problem in our production servers. Is there is work 
around? Server is running on windows-2000 SP3. Java version is 1.3.1_04-b02.

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

Bug in org.apache.catalina.authenticator.DigestAuthenticator

[adam . hathcock]

line 317:
  qop = removeQuotes(currentTokenValue);
needs to be:
  qop = currentTokenValue;

I was using the Tomcat 4.1.24 code as an example for Digest Authentication and
discovered that the hashes weren't matching in my code.  Since "auth" was being
stripped to "ut", the hashes were screwed up.  I checked the RFC 2617 spec
http://asg.web.cmu.edu/rfc/rfc2617.html#sec-3.5 and qop doesn't have quotes.

I searched the list and couldn't find if this was discovered or not, so I
decided to post here :)

Adam Hathcock


-
This mail sent through IMP: http://horde.org/imp/

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

DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16113

removing then replacing a jsp page continues to give a 404





--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 17:36 ---
I have a working patch for this bug; I'd appreciate help/advice from anyone 
more familiar with creating and submitting patches to the Tomcat team.

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

Re: [5.0] [PROPOSAL] Make output buffer size limit configurable

[Jan Luehe]

Remy,

Jan Luehe wrote:

Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {

bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new CharChunk(size);
cb.setLimit(size);
}
As a result of this, if the response does not fit in the output
buffer, the buffer is flushed, and the response does no longer include
a "Content-Length" header. Instead, it includes a "Transfer-Encoding"
header whose value is "chunked":
  Transfer-Encoding: chunked

It may be useful (e.g., for some benchmarks such as TPC-W) to be able
to configure a connector such that the buffer size of its responses
grows infinitely, in which case the above "setLimit" calls would not
occur and the response would always include a "Content-Length" header,
no matter how big.
I am proposing a CoyoteConnector attribute "outLimited" (I am open to 
other naming suggestions), whose possible values may be "TRUE" 
(default) or "FALSE": if "TRUE", the output buffer size limit is set 
to the output buffer size (current behaviour), and if "FALSE", an 
output buffer may grow infinitely.

Comments?


-1. The performance impact of chunking on the server side is zero. If 
you client bench program is dumb and its performance degrades with 
chunking, fine, but please keep this "optimization" for SunOne ;-) Your 
change basically does an automatic DoS condition on the server (simply 
request a big file and boom).
How about making the output buffer size limit configurable?
(A value of "-1" could mean indefinite growth, if people know what they 
are doing.)

Jan



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

RE: java Date related classes synchronization bottlenecks

[James Courtney]

David,
I didn't see an attachment that time.  Thanks as this is interesting stuff for 
Java development of any kind, not just Tomcat!

Jamey


James Courtney
InPhonic, Inc.

-Original Message-
From: David Rees [mailto:[EMAIL PROTECTED]
Sent: Friday, July 11, 2003 8:34 AM
To: [EMAIL PROTECTED]
Subject: Re: java Date related classes synchronization bottlenecks


David Cassidy said:
>
> I've done some tests with the below code
> hope this helps

David,

Could you give this version a try, and run it for 1 million iterations
instead of just 10k?  I'll be posting my results shortly for a couple of
different machines shortly.  The new version keeps the theoretical overall
run time constant by keeping the overall amount of work the same while you
vary the thread count.

So if you supply arguments 1 and 1 million, and then 2 and 1 million, in
the first case 1 thread will go through 1 million iterations, in the
second case each of the two threads will only go throgh 500,000
iterations.  Saves you division.  ;-)

Glenn, it would be interesting for you to modify the code to remove the
synchronization issue and then re-run the quick benchmark.

-Dave

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

DO NOT REPLY [Bug 20663] - Cannot shutdown Tomcat gracefully

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20663

Cannot shutdown Tomcat gracefully





--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 16:02 ---
Created an attachment (id=7248)
Truss output of the SHUTDOWN of tomcat process

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

DO NOT REPLY [Bug 20663] - Cannot shutdown Tomcat gracefully

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20663

Cannot shutdown Tomcat gracefully





--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 16:00 ---
I also get it - right out of the box
(only changed 8080 to 1080)

The exceptin happens in PoolTcpEndpoint.
I attach a truss of the java VM for the whole shutdown, in case
someone is interested. It shows the socket being terminated
without an explicit close() call.

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

Re: java Date related classes synchronization bottlenecks

[David Rees]

Here are the results from the last version of the TestDatePerf program I
sent out.  Below are the results from 3 different systems when run for 1
million iterations.

Here's how I interpret the results:

The program verifies the synchronization performance issue.
Dual-CPU machines take a huge performance hit when going from 1-2
processes fighting for the same synchronized lock.  The dual processor
machine always performs worse than the single processor with more than 1
thread running and doesn't start catching up until 16 threads are running.

I did a few test runs when running 2 threads and watching the output from
top, I noticed that both CPUs were not kept busy (as expected).

Out of curiosity, I also tweaked the progrom and took out the call to
Timestamp.toString() and replaced it with some non-synchronized code. 
This code scaled almost perfectly when going from 1 to 2 threads on the
dual-cpu systems (run-time cut very close to 1/2) and increasing the
number of threads to 16 showed very little performance deviation over the
2 thread case.

So it looks like the bottleneck is real and depending on CPU performance I
would guess that you would start seeing when when you start making a few
thousand calls a second to these methods.

-Dave



Each system ran the following:
time java TestJavaPerf  100
with threads values of 1, 2, 4, 8, 16.

All Linux systems on on kernel 2.4.20.  It would interesting to see if
recent 2.5.x kernels perform better as they reported have improved
multi-thread performance in the latest development kernels.

System 1:
Duron 600MHz, Sun Java 1.4.2, RedHat Linux

System 2:
PIII 500MHz, Sun Java 1.4.2, RedHat Linux

System 3:
Dual PIII 500MHz, Sun Java 1.4.2, RedHat Linux

System 4:
Dual Mips R10k 225MHz, SGI Java 1.4.1 SGI IRIX

Sys# Threads  Real   User   Sys
1160.3   59.6   0.2
1278.2   72.8   5.3
14   122.0   93.1  28.8
18   152.1  105.0  47.0
116  184.4  121.6  62.7
Sys# Threads  Real   User   Sys
2180.5   80.2   0.3
22   108.0  111.2   3.2
24   177.2  141.5  34.4
28   290.1  200.3  88.5
216  325.2  220.0 103.9
Sys# Threads  Real   User   Sys
3180.4   80.2   0.4
32   249.3  221.3  94.8
34   289.8  244.0 124.8
38   309.8  257.6 130.5
316  325.4  264.4 132.2
Sys# Threads  Real   User   Sys
41   197.0  186.9   1.5
42   289.7  487.5   8.9
44  1148.9  996.9 267.0
48  1734.8 1086.0 284.3
416 1717.2 1058.4 284.8


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

Re: java Date related classes synchronization bottlenecks

[David Rees]

David Cassidy said:
>
> I've done some tests with the below code
> hope this helps

David,

Could you give this version a try, and run it for 1 million iterations
instead of just 10k?  I'll be posting my results shortly for a couple of
different machines shortly.  The new version keeps the theoretical overall
run time constant by keeping the overall amount of work the same while you
vary the thread count.

So if you supply arguments 1 and 1 million, and then 2 and 1 million, in
the first case 1 thread will go through 1 million iterations, in the
second case each of the two threads will only go throgh 500,000
iterations.  Saves you division.  ;-)

Glenn, it would be interesting for you to modify the code to remove the
synchronization issue and then re-run the quick benchmark.

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

tomcat job opportunity

[Steven Pincus]

Greetings.I work for an executive search firm in NY and am currently
looking, on behalf of my client, for a Tomcat software engineering with a
solid understanding of Tomcat internals. I can provide more details about
the role and the client when we speak.  
 
I was hoping you or someone you know might be interested in speaking with me
about this job opportunity.  
 
I appreciate your consideration in advance and hope to hear back from you
soon. Thanks - Steven  
 



 
Steven Pincus 
R.W. Davis & Co. 
90 Park Avenue 
New York, NY 10016 

Tel.  (212)231-4400 ext. 216 
Fax  (212)993-8080 
Cell  (973)722-2163 

[EMAIL PROTECTED] 
www.rwdavisco.com 

 


 

 

DO NOT REPLY [Bug 21456] - logs/context lost when restarting Context

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21456

logs/context lost when restarting Context

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 14:44 ---
With the new version of admin.war I attach, this bug is resolved.

For the patch, I took the code of restart in
admin-tomcat3.3.2-nightlybuild-on-20030710 (less a new functionnality)
and I add new things as :
- context list sorted by host:path
- a log with the user restarting context
- and a button "Return to Context List" with Pragma=no-cache (instead of a http
link).
Thank you to William.

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

DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16113

removing then replacing a jsp page continues to give a 404





--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 14:40 ---
We're seeing it too. Very nasty.

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

DO NOT REPLY [Bug 21456] - logs/context lost when restarting Context

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21456

logs/context lost when restarting Context





--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 14:36 ---
Created an attachment (id=7245)
diff between this new version and the tomcat-332-nightlybuild-on-20030710

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

DO NOT REPLY [Bug 21456] - logs/context lost when restarting Context

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21456

logs/context lost when restarting Context





--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 14:34 ---
Created an attachment (id=7244)
new admin.war with : patch 21456 from tomcat332 + logRestart + contextsList sorted + 
contextsList with no cache

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

DO NOT REPLY [Bug 3614] - bug in manager webapp

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3614

bug in manager webapp

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 14:26 ---
The bu is not resolved, i'm using tomcat 4.1.18 and the bug is still active

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

RE: [RFC] Handling the '*' URL

[Keith Wannamaker]

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]
| Sent: Friday, July 11, 2003 2:08 AM
| To: Tomcat Developers List
| Subject: [RFC] Handling the '*' URL
| 
| 
| This is really a Request-For-Comments, I'm not proposing anything.  I'm
| looking into resolving Bug #21454.
| 
| At the moment, requests for e.g:
|   OPTIONS * HTTP/1.1
|   TRACE * HTTP/1.1
| get properly handled by TC 5 (thanks to Keith's patch), buy passing them to
| DefaultServlet.  However, the '*' URL is really a HTTP Protocol URL, so it
| seems to me that it really should be handled by the Connector instead of the
| Servlet.  On the other hand, we have access to the rich Servlet-API
| implementations (Ok, so I don't in 3.3-land, but I can fake it ;-).  So my
| problem is that I can't see the correct route to go here.
| 
| Opinions?
| 
| 
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
| 
| 

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

DO NOT REPLY [Bug 21504] New: - Possible clash of workdirs where compile JSPs are stored

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21504

Possible clash of workdirs where compile JSPs are stored

   Summary: Possible clash of workdirs where compile JSPs are stored
   Product: Tomcat 5
   Version: 5.0.3
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Web application deployed at default context root ("/") stores by default its
compiled JSPs in $CATALINA_HOME/work/Catalina/localhost/_ subtree. This may
cause trouble if anyone deploys another application to "/_" context path as it
will try to use the same directory.

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

DO NOT REPLY [Bug 12263] - response.sendRedirect won't send to Tomcat SSL

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12263

response.sendRedirect won't send to Tomcat SSL





--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 12:31 ---
I believe this is fixed in the upcoming 4.1.25.

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

DO NOT REPLY [Bug 21503] New: - [PATCH] Need to add special emphasis for windows service to setting JAVA_HOME

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21503

[PATCH] Need to add special emphasis for windows service to setting JAVA_HOME

   Summary: [PATCH] Need to add special emphasis for windows service
to setting JAVA_HOME
   Product: Tomcat 4
   Version: 4.1.25
  Platform: All
   URL: http://jakarta.apache.org/tomcat/tomcat-4.1-
doc/RUNNING.txt
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Webapps:Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If you don't notice that you HAVE to set JAVA_HOME before tomcat is installed,
tomcat will NOT work as a service.  This will cause no end of pain because only
one bug report even mentions this issue.  Google did not reveal the fix.

  * Set an environment variable JAVA_HOME to the pathname of the directory
-   into which you installed the JDK release.
+   into which you installed the JDK release.  WINDOWS NOTE: Tomcat will
+   NOT work as a service if this is not set prior to installing tomcat.

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

DO NOT REPLY [Bug 21502] New: - [PATCH]Manager doesn't use correct method to get number of active sessions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21502

[PATCH]Manager doesn't use correct method to get number of active sessions 

   Summary: [PATCH]Manager doesn't use correct method to get number
of active sessions
   Product: Tomcat 4
   Version: 4.1.25
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The question is: Why turn a hashmap into an array just to take its
length when you already have a method that returns the number of
sessions?  This will make the life of people who write session managers
that DON'T store all the active sessions in memory easier.


--- HTMLManagerServlet.java 2003-03-19 04:18:34.0 -0500
+++ HTMLManagerServlet.java 2003-07-08 09:22:04.0 -0400
@@ -403,7 +403,7 @@
 (request.getContextPath() + "/html/sessions?path=" +
displayPath);
 args[4] =
-new Integer(context.getManager().findSessions().length);
+new Integer(context.getManager().getActiveSessions());
 writer.print(MessageFormat.format(APPS_ROW_DETAILS_SECTION,args));

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

DO NOT REPLY [Bug 12263] - response.sendRedirect won't send to Tomcat SSL

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12263

response.sendRedirect won't send to Tomcat SSL





--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 12:16 ---
We are having a similar issue. I assume that this has to do with the fact that
Tomcat Coyote connector knows about proxyName and proxyPort attributes, however
assumes always http for the proxy. If you are using a HTTPS reverse proxy (or as
you, a Stronghold Apache frontend), the 302 redirect "Location" header receives
the wrong full qualified URL.

I didn't do any further investigation, but I suggest the solution of adding a
proxyScheme attribute which by default is http, but can be overridden with
"https", the only alternative valid value.

I also would change the Component of this bug, but I leave this to active
developers to decide.

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

Re: [RFC] Handling the '*' URL

[Remy Maucherat]

Bill Barker wrote:
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, July 10, 2003 11:29 PM
Subject: Re: [RFC] Handling the '*' URL


Bill Barker wrote:

This is really a Request-For-Comments, I'm not proposing anything.  I'm
looking into resolving Bug #21454.
At the moment, requests for e.g:
 OPTIONS * HTTP/1.1
 TRACE * HTTP/1.1
get properly handled by TC 5 (thanks to Keith's patch), buy passing them
to

DefaultServlet.  However, the '*' URL is really a HTTP Protocol URL, so
it

seems to me that it really should be handled by the Connector instead of
the

Servlet.  On the other hand, we have access to the rich Servlet-API
implementations (Ok, so I don't in 3.3-land, but I can fake it ;-).  So
my

problem is that I can't see the correct route to go here.

Opinions?
I'm only talking about OPTIONS here. TRACE is protocol specific for all
URLs (but I don't care about it ;-) ).
I think it should be handled by the servlet, because for example you can
replace the default servlet by the WebDAV servlet, and then it should
return the DAV methods.


At the moment (at least in TC 5, which is the only one that returns a 200
Response), this is handled by the Default-Servlet (which ever one is mapped
to '/', which defaults to DefaultServlet) in the ROOT Context.  So, the
current response according to you is still wrong if I have the the 'webdav'
Context installed.

If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to
apply to the server in general rather than to a specific resource. Since a
server's communication options typically depend on the resource, the "*"
request is only useful as a "ping" or "no-op" type of method; it does
nothing beyond allowing the client to test the capabilities of the server.
For example, this can be used to test a proxy for HTTP/1.1 compliance (or la
ck thereof).

I'm starting to lean to putting this into the Connector, rather than sending
it to the Servlet (who can't possibly give a server-wide answer).  Note:
I'm only interested in the case where the Request-URI.equals("*").  All
other cases will go to the Servlet.
In my reasoning, I was implying that I had the asumption that the 
default servlet of the root context was a fair representation of what 
the server could do.

Both work for me :)

Remy

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

cvs commit: jakarta-tomcat-site/xdocs-faq connectors.xml

[funkman]

funkman 2003/07/11 03:57:20

  Modified:docs/faq connectors.html
   docs/faq/printer connectors.html
   xdocs-faq connectors.xml
  Log:
  Add q about jk2 config file location based on tomcat user conversation
  
  http://marc.theaimsgroup.com/?t=10578489323&r=1&w=2
  
  Revision  ChangesPath
  1.5   +33 -0 jakarta-tomcat-site/docs/faq/connectors.html
  
  Index: connectors.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/connectors.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- connectors.html   11 Jul 2003 01:57:37 -  1.4
  +++ connectors.html   11 Jul 2003 10:57:19 -  1.5
  @@ -101,6 +101,14 @@
   At boot, is order of start up (Apache vs Tomcat) important?
 
   
  +
  +  
  + JK2 doesn't seem to be using my settings in my
  + workers2.properties file
  + such as creating the shm file or mapping the URIs listed to Tomcat,
  + what's wrong?
  +  
  +
 
   
   Answers
  @@ -241,6 +249,31 @@
   No. This way - either apache or tomcat can be restarted at any time
   independent of one another.
 
  +
  +  
  +
  + JK2 doesn't seem to be using my settings in my
  + workers2.properties file
  + such as creating the shm file or mapping the URIs listed to Tomcat,
  + what's wrong?
  +
  +  
  +  
  +JK2 is not finding your workers2.properties file.
  +Specify it's location in your httpd.conf file by adding:
  +
  +
  +
  +JkSet config.file /full/system/path/to/workers2.properties
  +
  +
  +http://marc.theaimsgroup.com/?t=10578489323&r=1&w=2";>
  +Thread which spawned this question.
  +
  +  
  +
  +
  +
   
   
   
  
  
  
  1.4   +33 -0 jakarta-tomcat-site/docs/faq/printer/connectors.html
  
  Index: connectors.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/printer/connectors.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- connectors.html   11 Jul 2003 01:57:39 -  1.3
  +++ connectors.html   11 Jul 2003 10:57:20 -  1.4
  @@ -100,6 +100,14 @@
   At boot, is order of start up (Apache vs Tomcat) important?
 
   
  +
  +  
  + JK2 doesn't seem to be using my settings in my
  + workers2.properties file
  + such as creating the shm file or mapping the URIs listed to Tomcat,
  + what's wrong?
  +  
  +
 
   
   Answers
  @@ -240,6 +248,31 @@
   No. This way - either apache or tomcat can be restarted at any time
   independent of one another.
 
  +
  +  
  +
  + JK2 doesn't seem to be using my settings in my
  + workers2.properties file
  + such as creating the shm file or mapping the URIs listed to Tomcat,
  + what's wrong?
  +
  +  
  +  
  +JK2 is not finding your workers2.properties file.
  +Specify it's location in your httpd.conf file by adding:
  +
  +
  +
  +JkSet config.file /full/system/path/to/workers2.properties
  +
  +
  +http://marc.theaimsgroup.com/?t=10578489323&r=1&w=2";>
  +Thread which spawned this question.
  +
  +  
  +
  +
  +
   
   
   
  
  
  
  1.4   +33 -0 jakarta-tomcat-site/xdocs-faq/connectors.xml
  
  Index: connectors.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs-faq/connectors.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- connectors.xml11 Jul 2003 01:57:39 -  1.3
  +++ connectors.xml11 Jul 2003 10:57:20 -  1.4
  @@ -114,6 +114,14 @@
   At boot, is order of start up (Apache vs Tomcat) important?
 
   
  +
  +  
  + JK2 doesn't seem to be using my settings in my
  + workers2.properties file
  + such as creating the shm file or mapping the URIs listed to Tomcat,
  + what's wrong?
  +  
  +
 
   
   
  @@ -257,6 +265,31 @@
   No. This way - either apache or tomcat can be restarted at any time
   independent of one another.
 
  +
  +  
  +
  + JK2 doesn't seem to be using my settings in my
  + workers2.properties file
  + such as creating the shm file or mapping the URIs listed to Tomcat,
  + what's wrong?
  +
  +  
  +  
  +JK2 is not finding your workers2.properties file.
  +Specify it's location in your httpd.conf file by adding:
  +
  +
  +
  +JkSet config.file /full/system/path/to/workers2.properties
  +
  +
  +
  +Thread which spawned this question.
  +
  +  
  +
  +
  +
   
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
F

[GUMP] Build timed out - jk2

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml

init.taskdef:

guess.os:
 [echo] build.properties i386.Linux
 [echo] Linux:true Win32:${win32} Netware:${netware} Solaris:${solaris} 
HPUX:${hpux}

init.win32.properties:

init.win32.mc:

init.win32:

init.netware:

init.os:

guess.server:
 [echo] Apache2 /usr/local/apache2 true
 [echo] Apache13 /usr true
 [echo] IIS ${iis.home} ${iis.detect}
 [echo] Iplanet ${iplanet.home} ${iplanet.detect}
 [echo] AOLserver ${aolserver.home} ${aolserver.detect}
 [echo] JNI true


init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk2

apache20:
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk2/apache2
   [so] Compiling 42 out of 42
Compiling 
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c
/home/rubys/bin/timeout: timed out

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

Re: java Date related classes synchronization bottlenecks

[David Cassidy]

I've done some tests with the below code
hope this helps

David

10 Processor Sun Sparc 2i 400Mhz (Solaris 2.8) jdk 1.4.0-b92

time java TestDatePerf  1 1 real0m2.096s user0m1.901s sys 0m0.142s
time java TestDatePerf  2 1 real0m4.848s user0m4.240s sys 0m1.372s
time java TestDatePerf  3 1 real0m7.449s user0m6.530s sys 0m3.312s
time java TestDatePerf  4 1 real0m11.140s user   0m8.661s sys 0m4.543s
time java TestDatePerf  5 1 real0m13.194s user   0m11.001s sys 0m7.182s
time java TestDatePerf  6 1 real0m17.981s user   0m12.381s sys 0m8.602s
time java TestDatePerf  7 1 real0m20.659s user   0m15.271s sys 0m10.102s
time java TestDatePerf  8 1 real0m22.540s user   0m17.501s sys 0m13.603s
time java TestDatePerf  9 1 real0m26.457s user   0m19.991s sys 0m14.793s
time java TestDatePerf 10 1 real0m32.006s user   0m22.451s sys 0m15.923s
time java TestDatePerf 20 1 real0m57.951s user   0m43.660s sys 0m37.772s
time java TestDatePerf 30 1 real1m23.016s user   1m6.050s  sys 0m56.952s
time java TestDatePerf 40 1 real1m52.507s user   1m28.651s sys 1m15.832s
time java TestDatePerf 50 1 real2m21.881s user   1m49.161s sys 1m35.772s

linux dual 2.8Ghz P4  (kernel 2.4.19 ) jdk1.4.1_03-b02

time java TestDatePerf  1 1  real0m0.453s user0m0.410s sys 0m0.020s
time java TestDatePerf  2 1  real0m1.411s user0m1.390s sys 0m0.410s
time java TestDatePerf  3 1  real0m3.119s user0m2.890s sys 0m1.610s
time java TestDatePerf  4 1  real0m3.690s user0m3.040s sys 0m1.780s
time java TestDatePerf  5 1  real0m4.630s user0m3.330s sys 0m2.360s
time java TestDatePerf  6 1  real0m5.410s user0m4.530s sys 0m2.480s
time java TestDatePerf  7 1  real0m6.310s user0m5.030s sys 0m3.000s
time java TestDatePerf  8 1  real0m7.330s user0m5.510s sys 0m3.590s
time java TestDatePerf  9 1  real0m8.682s user0m6.970s sys 0m4.060s
time java TestDatePerf 10 1  real0m9.648s user0m7.730s sys 0m4.760s
time java TestDatePerf 20 1  real0m19.270s user0m15.500s sys 0m9.210s
time java TestDatePerf 30 1  real0m32.570s user0m26.940s sys 0m14.740s
time java TestDatePerf 40 1  real0m42.492s user0m35.130s sys 0m20.560s
time java TestDatePerf 50 1  real0m57.209s user0m47.040s sys 0m25.330s




   

  David Rees   

  <[EMAIL PROTECTED]To:   Tomcat Developers List 
<[EMAIL PROTECTED]>
  .com>cc: 

   Subject:  Re: java Date related classes 
synchronization bottlenecks 
  11/07/2003 02:52 

  Please respond to

  "Tomcat  

  Developers List" 

   

   





On Thu, Jul 10, 2003 at 05:46:06PM -0500, Glenn Nielsen wrote:
>
> Now use jar to unarchive the src.jar file in your java SDK.
> Take a look at the java.sql.Timestamp.toString() method which the FileLogger
> above uses.
>
> To verify this look at the source for java.util.Date.getField().

Yes, that looks bad (looking at 1.4.2 src)!  It appears that avoiding calls to the
Timestamp.toString() is really to be avoided if possible.

> And there are many other synchronization bottlenecks in the following Date
> related classes:
>
> java.util.Calendar.getInstance()
> java.util.Date
> java.ut

DO NOT REPLY [Bug 21489] - Catalina-ant task: problem with config parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21489

Catalina-ant task: problem with config parameter

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

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

DO NOT REPLY [Bug 21489] - Catalina-ant task: problem with config parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21489

Catalina-ant task: problem with config parameter





--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 08:57 ---
Why does the file:// format work for the "war=" attribute? Should that not also 
give an error then?

And which format should then be used withing the context.xml for the 
docbase="xxx" 
attribute?

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

DO NOT REPLY [Bug 21489] - Catalina-ant task: problem with config parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21489

Catalina-ant task: problem with config parameter





--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 08:48 ---
IMO this is not a bug. "file://C:/Tomcat4.1/webapps/context.xml" is wrong and
the fact that browsers like IE can accept such URL is not important here. One or
three slashes work (//, empty host name and leading slash from path). Ad spaces:
you should be able to use + or %20. I guess this should be closed as invalid.

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

DO NOT REPLY [Bug 21472] - JDBCRealm: Auth ok but Not Authorized

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21472

JDBCRealm: Auth ok but Not Authorized





--- Additional Comments From [EMAIL PROTECTED]  2003-07-11 07:40 ---
thank you and sorry :-(

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

Re: [RFC] Handling the '*' URL

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, July 10, 2003 11:29 PM
Subject: Re: [RFC] Handling the '*' URL


> Bill Barker wrote:
> > This is really a Request-For-Comments, I'm not proposing anything.  I'm
> > looking into resolving Bug #21454.
> >
> > At the moment, requests for e.g:
> >   OPTIONS * HTTP/1.1
> >   TRACE * HTTP/1.1
> > get properly handled by TC 5 (thanks to Keith's patch), buy passing them
to
> > DefaultServlet.  However, the '*' URL is really a HTTP Protocol URL, so
it
> > seems to me that it really should be handled by the Connector instead of
the
> > Servlet.  On the other hand, we have access to the rich Servlet-API
> > implementations (Ok, so I don't in 3.3-land, but I can fake it ;-).  So
my
> > problem is that I can't see the correct route to go here.
> >
> > Opinions?
>
> I'm only talking about OPTIONS here. TRACE is protocol specific for all
> URLs (but I don't care about it ;-) ).
>
> I think it should be handled by the servlet, because for example you can
> replace the default servlet by the WebDAV servlet, and then it should
> return the DAV methods.
>

At the moment (at least in TC 5, which is the only one that returns a 200
Response), this is handled by the Default-Servlet (which ever one is mapped
to '/', which defaults to DefaultServlet) in the ROOT Context.  So, the
current response according to you is still wrong if I have the the 'webdav'
Context installed.


If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to
apply to the server in general rather than to a specific resource. Since a
server's communication options typically depend on the resource, the "*"
request is only useful as a "ping" or "no-op" type of method; it does
nothing beyond allowing the client to test the capabilities of the server.
For example, this can be used to test a proxy for HTTP/1.1 compliance (or la
ck thereof).


I'm starting to lean to putting this into the Connector, rather than sending
it to the Servlet (who can't possibly give a server-wide answer).  Note:
I'm only interested in the case where the Request-URI.equals("*").  All
other cases will go to the Servlet.


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


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