cvs commit: jakarta-tomcat-catalina/webapps/docs/config valve.xml
billbarker2003/12/15 23:22:14 Modified:webapps/docs/config valve.xml Log: Updating SSO docs. Fix for Bug #2 Submitted by: Brian Stansberry [EMAIL PROTECTED] Revision ChangesPath 1.6 +11 -0 jakarta-tomcat-catalina/webapps/docs/config/valve.xml Index: valve.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/valve.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- valve.xml 4 Nov 2003 17:58:46 - 1.5 +++ valve.xml 16 Dec 2003 07:22:14 - 1.6 @@ -350,6 +350,17 @@ pDetail level of debugging messages created by this component. By default, this is set to zero (0), which means no debug output./p /attribute + + attribute name=requireReauthentication required=false +pDefault false. Flag to determine whether each request needs to be +reauthenticated to the security strongRealm/strong. If true, this +Valve uses cached security credentials (username and password) to +reauthenticate to the strongRealm/strong each request associated +with an SSO session. If false, the Valve can itself authenticate +requests based on the presence of a valid SSO cookie, without +rechecking with the strongRealm/strong./p + /attribute + /attributes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25555] - SingleSignOn valve config doc missing requireReauthentication attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2. 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=2 SingleSignOn valve config doc missing requireReauthentication attribute [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-16 07:23 --- Patch committed. Thanks much! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25557] New: - Not accepting username/password in Global.properties in tomcat 4.0.3
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25557. 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=25557 Not accepting username/password in Global.properties in tomcat 4.0.3 Summary: Not accepting username/password in Global.properties in tomcat 4.0.3 Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have tomcat 4.0.3 with jdk1.4. with SQL Server 2000, when i try to connect to my web application it doesnt accept the username/password specified in WEB- INF\Global.properties file. I have double checked the password in the database and even changed it again to the one mentioned in Global.properties file, but it still odesnt work. One day it works and the next day it stops accepting the username/password. What might be wrong? Can anyone help me? I am a beginner. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25528.
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=25528
WebappClassloader does not register with RMI codebase cache
--- Additional Comments From [EMAIL PROTECTED] 2003-12-16 08:51 ---
The getURLs() method is called too often in tomcat 4. The
sun.rmi.server.LoaderHandler class has a piece of code like this:
ClassLoader classloader = class1.getClassLoader();
if(classloader == null || codebaseLoaders.containsKey(classloader))
return codebase;
String s1 = null;
if(classloader instanceof Loader)
s1 = ((Loader)classloader).getClassAnnotation();
else
if(classloader instanceof URLClassLoader)
try
{
URL aurl[] = ((URLClassLoader)classloader).getURLs();
(...)
You see; it checks to see if the classloader is 'known', if so this method
getClassAnnotation returns the codebase directly. If not, it calls the getURLs
() method for EVERY class deserialization! That is because the codeBaseLoaders
cache does not contain the WebappClassLoader for Tomcat 4.
I still think it's a bug that should be fixed in version 4; or at least made
known to people because it has high performance impact for all use or RMI with
tomcat 4 (see usenet for a lot of people with the same problems)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25528. 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=25528 WebappClassloader does not register with RMI codebase cache --- Additional Comments From [EMAIL PROTECTED] 2003-12-16 09:12 --- we tested this on tomcat 5 too and the problem persists. I just checked the 5.0.16 source of tomcat catalina; cannot find the fix that you refer to. Where exactly should this be? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25528. 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=25528 WebappClassloader does not register with RMI codebase cache --- Additional Comments From [EMAIL PROTECTED] 2003-12-16 09:37 --- Ah I see the fix now in Revision 1.28 of WebappClassLoader, just a week ago. It does not solve the superfluous number of calls to getURLs() though, just makes it faster. What should we do with our clients that use tomcat 4 and face this problem? Use our custom classloader patch? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems with catalina.properties
Hello, I have written a Listener and configured it in the server.xml with the Listener Tag. In conf/catalina.properties I extend the server.loader line with the path to the jar the Listener-Class contains. When I start Tomcat a ClassNotFoundException occurs. Only when i copy the jar into server/lib the classes will be successfully loaded. Is this a bug or will the server.loader values not used? Best regards Thorsten Kamann -- Thorsten Kamann Email: [EMAIL PROTECTED] ICQ: 40746578 Yahoo: ThorQue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25559] New: - threads after reloading application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25559. 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=25559 threads after reloading application Summary: threads after reloading application Product: Tomcat 4 Version: 4.1.27 Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] After reloading or stoping application all threads which started by this application still running. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Intro/question possible buglet with Content-Type and Charsets.
Hi All, Quick intro, and then a question; We use tomcat to host java web applications at our location. My client requires us to follow very strict rules for deploying software, that means it can be a documentation intensive process (evidence gathering/ IQP's etc ). So we rarely upgrade as it is quite allot of work. Luckily tomcat is excellent and rarely needs upgrading or patching. Now the question; Tomcat 4.1.29 seems to insist on added charset to the content type, even if a Content-Type has been set using response.setContentType or similar (without a charset). Tomcat 5 seems to do something similar judging from http://www.mail-archive.com/[EMAIL PROTECTED]/msg49015.html but I think it fails to check if the Content type is a text one (HTML) and adds it for any content type, which would appear not to be right IMHO. Without wishing to appear rude :-) I need to change this behaviour and remove the insertion of the charset for non text based Content-Types eg: application/vnd.ms-excel Hence could someone give me some pointers / crash course as to which class I need to patch to remove this? Thanks. Greg Cope GCS Ltd Assign to: CIT, Sandwich - ISG Phone: (44) 01304 642040 Fax: (44) 01304 652118 LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addresee(s) only. Access to this e-mail by anyone else is unauthorised. If you are not an addressee, any disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is unauthorised and may be unlawful. If you are not an addressee, please inform the sender immediately. Pfizer Limited is registered in England under No. 526209 with its registered office at Ramsgate Road, Sandwich, Kent CT13 9NJ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intro/question possible buglet with Content-Type and Charsets.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24970 [EMAIL PROTECTED] wrote: Hi All, Quick intro, and then a question; We use tomcat to host java web applications at our location. My client requires us to follow very strict rules for deploying software, that means it can be a documentation intensive process (evidence gathering/ IQP's etc ). So we rarely upgrade as it is quite allot of work. Luckily tomcat is excellent and rarely needs upgrading or patching. Now the question; Tomcat 4.1.29 seems to insist on added charset to the content type, even if a Content-Type has been set using response.setContentType or similar (without a charset). Tomcat 5 seems to do something similar judging from http://www.mail-archive.com/[EMAIL PROTECTED]/msg49015.html but I think it fails to check if the Content type is a text one (HTML) and adds it for any content type, which would appear not to be right IMHO. Without wishing to appear rude :-) I need to change this behaviour and remove the insertion of the charset for non text based Content-Types eg: application/vnd.ms-excel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Next site update?
Hi, When will the next tomcat site update take place? Usually we just do one when we have a new build, right? I've added/combined/linked architecture documentation (part of the docs webapp) and would like our site to reflect that, if only so that I (we) can get feedback on how much more work I (we) have to do ;) Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Intro/question possible buglet with Content-Type and Charsets .
Thanks Tim, Having a little trouble getting anything from bugzilla, nagoya.apache.org seems to be having a little trouble! Looking in the archives for this id, I see that someone has a 4.1.29 patch and a complied class, but cannot see either email address or content via the archive. Ho hum Thanks for the pointer. Greg -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 16 December 2003 12:31 To: Tomcat Developers List Subject: Re: Intro/question possible buglet with Content-Type and Charsets. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24970 [EMAIL PROTECTED] wrote: Hi All, Quick intro, and then a question; We use tomcat to host java web applications at our location. My client requires us to follow very strict rules for deploying software, that means it can be a documentation intensive process (evidence gathering/ IQP's etc ). So we rarely upgrade as it is quite allot of work. Luckily tomcat is excellent and rarely needs upgrading or patching. Now the question; Tomcat 4.1.29 seems to insist on added charset to the content type, even if a Content-Type has been set using response.setContentType or similar (without a charset). Tomcat 5 seems to do something similar judging from http://www.mail-archive.com/[EMAIL PROTECTED]/msg4 9015.html but I think it fails to check if the Content type is a text one (HTML) and adds it for any content type, which would appear not to be right IMHO. Without wishing to appear rude :-) I need to change this behaviour and remove the insertion of the charset for non text based Content-Types eg: application/vnd.ms-excel - 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]
Re: 5.next + 4.1.x future
Remy Maucherat wrote: I'm interested in the following enhancements to 5.0.x in the future (= in january or later): - refactoring of the save to XML feature (that's been requested; I don't know if I'll use that to be able to use the admin webapp under JBoss, though); likely the default impl will remain the current one, but we'll be able to take out all that code from StandardServer :) IMO the current one is pretty bad. There is a beginning in commons-modeler, and IMO it is the right solution for the problem ( as it tracks changes to the config - instead of trying to generate a new file, and preserves comments and structure ). I don't know when things will slow down a bit at work - but in january I'll try my best to free some time. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.next + 4.1.x future
Remy Maucherat wrote: Jeanfrancois Arcand wrote: +1 I would also like to explore, as a separate module, a connector that uses NIO to see what kind of performance we can have. I have no intention of replacing the current connector, and probably I will waste my time trying to have the same performance as the current connector. But I would like to explore it anyway ( latter next year, after the security stuff ) My opinion is that NIO is going to be really useless. - HTTP processing time is insignificant (BTW, most of the current algorithm can be used in non blocking mode, I think) - You have to go in blocking mode for the whole Catalina pipeline (ok: fast) and for running the user application - It will make object reuse more complex (you'll have to have a pool holding all the HTTP processors, essentially) NIO may be good in mod_jk mode - not the select but the mmap. I agree that select can't help too much given the servlet IO model, it's the mmap ( and the char-byte conversion ) that are really valuable in our case. BTW - another intersting optimization is for JSP static content, which can be also mmapped to avoid sending it over ( and maybe even get it sent directly from the disk ). Costin So the benefit is for holding HTTP/1.1 persistent connections, given that: - It will make the connector code more complex ( :-( ) - Modern OSes (Linux 2.6, Solaris with Sun's VMs, any Linux with JRockit and its thread mapping similar to Solaris) will probably not really care about saving a few threads But, hey, if you have time, it's an interesting experiment (and I'll try to help out a bit if I have time) :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.next + 4.1.x future
Jan-Henrik Haukeland wrote:
Remy Maucherat [EMAIL PROTECTED] writes:
My opinion is that NIO is going to be really useless.
Eh, hello!? Oh, okay if it's not important that Tomcat scale and
perform well it may be useless. But, really, before NIO it was
hopeless to try and write a scalable and fast tcp server application
in Java. Tomcat's current connection handling with blocing all over
the place and thundering herd problem doesn't scale or work very
well under heavy load.
Don't forget that servlets ( which is the main job of tomcat ) use
blocking input/output streams.
NIO select ( which is what most people see first in NIO ) is not going
to help in this. Select is extremely powerfull - but it requires a
certain kind of event-based architecture which doesn't match the
blocking model of servlets ( which has the big benefit of making things
simple for users ).
Think about it - in any case you do need one thread for each active
request, for the servlet. Most of the time is spent in the service()
method - you can do select() as much as you want in http/jk processing,
but you must have the thread for service() ( which can't be avoided
since servlets are allowed to block the thread ).
Only thing you can save is the static servlet - but for that you are
better off using a real server or a cache.
It's sad people see select() first - and don't pay attention to
char-byte convertors in NIO ( a huge ammount of optimization - tomcat
already has something that emulates the same model, so we won't benefit
much ), and the mmapping feature - which is huge for IPC and java-native
communication.
Costin
- It will make object reuse more complex (you'll have to have a pool
holding all the HTTP processors, essentially)
You will have a pool holding incomming connection, and if there is an
i/o event on the connection such as data present you will hand the
connection over to a small pool of HTTP processors (5-10). Here's a
quasi example for the main server loop. (All sockets must be
non-blocking, including the serversocket, i.e. it must *not* block on
accept(). Every i/o operation must of course also be non-blocking).
This loop allows the server to handle many thousand concurrent
connections without using many threads.
for(;;) {
/* Poll the connection pool, including the server socket and
* return the number of sockets ready for processing */
numReady= Poll.poll();
if(Poll.hasConnection()) {
/* We have new connections on the server socket; accept
* every incomming connection and put them into the
* connection pool */
doAccept();
/* Continue checking for more incomming connection;
* new connections are more important than old */
continue;
}
if(numReady == 0) {
/* Close and remove connections that has timed out or
* are done */
Poll.checkTimeout();
/* Continue checking for more incomming connection */
continue;
}
/* Get and process only those connections that is
* ready. I.e. has data avilable. (More optimizing is to only
* hand over incomming connection that has read and buffered a
* complete HTTP request */
while((connection= Poll.next())) {
/* Push the connection into our HttpProcessor thread
* worker/queue for processing.
- Keep-alive connections are not closed but keept in
the connection pool and will be re-processed.
- Connections that are finished are closed by the
HttpProcessor and will be removed from the pool
in the test above */
if(! processorPush(connection)) {
/* If no more processor threads are available
* we process the request ourself. Alternatively
* increase the pool of processor threads */
processConnection(connection, NO_KEEPALIVE);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intro/question possible buglet with Content-Type and Charsets .
Yeah, nagoya.apache.org seems down. Hopefully it will be back soon. The bug has good detail of what and how to fix. -Tim [EMAIL PROTECTED] wrote: Thanks Tim, Having a little trouble getting anything from bugzilla, nagoya.apache.org seems to be having a little trouble! Looking in the archives for this id, I see that someone has a 4.1.29 patch and a complied class, but cannot see either email address or content via the archive. Ho hum Thanks for the pointer. Greg -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 16 December 2003 12:31 To: Tomcat Developers List Subject: Re: Intro/question possible buglet with Content-Type and Charsets. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24970 [EMAIL PROTECTED] wrote: Hi All, Quick intro, and then a question; We use tomcat to host java web applications at our location. My client requires us to follow very strict rules for deploying software, that means it can be a documentation intensive process (evidence gathering/ IQP's etc ). So we rarely upgrade as it is quite allot of work. Luckily tomcat is excellent and rarely needs upgrading or patching. Now the question; Tomcat 4.1.29 seems to insist on added charset to the content type, even if a Content-Type has been set using response.setContentType or similar (without a charset). Tomcat 5 seems to do something similar judging from http://www.mail-archive.com/[EMAIL PROTECTED]/msg4 9015.html but I think it fails to check if the Content type is a text one (HTML) and adds it for any content type, which would appear not to be right IMHO. Without wishing to appear rude :-) I need to change this behaviour and remove the insertion of the charset for non text based Content-Types eg: application/vnd.ms-excel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.next + 4.1.x future
Costin Manolache wrote: Jan-Henrik Haukeland wrote: Don't forget that servlets ( which is the main job of tomcat ) use blocking input/output streams. NIO select ( which is what most people see first in NIO ) is not going to help in this. Select is extremely powerfull - but it requires a certain kind of event-based architecture which doesn't match the blocking model of servlets ( which has the big benefit of making things simple for users ). Think about it - in any case you do need one thread for each active request, for the servlet. Most of the time is spent in the service() method - you can do select() as much as you want in http/jk processing, but you must have the thread for service() ( which can't be avoided since servlets are allowed to block the thread ). Only thing you can save is the static servlet - but for that you are better off using a real server or a cache. It's sad people see select() first - and don't pay attention to char-byte convertors in NIO ( a huge ammount of optimization - tomcat already has something that emulates the same model, so we won't benefit much ), and the mmapping feature - which is huge for IPC and java-native communication. Well, we're using the C2B from NIO already. The old stuff is just wrappers around them, AFAIK. Of course, it would be more efficient to bypass the wrappers completely :) For mem maps, I don't know. The direct buffers are rather annoying to manipulate, it seems. It's good that we have a very efficient HTTP stack already, and we don't have to rush this stuff :-D Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25528. 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=25528 WebappClassloader does not register with RMI codebase cache --- Additional Comments From [EMAIL PROTECTED] 2003-12-16 18:56 --- Porting the getURLs patch from TC 5 is very easy. I recommend you do that, and I also expect the patch will be ported to 4.1.x. BTW, making the amount of calls zero is not useful: the overhead will now be on the serialization. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25559] - threads after reloading application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25559. 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=25559 threads after reloading application [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-16 19:40 --- It is the responsibility of the webapp to stop any threads that it has started. Tomcat certainly can't be expected to handle threads that it knows nothing about. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java
jfarcand2003/12/16 11:46:24
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
Log:
Fix typo (cut and paste should not exist)
Revision ChangesPath
1.28 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- CoyoteRequest.java10 Dec 2003 22:26:28 - 1.27
+++ CoyoteRequest.java16 Dec 2003 19:46:23 - 1.28
@@ -1266,7 +1266,7 @@
if (localName == null) {
if (socket != null) {
InetAddress inet = socket.getLocalAddress();
-localAddr = inet.getHostName();
+localName = inet.getHostName();
} else {
coyoteRequest.action
(ActionCode.ACTION_REQ_LOCAL_NAME_ATTRIBUTE, coyoteRequest);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25547] - default errorpage is displayed instead of the one forwarded to
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25547. 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=25547 default errorpage is displayed instead of the one forwarded to [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2003-12-16 20:04 --- 1) Traces are showing that my error page is executed but not displayed. So the forward is not the only culprit. This forward is different in that the target page has %@ page isErrorPage=true % which is not usually the case. 2) Why is tomcat's default error page displayed with the exception caught by my servlet ? (It act as if my error page was forwarding to the default which it doesn't do) 3) Why is it working in Tomcat 4.1 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25547] - default errorpage is displayed instead of the one forwarded to
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25547. 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=25547 default errorpage is displayed instead of the one forwarded to --- Additional Comments From [EMAIL PROTECTED] 2003-12-16 20:10 --- Can you add a test case to reproduce the problem? If I can reproduce the problem with you example, then it with be easy to fix. Merci ;-) -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25547] - default errorpage is displayed instead of the one forwarded to
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25547. 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=25547 default errorpage is displayed instead of the one forwarded to --- Additional Comments From [EMAIL PROTECTED] 2003-12-16 22:47 --- Created an attachment (id=9604) Test Case(war file) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25547] - default errorpage is displayed instead of the one forwarded to
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25547. 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=25547 default errorpage is displayed instead of the one forwarded to --- Additional Comments From [EMAIL PROTECTED] 2003-12-16 22:48 --- Jean-Pierre, It looks like I owe you an apology. It appears that the presence of an attribute named javax.servlet.jsp.jspException, bound to the request object, results in the invocation of the error page machinery, even if the exception has been caught. Here's a small test case. To Run: Deploy it, go to http://localhost:8080/error_page_test and click on the ErrorPage link to throw a divide by 0 exception. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25013] - Symbolic link related troubles should be logged as such.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25013. 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=25013 Symbolic link related troubles should be logged as such. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-17 01:34 --- Having inspected the code, the tldScanTld method cannot know that the failure is due to a symbolic link issue. Setting DEBUG-level logging for the relevant class (org.apache.catalina.startup.TldConfig) would have shown a message in the log right before the error with the text Scanning TLD at resource path ' + resourcePath + '); (with resourcePath filled in as the symbolic link file), thereby giving the user more information. I'm marking the bug as INVALID because it's more of a debugging issue than a code error. If you feel different, please look at the code and suggest a patch before reopening the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24976] - -Dcatalina.base=... does not work, but export CATALINA_BASE=... does
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24976. 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=24976 -Dcatalina.base=... does not work, but export CATALINA_BASE=... does [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-12-17 02:15 --- Not only does this work for me personally, but it's used by default in all the scripts, so I'm fairly certain it works in general ;) More likely, you're setting it somewhere and then it gets set again in $CATALINA_HOME/bin/catalina.sh, overriding your setting. Try System.out.println(System.getProperty(catalina.base)) from one of your servlets inside a running tomcat to verify your setting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
yoavs 2003/12/16 18:42:26 Modified:webapps/docs changelog.xml Log: Started changelog for 5.0.17. Revision ChangesPath 1.31 +24 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- changelog.xml 30 Nov 2003 14:55:27 - 1.30 +++ changelog.xml 17 Dec 2003 02:42:26 - 1.31 @@ -13,6 +13,30 @@ body +section name=Tomcat 5.0.17 (probably remm, unless we decide to give him a break) + subsection name=Catalina +changelog + add +Added minimal-server.xml (yoavs) + /add +/changelog + /subsection + + subsection name=Jasper +changelog +/changelog + /subsection + + subsection name=Webapps +changelog + docs +Added architecture documentation (yoavs) + /docs +/changelog + /subsection + +/section + section name=Tomcat 5.0.16 (remm) subsection name=Catalina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/common doccontrib.xml
yoavs 2003/12/16 18:50:44 Modified:jk/xdocs/common doccontrib.xml Log: Tiny documentation patch fixes bugzilla 24482. Revision ChangesPath 1.2 +2 -2 jakarta-tomcat-connectors/jk/xdocs/common/doccontrib.xml Index: doccontrib.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/common/doccontrib.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- doccontrib.xml14 Mar 2003 00:12:11 - 1.1 +++ doccontrib.xml17 Dec 2003 02:50:44 - 1.2 @@ -210,7 +210,7 @@ to produce a unified diff of the index.xml file and call it patch.txt, you would cd into the directory containing the index.xml file and: screen -readC:\build\jakarta-tomcat-connectors\jk\xdocscvs diff -u index.xml +readC:\build\jakarta-tomcat-connectors\jk\xdocs\cvs diff -u index.xml patch.txt./read read /read /screen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24482] - DOC creating a patch example doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24482. 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=24482 DOC creating a patch example doesn't work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-17 02:51 --- Fixed as suggested for 5.0.17. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24943] - Tomcat 5.0.14 / Windows 2000 Service does not start
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24943. 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=24943 Tomcat 5.0.14 / Windows 2000 Service does not start --- Additional Comments From [EMAIL PROTECTED] 2003-12-17 03:19 --- Mine will start but then stops immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9936] - http tunnel could not work with mod_jk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9936. 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=9936 http tunnel could not work with mod_jk [EMAIL PROTECTED] changed: What|Removed |Added Component|Connector:HTTP/1.1 |Connector:Coyote HTTP/1.1 |(deprecated)| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
