build error for coyote from JTC CVS against Tomcat 4.0.4 ;[

[GOMEZ Henri]

While trying to rebuild tomcat4 ajp stuff from latest JTC CVS,
I got the following error, while trying to build against the TC 4.0.4


Buildfile: build.xml

init:
 [echo]  Coyote 1.0-dev 

prepare:

static:

report-tc4:
 [echo] Tomcat4 detected 

report-tc33:
 [echo] Tomcat3.3 detected 

report:

compile.shared:

compile.tomcat4:
[javac] Compiling 1 source file to 
/home/root/jakarta-tomcat-connectors/coyote/build/classes
[javac] 
[javac] Found 15 semantic errors compiling 
"/home/root/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteServerSocketFactory.java":
[javac] 
[javac]255. throws IOException, KeyStoreException, 
NoSuchAlgorithmException,
[javac] <--->
[javac] *** Error: The exception "KeyStoreException" is not the same as or a 
subclass of any exception in the throws clause of the overridden method 
"java.net.ServerSocket createSocket(int $1);" declared in type 
"org/apache/catalina/net/ServerSocketFactory".
[javac] 
[javac] 
[javac]255. throws IOException, KeyStoreException, 
NoSuchAlgorithmException,
[javac]
<-->
[javac] *** Error: The exception "NoSuchAlgorithmException" is not the same as or 
a subclass of any exception in the throws clause of the overridden method 
"java.net.ServerSocket createSocket(int $1);" declared in type 
"org/apache/catalina/net/ServerSocketFactory".
[javac] 
[javac] 
[javac]256. CertificateException, UnrecoverableKeyException,
[javac] <-->
[javac] *** Error: The exception "CertificateException" is not the same as or a 
subclass of any exception in the throws clause of the overridden method 
"java.net.ServerSocket createSocket(int $1);" declared in type 
"org/apache/catalina/net/ServerSocketFactory".
[javac] 
[javac] 
[javac]256. CertificateException, UnrecoverableKeyException,
[javac]   <--->
[javac] *** Error: The exception "UnrecoverableKeyException" is not the same as or 
a subclass of any exception in the throws clause of the overridden method 
"java.net.ServerSocket createSocket(int $1);" declared in type 
"org/apache/catalina/net/ServerSocketFactory".
[javac] 
[javac] 
[javac]257. KeyManagementException {
[javac] <>
[javac] *** Error: The exception "KeyManagementException" is not the same as or a 
subclass of any exception in the throws clause of the overridden method 
"java.net.ServerSocket createSocket(int $1);" declared in type 
"org/apache/catalina/net/ServerSocketFactory".
[javac] 
[javac] 
[javac]263. throws IOException, KeyStoreException, 
NoSuchAlgorithmException,
[javac] <--->
[javac] *** Error: The exception "KeyStoreException" is not the same as or a 
subclass of any exception in the throws clause of the overridden method 
"java.net.ServerSocket createSocket(int $1, int $2);" declared in type 
"org/apache/catalina/net/ServerSocketFactory".
[javac] 
[javac] 
[javac]263. throws IOException, KeyStoreException, 
NoSuchAlgorithmException,
[javac]
<-->
[javac] *** Error: The exception "NoSuchAlgorithmException" is not the same as or 
a subclass of any exception in the throws clause of the overridden method 
"java.net.ServerSocket createSocket(int $1, int $2);" declared in type 
"org/apache/catalina/net/ServerSocketFactory".
[javac] 
[javac] 
[javac]264. CertificateException, UnrecoverableKeyException,
[javac] <-->
[javac] *** Error: The exception "CertificateException" is not the same as or a 
subclass of any exception in the throws clause of the overridden method 
"java.net.ServerSocket createSocket(int $1, int $2);" declared in type 
"org/apache/catalina/net/ServerSocketFactory".
[javac] 
[javac] 
[javac]264. CertificateException, UnrecoverableKeyException,
[javac]   <--->
[javac] *** Error: The exception "UnrecoverableKeyException" is not the same as or 
a subclass of any exception in the throws clause of the overridden method 
"java.net.ServerSocket createSocket(int $1, int $2);" declared in type 
"org/apache/catalina/net/ServerSocketFactory".
[javac] 
[javac] 
[javac]265. KeyManagementException {
[javac] <>
[javac] *** Error: The exception "KeyManagementException" is not the same as or a 
subclass of any exception in the throws clause of the overridden method 
"java.net.ServerSocket creat

DO NOT REPLY [Bug 8099] - DefaultServlet looses query string information in redirect

[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=8099

DefaultServlet looses query string information in redirect

[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|4.0.3 Final |4.0.4 Final



--- Additional Comments From [EMAIL PROTECTED]  2002-06-19 08:54 ---
The patch is only present in the 4.1.x releases. Depending on how much more life
the 4.0.x branch has, it will or will not be ported.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: index.*: mod_jk 1.2.0 vs. Apache 2.0.36

[GOMEZ Henri]

>> Hum, I think the problem should be easier to detect (I hope so)
>
>Yeah, I agree. I actually think that my configuration could be screwed
>somewhere, somehow (although I don't see how) because almost all Apache
>2.0.x/Tomcat 3.3.x users would run into this kind of problem...

Not sure. In fact many site make use of :

JkMount /examples/* ajp13

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: index.*: mod_jk 1.2.0 vs. Apache 2.0.36

[Bojan Smojver]

On Wed, 2002-06-19 at 18:45, GOMEZ Henri wrote:

> Hum, I think the problem should be easier to detect (I hope so)

Yeah, I agree. I actually think that my configuration could be screwed
somewhere, somehow (although I don't see how) because almost all Apache
2.0.x/Tomcat 3.3.x users would run into this kind of problem...

Bojan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: index.*: mod_jk 1.2.0 vs. Apache 2.0.36

[GOMEZ Henri]

>Yes, pretty much. I'm guessing that Apache will try it's own page types
>first (index.shtml, index.html etc.) and if if doesn't find any, pass
>the request to Tomcat (through mod_jk) for index.jsp and then index.vm
>(in that order, since that's how it's specified in DirectoryIndex).
>
>Just for the record, the server displayed the content of the directory
>(this is on the test machine where that's allowed).
>
>When I put explicit URL in the address field of the brower (e.g.
>http://www.testsite.dev/index.vm) it does work (i.e. Tomcat 
>picks up the
>servlet that handles *.vm pages etc.).

Hum, I think the problem should be easier to detect (I hope so)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Bug 6832] - Locale of the browser is ignored by the AJP13 connector

[GOMEZ Henri]

>I apologize. It is never fair to take out one's frustrations 
>on another.

Ok, I could understand your language problem and I'll try to
fix it.

The problem is that TC 4.0.4 is out, and that patch may need
a corrected tarball for connectors (and tomcat-ajp.jar)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: index.*: mod_jk 1.2.0 vs. Apache 2.0.36

[Bojan Smojver]

Yes, pretty much. I'm guessing that Apache will try it's own page types
first (index.shtml, index.html etc.) and if if doesn't find any, pass
the request to Tomcat (through mod_jk) for index.jsp and then index.vm
(in that order, since that's how it's specified in DirectoryIndex).

Just for the record, the server displayed the content of the directory
(this is on the test machine where that's allowed).

When I put explicit URL in the address field of the brower (e.g.
http://www.testsite.dev/index.vm) it does work (i.e. Tomcat picks up the
servlet that handles *.vm pages etc.).

Bojan

On Wed, 2002-06-19 at 18:23, GOMEZ Henri wrote:
> The question is :
> 
> What should do http server ?
> 
> forward to tomcat /index.jsp and if it fail, try next
> to forward /index.vm ?
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .) 
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
> 
> 
> 
> >-Original Message-
> >From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> >Sent: Wednesday, June 19, 2002 1:19 AM
> >To: Tomcat Dev List
> >Subject: RE: index.*: mod_jk 1.2.0 vs. Apache 2.0.36
> >
> >
> >It doesn't work in either case. In this case it should be index.vm,
> >since that's the file that exists in the directory.
> >
> >Bojan
> >
> >On Tue, 2002-06-18 at 19:58, GOMEZ Henri wrote:
> >> question.
> >> 
> >> Should mod_jk forward to tomcat index.jsp or index.vm ?
> >> 
> >> -
> >> Henri Gomez ___[_]
> >> EMAIL : [EMAIL PROTECTED](. .) 
> >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
> >> 
> >> 
> >> 
> >> >-Original Message-
> >> >From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> >> >Sent: Monday, June 17, 2002 1:11 PM
> >> >To: Tomcat Dev List
> >> >Subject: index.*: mod_jk 1.2.0 vs. Apache 2.0.36
> >> >
> >> >
> >> >I've submitted a bug regarding this (9913) since it still 
> >appears to be
> >> >there in the above combo.
> >> >
> >> >This should be very simple to test (you just whack an index.jsp in a
> >> >directory), so if someone can confirm that my configuration is
> >> >brain-dead (because this is such an unlikely bug :-), that would be
> >> >nice.
> >> >
> >> >Bojan
> >> >
> >> >
> >> >--
> >> >To unsubscribe, e-mail:   
> >> >
> >> >For additional commands, e-mail: 
> >> >
> >> >
> >> >
> >> 
> >> --
> >> To unsubscribe, e-mail:   
> 
> > For additional commands, e-mail: 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] When Session Max reached, throw out oldest session

[andre . powroznik]

It may be configurable, to allow both choices?

André

-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: 19 June 2002 10:26
To: Tomcat Developers List
Subject: RE: [PATCH] When Session Max reached, throw out oldest session


>Agreed... If we start invalidating sessions when too much memory is
>"wasted", I'm going to choose a different servlet engine for 
>my 10m req/day
>site... :) If I define that a session has a timeout, I want 
>that timeout to
>be _real_ and if I run into memory problems, well, that's my 
>problem, not
>yours (servlet engine developers)...
>

I agree.

If there is no more slots open for incoming connections (clients),
then the servlet engine should return an error, which could be
handled by a redirector like mod_jk or mod_webapp to forward the
request to another Tomcat.

I'm really against dropping existing sessions.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

 DISCLAIMER  
"This e-mail and any attachments thereto may contain information 
which is confidential and/or protected by intellectual property 
rights and are intended for the sole use of the recipient(s) named above. 
Any use of the information contained herein (including, but not limited to, 
total or partial reproduction, communication or distribution in any form) 
by persons other than the designated recipient(s) is prohibited. 
If you have received this e-mail in error, please notify the sender either 
by telephone or by e-mail and delete the material from any computer. 
Thank you for your cooperation."


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] When Session Max reached, throw out oldest session

[GOMEZ Henri]

>Agreed... If we start invalidating sessions when too much memory is
>"wasted", I'm going to choose a different servlet engine for 
>my 10m req/day
>site... :) If I define that a session has a timeout, I want 
>that timeout to
>be _real_ and if I run into memory problems, well, that's my 
>problem, not
>yours (servlet engine developers)...
>

I agree.

If there is no more slots open for incoming connections (clients),
then the servlet engine should return an error, which could be
handled by a redirector like mod_jk or mod_webapp to forward the
request to another Tomcat.

I'm really against dropping existing sessions.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: index.*: mod_jk 1.2.0 vs. Apache 2.0.36

[GOMEZ Henri]

The question is :

What should do http server ?

forward to tomcat /index.jsp and if it fail, try next
to forward /index.vm ?

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, June 19, 2002 1:19 AM
>To: Tomcat Dev List
>Subject: RE: index.*: mod_jk 1.2.0 vs. Apache 2.0.36
>
>
>It doesn't work in either case. In this case it should be index.vm,
>since that's the file that exists in the directory.
>
>Bojan
>
>On Tue, 2002-06-18 at 19:58, GOMEZ Henri wrote:
>> question.
>> 
>> Should mod_jk forward to tomcat index.jsp or index.vm ?
>> 
>> -
>> Henri Gomez ___[_]
>> EMAIL : [EMAIL PROTECTED](. .) 
>> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
>> 
>> 
>> 
>> >-Original Message-
>> >From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
>> >Sent: Monday, June 17, 2002 1:11 PM
>> >To: Tomcat Dev List
>> >Subject: index.*: mod_jk 1.2.0 vs. Apache 2.0.36
>> >
>> >
>> >I've submitted a bug regarding this (9913) since it still 
>appears to be
>> >there in the above combo.
>> >
>> >This should be very simple to test (you just whack an index.jsp in a
>> >directory), so if someone can confirm that my configuration is
>> >brain-dead (because this is such an unlikely bug :-), that would be
>> >nice.
>> >
>> >Bojan
>> >
>> >
>> >--
>> >To unsubscribe, e-mail:   
>> >
>> >For additional commands, e-mail: 
>> >
>> >
>> >
>> 
>> --
>> To unsubscribe, e-mail:   

> For additional commands, e-mail: 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Bug 6832] / Hum need coyote here

[GOMEZ Henri]

Or the better way could be to copy CoyoteRequest code.
But there will be 3 copy of Accept-Language decoding
in TC 4.x, may be it should be placed elsewhere and
useable by HttpProcessor, CoyoteRequest and AJP13
(may be tomcat-util ?)
>>>
>>>For Jk2, TC 4.x already is using a CoyoteRequest, so you 
>should be fine.
>>>It's only the o.a.ajp connectors that need Accept-Language parsing.
>> 
>> 
>> Can we officially deprecate o.a.ajp ? 
>
>+1. I think this has already been voted, actually.

So what could we do with TC 4.0.4 and AJP for getLocales() ?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 8099] - DefaultServlet looses query string information in redirect

[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=8099

DefaultServlet looses query string information in redirect

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2002-06-19 08:18 ---
The fix is not included in the final release of Tomcat 4.0.4.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: