(Tiny) help offer
Hi there, I just subscribed to tomcat-dev in order to discuss a nitpick issue I found in Tomcat 4.1.18. The intro page you get on starting Tomcat for the first time, that is the index page of the ROOT webapp, does not have a correct doctype and is therefore probably invalid HTML, though I must admit I haven't actually checked this yet with a validator. In addition, it uses layout tables, purely presentational elements and more things that (not only) I consider to be bad web design practice. I won't complain longer about this if (a) nobody else thinks this is in the least important, or (b) you let me fix this. ;-) I consider myself to have extensive knowledge in modern, standards-compliant HTML writing, and would like to put this knowledge to use. This way, I hope to get involved in the Tomcat project in a small way. If this goes well, I'd start checking the other example pages as well. What do you think? Ciao, Christoph -- --- Christoph Seibert [EMAIL PROTECTED] --- -- Farlon Dragon -==(UDIC)==-http://home.pages.de/~seibert/ -- - Who can possibly rule if no one- - who wants to can be allowed to? - D. Adams, HHGTTG - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs?
Bill Barker wrote: Schnitzer, Jeff [EMAIL PROTECTED] writes: The standard fix for this is to use a cryptographic pseudo-random number generator, such as Java's SecureRandom. SecureRandom automatically seeds itself from allegedly random system data. the probability that two sufficiently long random numbers (e.g. 16 bytes) will collide is vanishing. (E.g. with a 16-byte session ID, you'd have to generate 2^60 session IDs to have a reasonable chance of collision. Nice to have you back Eric :-) As far as I can tell, ManagerBase could really use your expertise on this. The current algorithm is really bad :-( Yes, it would be nice to have a new one for Tomcat 5. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15612] - Tomcat4.1.18's JK2 connector occurs SocketTimeoutException
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=15612. 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=15612 Tomcat4.1.18's JK2 connector occurs SocketTimeoutException --- Additional Comments From [EMAIL PROTECTED] 2002-12-30 10:21 --- We see this too using downloaded binary mod_jk2-2.0.43.dll on Windows XP, Apache 2.0.43, jakarta-tomcat-4.1.17-LE-jdk14, Sun JDK 1.4.1_01 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15612] - Tomcat4.1.18's JK2 connector occurs SocketTimeoutException
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=15612. 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=15612 Tomcat4.1.18's JK2 connector occurs SocketTimeoutException [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-30 10:25 --- Did you notice the JK 2 connector configuration changed in 4.1.16 ? If you use the config from 4.1.12, it's normal that this happens. Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ (notice the connectionTimeout value) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
glenn 2002/12/30 06:10:20 Modified:jk/native CHANGES.txt Log: Update changes Revision ChangesPath 1.7 +6 -2 jakarta-tomcat-connectors/jk/native/CHANGES.txt Index: CHANGES.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- CHANGES.txt 16 Dec 2002 14:50:50 - 1.6 +++ CHANGES.txt 30 Dec 2002 14:10:20 - 1.7 @@ -1,6 +1,10 @@ JAKARTA TOMCAT CONNECTORS (JK) CHANGELOG:-*-text-*- Last modified at [$Date$] +Changes with JK 1.2.3: +* Add JkAutoAlias to Apache 2.0 + [glenn] + Changes with JK 1.2.2: * tomcat_trend.pl updated script to support changed logging of aborted requests @@ -28,4 +32,4 @@ [hgomez] * Final patches to make JK iSeries compliant [hgomez] - \ No newline at end of file + -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk aphowto.xml
glenn 2002/12/30 06:16:54 Modified:jk/xdocs/jk aphowto.xml Log: Update version numbers for apache in docs Revision ChangesPath 1.18 +8 -8 jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml Index: aphowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- aphowto.xml 26 Nov 2002 16:12:03 - 1.17 +++ aphowto.xml 30 Dec 2002 14:16:54 - 1.18 @@ -875,16 +875,16 @@ subsection name=Installation in Apache-2.0 screen -note /home/apache20/httpd-2.0.40 is the directory where the httpd-2.0 sources +note /home/apache20/httpd-2.0.43 is the directory where the httpd-2.0 sources are located. /note -type./configure --with-apache=/home/apache20/httpd-2.0.40/typebr/ +type./configure --with-apache=/home/apache20/httpd-2.0.43/typebr/ typemake/typebr/ noteInstall the mod_jk library and other files in -/home/apache20/httpd-2.0.40/modules: /note +/home/apache20/httpd-2.0.43/modules: /note typemake install/typebr/ note It is not possible to configure Apache directly because the config.m4 of mod_jk must be added to the configure of httpd-2.0. /note -typecd /home/apache20/httpd-2.0.40/type +typecd /home/apache20/httpd-2.0.43/type typesh buildconf/type typeconfigure ... --with-mod_jk/type typemake/type @@ -898,15 +898,15 @@ subsection name=Installation in Apache-1.3 screen -note /home/apache/apache_1.3.26 is the directory where the apache-1.3 sources +note /home/apache/apache_1.3.27 is the directory where the apache-1.3 sources are located. /note -type./configure --with-apache=/home/apache/apache_1.3.26/typebr/ +type./configure --with-apache=/home/apache/apache_1.3.27/typebr/ typemake/typebr/ noteInstall the libjk library, mod_jk.c, includes and other files in -/home/apache/apache_1.3.26/src/modules/jk: /note +/home/apache/apache_1.3.27/src/modules/jk: /note typemake install/typebr/ note Configure in the Apache sources: /note -typecd /home/apache/apache_1.3.26/type +typecd /home/apache/apache_1.3.27/type typeconfigure ... --enable-module=dir --disable-shared=dir \/type typenext --activate-module=src/modules/jk/libjk.a \/typenext typenext --disable-shared=jk/typenext -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Questions related to a port of the IIS-connector to Domino I plan toprovide
Mladen Turk [EMAIL PROTECTED] wrote on 30.12.2002 08:02:13: Good, so if there is DSAPI, there shuld't be problems :). I think so and I am making progress, but hope someone can help me further with questions 2 and 3 :) For the moment I work with 5.0 for the following reasons. Many organizations I work with have and will have Domino 5 servers around for quite some time and because I do have a problem with the old jk1 connector with Domino 6. It produces the following two errors during execution of the JNI_CreateJavaVM call in jk_jni_worker.c - 'Entry point for procedure _JVM_GetCPMethodNameUTF@12 in DLL jvm.dll could not be found' and afterwards 'Entry point for procedure _JVM_SupportsCX8@0 in DLL jvm.dll could not be found'. I am not sure what causes the errors but I think it Domino 6 because with Domino 5 there are no problems at all. Any suggestions? Looks to me like that you are using the wrong JVM. The strange thing is, that this only happens when using Domino 6 and not when using Domino 5 with the same JVM path and DSAPI filter. I extracted the relevant code from 'jk_jni_worker.c' and found the mentioned JNI_CreateJavaVM call to be the problem. I tried it with JDK/JRE 1.3.1_06 and JDK/JRE 1.4.1_01 and got the same results :( Can there be any class-path or system-path related issues, which might be handled different from Domino 5 to 6? Any other ideas or hints? MT. Olaf -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs?
I can also report that I've seen this happen when the system is under load. We had a user log in and gain access to another user's session. I'm sure you can understand that makes it a very serious bug for security-sensitive applications, perhaps even deserving some kind of security alert announcement. Tim's patch is robust and seems like a good candidate for inclusion in the source at the earliest opportunity since it ensures that no duplicate session id's will be commisioned (and ManagerBase already uses SecureRandom). Eric Rescorla wrote: The standard fix for this is to use a cryptographic pseudo-random number generator, such as Java's SecureRandom. SecureRandom automatically seeds itself from allegedly random system data. the probability that two sufficiently long random numbers (e.g. 16 bytes) will collide is vanishing. (E.g. with a 16-byte session ID, you'd have to generate 2^60 session IDs to have a reasonable chance of collision. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14008] - Error in taglib iterator
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=14008. 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=14008 Error in taglib iterator --- Additional Comments From [EMAIL PROTECTED] 2002-12-30 14:57 --- Created an attachment (id=4296) Test Case for Iteration Tag with NESTED Variable Info -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14008] - Error in taglib iterator (with NESTED variable info)
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=14008. 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=14008 Error in taglib iterator (with NESTED variable info) [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Critical Summary|Error in taglib iterator|Error in taglib iterator ||(with NESTED variable info) --- Additional Comments From [EMAIL PROTECTED] 2002-12-30 15:00 --- See tc attached (it is war-file). Running under the tomcat 4.0 it produces correct output, but under tomcat 4.1.x 1st element is null. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs?
Glenn Olander wrote: I can also report that I've seen this happen when the system is under load. We had a user log in and gain access to another user's session. I'm sure you can understand that makes it a very serious bug for security-sensitive applications, perhaps even deserving some kind of security alert announcement. Tim's patch is robust and seems like a good candidate for inclusion in the source at the earliest opportunity since it ensures that no duplicate session id's will be commisioned (and ManagerBase already uses SecureRandom). Bill enabled the (ugly but very safe) code for getting rid of duplicates. That will be in 4.1.x, at least for now. Experimentation on new and cleaner algorithms should happen in the 5.0.x branch first (and then it may be ported, although I'd say it shouldn't as the current code gets the job done relatively well and is tested). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
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=10383. 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=10383 Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2002-12-30 15:23 --- Thanks for the excellent bug report and the patch. I have verified that the bug exists. I am looking into the best way to handle exceptions when processing a request with Ajp. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java
glenn 2002/12/30 08:00:32
Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java
Log:
Fix bug 10383 and remove stack trace from client abort type of exception
Revision ChangesPath
1.10 +24 -7
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java
Index: Ajp13Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Ajp13Processor.java 7 Jun 2002 18:54:21 - 1.9
+++ Ajp13Processor.java 30 Dec 2002 16:00:32 - 1.10
@@ -441,9 +441,15 @@
try {
// set flag
handlingRequest.set(true);
-
+
+boolean bad_request = false;
+
// set up request
-request.setAjpRequest(ajpRequest);
+try {
+request.setAjpRequest(ajpRequest);
+} catch (IllegalArgumentException e) {
+bad_request = true;
+}
request.setResponse(response);
request.setStream(input);
@@ -455,7 +461,11 @@
logger.log(invoking...);
}
-connector.getContainer().invoke(request, response);
+if (!bad_request) {
+connector.getContainer().invoke(request, response);
+} else {
+response.sendError(400);
+}
if (debug 0) {
logger.log(done invoking, finishing request/response);
@@ -468,6 +478,13 @@
logger.log(finished handling request.);
}
+} catch (IOException ioe) {
+// Normally this catches a socket Broken Pipe caused by the
+// remote client aborting the request. mod_jk will close the
+// socket on its side and the processor will get a socket EOF
+// when it next tries to read from mod_jk, then recycle itself
+// normally. Don't print the stack trace in this case.
+logger.log(process: IOException + ioe.getMessage());
} catch (Throwable e) {
logger.log(process: invoke, e);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
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=10383. 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=10383 Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-30 16:02 --- I have just committed a patch that will return an HTTP status code of 400 - Bad Request when this happens. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
glenn 2002/12/30 08:06:09 Modified:.RELEASE-NOTES-4.1.txt Log: Update release notes Revision ChangesPath 1.42 +5 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- RELEASE-NOTES-4.1.txt 28 Dec 2002 02:20:43 - 1.41 +++ RELEASE-NOTES-4.1.txt 30 Dec 2002 16:06:09 - 1.42 @@ -718,6 +718,10 @@ JK 2 CoyoteHandler: Fix NPE occurring in SSL mode. +[4.1.19] #10383 + Ajp13 + Fix hanging Ajp13Processor and web server request when invalid Cookie sent. + An HTTP status code 400 - Bad Request is now returned. Jasper Bug Fixes: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs?
fyi, the version he checked in contains a bug. It should append jvmRoute
within
the loop. It should look like this:
String sessionId = generateSessionId();
String jvmRoute = getJvmRoute();
// @todo Move appending of jvmRoute generateSessionId()???
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
}
synchronized (sessions) {
while (sessions.get(sessionId) != null){// Guarantee
uniqueness
sessionId = generateSessionId();
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
}
}
}
session.setId(sessionId);
return (session);
Remy Maucherat wrote:
Glenn Olander wrote:
I can also report that I've seen this happen when the system is
under load. We had a
user log in and gain access to another user's session. I'm sure
you can understand that
makes it a very serious bug for security-sensitive applications,
perhaps even deserving
some kind of security alert announcement.
Tim's patch is robust and seems like a good candidate for
inclusion in the source
at the earliest opportunity since it ensures that no duplicate
session id's will be
commisioned (and ManagerBase already uses SecureRandom).
Bill enabled the (ugly but very safe) code for getting rid of
duplicates. That will be in 4.1.x, at least for now.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs?
This looks true by the looks of:
http://cvs.apache.org/viewcvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java?rev=1.15content-type=text/vnd.viewcvs-markup
The while loop is looking for one session ID, and if JVM route is set, a
different session ID is saved. (Since jvmRoute is attached AFTER dup check)
What is missing is the addition of jvmRoute to generateSessionId()
Attached is a patch against the HEAD of ManagerBase.java.
My original patch also provided a debug message and diff against
LocalStrings.properties to log that a dup sessionId was created. I would
be curious if that piece of code would ever be run. Personally - I doubt
it. But we'd have proof that a duplicate sessionID was created with the
debug message. If your want that patch instead - I can provide that on
demand.
-Tim
Glenn Olander wrote:
fyi, the version he checked in contains a bug. It should append jvmRoute
within
the loop. It should look like this:
String sessionId = generateSessionId();
String jvmRoute = getJvmRoute();
// @todo Move appending of jvmRoute generateSessionId()???
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
}
synchronized (sessions) {
while (sessions.get(sessionId) != null){// Guarantee
uniqueness
sessionId = generateSessionId();
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
}
}
}
session.setId(sessionId);
return (session);
Index: ManagerBase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
retrieving revision 1.15
diff -r1.15 ManagerBase.java
138,139c138,139
---
293,294c293,294
---
588,593d587
String jvmRoute = getJvmRoute();
// @todo Move appending of jvmRoute generateSessionId()???
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
session.setId(sessionId);
}
693a688,693
String jvmRoute = getJvmRoute();
if (jvmRoute != null) {
result.append('.').append(jvmRoute);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs?
Bill Barker [EMAIL PROTECTED] writes: As far as I can tell, ManagerBase could really use your expertise on this. The current algorithm is really bad :-( Ok. I've read the current code, which, as you say, is rather complicated. As far as I can tell, here's how it works: INITIALIZATION (1) Generate an entropy value E which is the ManagerBase instance toString()ed. (2) Get the current time T using system.getCurrentTimeMillis() (3) Mix E and T using XOR, wrapping E appropriately if it's longer T. [0]. Call the output S (4) Generate a new SecureRandom() and seed it using setSeed(S) If this fails, a new Random() is generated and seeded using setSeed(S). [1] SESSION ID GENERATION (1) Fill a 16-byte buffer with Random data from the random generator. (2) Digest the buffer (likely with MD5). (3) Hexify the value [2] SESSION CREATION (1) Generate a session ID. (2) If it already exists, go to (1). So, what's wrong with this code: (1) It's over-complicated. There's no need to hash the output of SecureRandom()--especially when you look at SecureRandom and see that it's hashes on the inside. :) (2) The entropy source isn't very good. There are really two sources of entropy, the initial time value and the toString() value of ManagerBase. The time value can generally be determined to within a few minutes. So, if we say 10 minutes, then there is 16 bits of entropy there. I haven't tested it, but the toString() value is probably an object handle of some kind. On FreeBSD with JDK 1.3, it looks to be the class name followed by a 32-bit ID. Since the class name is known, there are only 32 bits of entropy at best (assuming that the IDs aren't predictable). So, at best there are 48 bits of entropy. Not heartwarming. An attacker can presumably exhaustively search the entire RNG seed space with an effort of 2^48 ops. That said, this algorithm shouldn't repeat. No matter how crappy the seed is, cryptographically secure PRNGs (which SecureRandom supposedly is) generate white output. If you're seeing repeats with this algorithm, then something is very wrong. One possibility is that you're actually falling back to Random, which, as I mentioned above, the code allows for. It's possible you'd see more collisions with such a PRNG, though they should still be pretty rare. -Ekr [0] Note that I haven't verified this algorithm. [1] I don't know how often this happens. [2] I haven't verified this code either. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Questions related to a port of the IIS-connector to Domino I plan to provide
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 3:15 PM To: Tomcat Developers List Subject: RE: Questions related to a port of the IIS-connector to Domino I plan to provide Good, so if there is DSAPI, there shuld't be problems :). I think so and I am making progress, but hope someone can help me further with questions 2 and 3 :) I'll try to be as much help as I could. I'm interested in JK2/Domino implementation too. Looks to me like that you are using the wrong JVM. The strange thing is, that this only happens when using Domino 6 and not when using Domino 5 with the same JVM path and DSAPI filter. I extracted the relevant code from 'jk_jni_worker.c' and found the mentioned JNI_CreateJavaVM call to be the problem. I tried it with JDK/JRE 1.3.1_06 and JDK/JRE 1.4.1_01 and got the same results :( Can there be any class-path or system-path related issues, which might be handled different from Domino 5 to 6? Any other ideas or hints? Seems that Domino 6 is using its own JVM (think that the one (IBM 1.3.1) comes with installation) and you have collision problem cause you are loading another JVM in the process. There could be a problem with that if Domino already loads JVM, cause you can load JVM only once per process. We'll need to change some calls to JNI to attach to already created JVM. I'll try to do that (for JK2). Do you have some tools (like Process Explorer from SysInternals?) so you can tell if the JVM is already loaded and what is the version. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
apache http server
Can anyone tell me, Tomcat works both HTTP and APP server? do i need to download apache HTTPserver seperately inorder to make Tomcat work as both APP and HTTP server? Thanks, ravi = Thanks, RAVI KUMAR APPALA __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: ThreadPool
Craig R. McClanahan wrote: I don't see a problem with that, but I've stopped using reloadable at all for my development -- reload-on-demand (via the manager webapp) is a much more effective strategy IMHO. And reloadable shouldn't be used on a production server anyway. Is there a way to do that from the admin app as well? If there is I haven't found it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs?
Good catch!
I'll apply the patch (if somebody doesn't beat me to it).
- Original Message -
From: Glenn Olander [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, December 30, 2002 8:05 AM
Subject: Re: Duplicate session IDs?
fyi, the version he checked in contains a bug. It should append jvmRoute
within
the loop. It should look like this:
String sessionId = generateSessionId();
String jvmRoute = getJvmRoute();
// @todo Move appending of jvmRoute generateSessionId()???
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
}
synchronized (sessions) {
while (sessions.get(sessionId) != null){// Guarantee
uniqueness
sessionId = generateSessionId();
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
}
}
}
session.setId(sessionId);
return (session);
Remy Maucherat wrote:
Glenn Olander wrote:
I can also report that I've seen this happen when the system is
under load. We had a
user log in and gain access to another user's session. I'm sure
you can understand that
makes it a very serious bug for security-sensitive applications,
perhaps even deserving
some kind of security alert announcement.
Tim's patch is robust and seems like a good candidate for
inclusion in the source
at the earliest opportunity since it ensures that no duplicate
session id's will be
commisioned (and ManagerBase already uses SecureRandom).
Bill enabled the (ugly but very safe) code for getting rid of
duplicates. That will be in 4.1.x, at least for now.
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: ThreadPool
On Mon, 30 Dec 2002, Joseph Shraibman wrote: Date: Mon, 30 Dec 2002 14:00:57 -0500 From: Joseph Shraibman [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: [PATCH] Re: ThreadPool Craig R. McClanahan wrote: I don't see a problem with that, but I've stopped using reloadable at all for my development -- reload-on-demand (via the manager webapp) is a much more effective strategy IMHO. And reloadable shouldn't be used on a production server anyway. Is there a way to do that from the admin app as well? If there is I haven't found it. No, there's not, although in principle it would be possible to do this. I like using the custom Ant tasks included with Tomcat 4.1 for manipulation via manager, so that I can create a reload target. If you don't use Ant, it's just as easy to leave a browser window open to: http://localhost:8080/manager/reload?path=/myapp and just click Reload whenever you want. The first time you do this it'll ask you to log on (via BASIC authentication) -- after that, it's just a single click away. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Questions related to a port of the IIS-connector to Domino I plan to provide
Mladen Turk wrote: Seems that Domino 6 is using its own JVM (think that the one (IBM 1.3.1) comes with installation) and you have collision problem cause you are loading another JVM in the process. There could be a problem with that if Domino already loads JVM, cause you can load JVM only once per process. We'll need to change some calls to JNI to attach to already created JVM. I'll try to do that (for JK2). Even if Domino hasn't loaded the IBM VM, it may have settings that would load some of its jars. I was able to run jk using IBM JDK1.3 on linux - it should work on windows as well. Having 2 VMs is very likely to cause problems :-) ( sorry, I can't help too much - I'm not very familiar with IIS and windows :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: ThreadPool
Craig R. McClanahan wrote: It would actually be a pretty good solution IMO. A single thread checking the files for modification in all contexts is better ( again IMO ) than one thread per context. Same for checking sessions. The coding is a bit trickier ( and there are some issues related with DOS and security ), but it may be worth it. A single thread checking for modified files is probably ok (although it will slow down the effective reload rate for individual apps), but I'd be particularly careful about trying to combine the session timeout processing of multiple webapps into one thread. The problem is that application-level event handlers are called from this thread, and you really don't want an accidentally or maliciously coded webapp to start sleeping in one of these event handlers and thereby disable session timeout service for the entire Tomcat JVM. It's possible that some way to time out the timeout event hander :-) could deal with this, but it will require some care. I know - executing the even handlers can't be done on the expiration thread. The problem I'm trying to solve is scaling tomcat with the number of webapps. ( well, I'm not actually coding anything right now - there are more important issues :-) A hosting site with 100s of apps ( some very infrequently used !) would benefit a lot from having a single thread doing the checks for expiration. A thread pool can be used to process the event handlers - with some safeguards to prevent DOS ( event handlers hunging the expiration thread). It's not very difficult - let the thread pool grow to the max number of apps, and make sure a each context gets at most one thread for events. If all apps behave, you'll have few threads doing the expiration and one doing the check. Regarding the delay - yes, it may be faster to have 100 threads doing nothing but expiration ( or modification ) check, one per context. However it may be better to have 100 threads doing request processing and keep a single thread doing session maintainance. Java GC is done in a single thread too. Anyway - I don't think this is a very urgent problem to solve. As for someone stoping the check for class modification at run time using an admin interface - what's wrong with that ? I don't see a problem with that, but I've stopped using reloadable at all for my development -- reload-on-demand (via the manager webapp) is a much more effective strategy IMHO. And reloadable shouldn't be used on a production server anyway. I agree. Is 'reloadabl' disabled by default ? Should we deprecate it ? BTW - another way to do reload-on-demand is using JMX ( the html interface provided by either jmx-ri or mx4j - or any other jmx adaptor ). It may be a good idea to make the manager webapp more powerfull - i.e. support generic ( simple ) get/set operations via JMX. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: ThreadPool
On Mon, 30 Dec 2002, Costin Manolache wrote: As for someone stoping the check for class modification at run time using an admin interface - what's wrong with that ? I don't see a problem with that, but I've stopped using reloadable at all for my development -- reload-on-demand (via the manager webapp) is a much more effective strategy IMHO. And reloadable shouldn't be used on a production server anyway. I agree. Is 'reloadabl' disabled by default ? Yes ... at least in HEAD of 4.1 and 5.0. I'm pretty sure it's always been that way. Should we deprecate it ? Or perhaps (in 5.0) convert it to an installable module rather than a core feature? BTW - another way to do reload-on-demand is using JMX ( the html interface provided by either jmx-ri or mx4j - or any other jmx adaptor ). It may be a good idea to make the manager webapp more powerfull - i.e. support generic ( simple ) get/set operations via JMX. I agree. We could pretty easily provide JMX-based operations for everything that manager does (so that they're accessible from a JMX-based client), and have the manager webapp itself just be wrappers around those same MBean operations (for easy integration into non-JMX clients that can perform HTTP requests). Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: ThreadPool
Craig R. McClanahan wrote: I like using the custom Ant tasks included with Tomcat 4.1 for manipulation via manager, so that I can create a reload target. If you don't use Ant, it's just as easy to leave a browser window open to: I don't know if you looked at the JMX ant tasks in modeler. If we add some simple remote JMX feature in Manager - and implement the client side in the modeler ant tasks - it should be possible to control every aspect of tomcat from ant. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: ThreadPool
Craig R. McClanahan wrote: On Mon, 30 Dec 2002, Costin Manolache wrote: I agree. Is 'reloadabl' disabled by default ? Yes ... at least in HEAD of 4.1 and 5.0. I'm pretty sure it's always been that way. Yes, it's disabled by default. BTW, can't Linux 2.5/2.6 handle thousands of threads without any problem ? I remember reading an iterview of Ingo who said JVM performance and thread handling should be way better in 2.6. The idea is that there's nothing wrong with designing with threads in mind (I think that's good design), but the problem is that it doesn't quite work too well with most current OSes. BTW - another way to do reload-on-demand is using JMX ( the html interface provided by either jmx-ri or mx4j - or any other jmx adaptor ). It may be a good idea to make the manager webapp more powerfull - i.e. support generic ( simple ) get/set operations via JMX. I agree. We could pretty easily provide JMX-based operations for everything that manager does (so that they're accessible from a JMX-based client), and have the manager webapp itself just be wrappers around those same MBean operations (for easy integration into non-JMX clients that can perform HTTP requests). I added (theorical) support for MC4J in 5.0 some time ago, BTW. The only problem is that there's a version clash with MX4J (Tomcat has to use an API which changed between MX4J 1.1 and 1.1.1 to start the JRMP connector, and MC4J only works with MX4J 1.1 at the moment). After hacking to get it to work, in order to test the feature, I noticed the start/stop/reload operations weren't declared on the model MBeans. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: ThreadPool
Costin Manolache wrote: Craig R. McClanahan wrote: I like using the custom Ant tasks included with Tomcat 4.1 for manipulation via manager, so that I can create a reload target. If you don't use Ant, it's just as easy to leave a browser window open to: I don't know if you looked at the JMX ant tasks in modeler. If we add some simple remote JMX feature in Manager - and implement the client side in the modeler ant tasks - it should be possible to control every aspect of tomcat from ant. I think the client part should just use JRMP to talk to MX4J (or one of the others it provides). Ok, I'm being lazy here; I just don't feel like inventing our own custom protocol when one already exists ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: ThreadPool
On Mon, 30 Dec 2002, Costin Manolache wrote: Date: Mon, 30 Dec 2002 13:02:09 -0800 From: Costin Manolache [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [PATCH] Re: ThreadPool Craig R. McClanahan wrote: I like using the custom Ant tasks included with Tomcat 4.1 for manipulation via manager, so that I can create a reload target. If you don't use Ant, it's just as easy to leave a browser window open to: I don't know if you looked at the JMX ant tasks in modeler. I saw the commits, but not the code yet. It's on my list of stuff to look at. If we add some simple remote JMX feature in Manager - and implement the client side in the modeler ant tasks - it should be possible to control every aspect of tomcat from ant. Sounds like a reasonable way to do things. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: ThreadPool
BTW, can't Linux 2.5/2.6 handle thousands of threads without any problem ? I remember reading an iterview of Ingo who said JVM performance and thread handling should be way better in 2.6. You're right, and Java should be one to benefit well from it. But if the kernel period freeze lasts as long as the last one, we won't have 2.6.0 before 10 months, and give it another 4-5 months before it gets used in mainline distrib (last Debian uses 2.2 by default if I am correct :)) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: ThreadPool
Remy Maucherat wrote: BTW, can't Linux 2.5/2.6 handle thousands of threads without any problem ? I remember reading an iterview of Ingo who said JVM performance and thread handling should be way better in 2.6. The idea is that there's nothing wrong with designing with threads in mind (I think that's good design), but the problem is that it doesn't quite work too well with most current OSes. I'm pretty sure most OSes and apps will have problems with thousands of threads ( especially if a many are in RUN state ). They did a lot of changes in the linux scheduler - so hopefully thread handling improved too. I'm not very sure normal one request/thread will scale well for 1000s of concurent requests. That's an area where NIO would help ( select ). Squid ( and few other servers ) uses a single thread plus select plus some tricks to deal with extremely high load. I agree. We could pretty easily provide JMX-based operations for everything that manager does (so that they're accessible from a JMX-based client), and have the manager webapp itself just be wrappers around those same MBean operations (for easy integration into non-JMX clients that can perform HTTP requests). I added (theorical) support for MC4J in 5.0 some time ago, BTW. The only problem is that there's a version clash with MX4J (Tomcat has to use an API which changed between MX4J 1.1 and 1.1.1 to start the JRMP connector, and MC4J only works with MX4J 1.1 at the moment). After hacking to get it to work, in order to test the feature, I noticed the start/stop/reload operations weren't declared on the model MBeans. I added a reload for Context in the model mbean some time ago, and it seemed to work. For remote jmx - yes, MX4J RMI should work ( I was able to use it ), but it's very tricky. I think adding some simple operations in the ManagerServlet would be a good idea - just a get/set for a single attribute and a simple no-param method invocation would cover a lot of use cases. And we can easily implement an JMX-over-http on top of this. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
two system running at the sam time
Hello, Does anyone know how the two system running at the same time -- http://sameaddress:8080 and http://sameaddress:2999 using same tomcat-apache web server? ex: system1 using port 8080, system2 using port 2999, Am I right to modify the server.xml file? Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.http.HttpConnectionHandler/ Parameter name=port value=8080/ /Connector Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.http.HttpConnectionHandler/ Parameter name=port value=2999/ /Connector Thank you very much. Ping 12/30/02 __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session ManagerBase.java
billbarker2002/12/30 19:45:48
Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
Log:
Make certain that the jvmRoute is attached to the session before comparing for
uniqueness.
Submitted by: Glenn Olander [EMAIL PROTECTED]
Revision ChangesPath
1.16 +15 -9
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java
Index: ManagerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- ManagerBase.java 30 Dec 2002 02:36:26 - 1.15
+++ ManagerBase.java 31 Dec 2002 03:45:48 - 1.16
@@ -580,17 +580,23 @@
session.setMaxInactiveInterval(this.maxInactiveInterval);
String sessionId = generateSessionId();
-synchronized (sessions) {
-while (sessions.get(sessionId) != null)// Guarantee uniqueness
-sessionId = generateSessionId();
-}
-
String jvmRoute = getJvmRoute();
// @todo Move appending of jvmRoute generateSessionId()???
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
session.setId(sessionId);
}
+synchronized (sessions) {
+while (sessions.get(sessionId) != null){ // Guarantee uniqueness
+sessionId = generateSessionId();
+// @todo Move appending of jvmRoute generateSessionId()???
+if (jvmRoute != null) {
+sessionId += '.' + jvmRoute;
+session.setId(sessionId);
+}
+}
+}
+
session.setId(sessionId);
return (session);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java
billbarker2002/12/30 19:48:08
Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
Log:
Port patch from Tomcat 4.
Revision ChangesPath
1.9 +16 -9
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
Index: ManagerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- ManagerBase.java 30 Dec 2002 02:40:04 - 1.8
+++ ManagerBase.java 31 Dec 2002 03:48:08 - 1.9
@@ -633,16 +633,23 @@
session.setMaxInactiveInterval(this.maxInactiveInterval);
String sessionId = generateSessionId();
-synchronized (sessions) {
-while (sessions.get(sessionId) != null)// Guarantee uniqueness
-sessionId = generateSessionId();
-}
-
String jvmRoute = getJvmRoute();
// @todo Move appending of jvmRoute generateSessionId()???
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
+session.setId(sessionId);
}
+synchronized (sessions) {
+while (sessions.get(sessionId) != null){ // Guarantee uniqueness
+sessionId = generateSessionId();
+// @todo Move appending of jvmRoute generateSessionId()???
+if (jvmRoute != null) {
+sessionId += '.' + jvmRoute;
+session.setId(sessionId);
+}
+}
+}
+
session.setId(sessionId);
return (session);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationFilterConfig.java
glenn 2002/12/30 19:57:20
Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterConfig.java
Log:
Wrap ServletFilter init with swallow output
Revision ChangesPath
1.4 +20 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java
Index: ApplicationFilterConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ApplicationFilterConfig.java 16 Oct 2002 15:42:09 - 1.3
+++ ApplicationFilterConfig.java 31 Dec 2002 03:57:19 - 1.4
@@ -77,6 +77,8 @@
import org.apache.catalina.deploy.FilterDef;
import org.apache.catalina.util.Enumerator;
import org.apache.catalina.security.SecurityUtil;
+import org.apache.tomcat.util.log.SystemLogHandler;
+
/**
* Implementation of a codejavax.servlet.FilterConfig/code useful in
@@ -253,7 +255,20 @@
// Instantiate a new instance of this filter and return it
Class clazz = classLoader.loadClass(filterClass);
this.filter = (Filter) clazz.newInstance();
-filter.init(this);
+if (context instanceof StandardContext
+((StandardContext)context).getSwallowOutput()) {
+try {
+SystemLogHandler.startCapture();
+filter.init(this);
+} finally {
+String log = SystemLogHandler.stopCapture();
+if (log != null log.length() 0) {
+getServletContext().log(log);
+}
+}
+} else {
+filter.init(this);
+}
return (this.filter);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationFilterConfig.java
glenn 2002/12/30 19:57:34
Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterConfig.java
Log:
Wrap ServletFilter init with swallow output
Revision ChangesPath
1.8 +19 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java
Index: ApplicationFilterConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ApplicationFilterConfig.java 22 Jul 2001 20:25:08 - 1.7
+++ ApplicationFilterConfig.java 31 Dec 2002 03:57:34 - 1.8
@@ -76,7 +76,7 @@
import org.apache.catalina.Context;
import org.apache.catalina.deploy.FilterDef;
import org.apache.catalina.util.Enumerator;
-
+import org.apache.tomcat.util.log.SystemLogHandler;
/**
* Implementation of a codejavax.servlet.FilterConfig/code useful in
@@ -251,7 +251,20 @@
// Instantiate a new instance of this filter and return it
Class clazz = classLoader.loadClass(filterClass);
this.filter = (Filter) clazz.newInstance();
-filter.init(this);
+if (context instanceof StandardContext
+((StandardContext)context).getSwallowOutput()) {
+try {
+SystemLogHandler.startCapture();
+filter.init(this);
+} finally {
+String log = SystemLogHandler.stopCapture();
+if (log != null log.length() 0) {
+getServletContext().log(log);
+}
+}
+} else {
+filter.init(this);
+}
return (this.filter);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/tools/reports tomcat_trend.pl
glenn 2002/12/30 20:19:31
Modified:jk/tools/reports tomcat_trend.pl
Log:
Update for mod_jk log changes
Revision ChangesPath
1.3 +5 -4 jakarta-tomcat-connectors/jk/tools/reports/tomcat_trend.pl
Index: tomcat_trend.pl
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/tools/reports/tomcat_trend.pl,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- tomcat_trend.pl 16 Dec 2002 13:55:46 - 1.2
+++ tomcat_trend.pl 31 Dec 2002 04:19:31 - 1.3
@@ -127,6 +127,7 @@
foreach( @logs ) {
$logfile = $_;
chomp($logfile);
+ next if ( $logfile =~ /\.(bz2|gz|zip)$/ );
@head = `head -1 $logfile`;
($mon, $day, $time, $year) = (split /\s+/,$head[0])[1..4];
($hour, $min, $sec) = split /:/,$time;
@@ -228,7 +229,7 @@
if( $line =~ /\d\)\]: / ) {
# Handle a mod_jk error
# print mod_jk error! . scalar(localtime($logtime)) . $line\n;
-if( $line =~ /jk_tcp_socket_recvfull failed/ ) {
+if( $line =~ /(jk_tcp_socket_recvfull failed|ERROR: Receiving from
tomcat failed)/ ) {
$Global{tomcat_full}++;
$Interval{tomcat_full}++;
} elsif( $line =~ /(ajp_process_callback - write failed|ERROR sending
data to client. Connection aborted or network problems)/ ) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
