DO NOT REPLY [Bug 22701] - commons-logging and SSL in tomcat with struts
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=22701. 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=22701 commons-logging and SSL in tomcat with struts --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 06:13 --- It seems to me that having a static Log should be enough to stop this bug. However, I can't really reproduce it, and you committed your put commons- logging.jar in the System loader long after I committed the patch. If that's the only way to fix it, then I guess that's the way to go (but I don't have to like it :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Schedule change
Remy Maucherat wrote: Reshat Sabiq wrote: I'm a newbie on this list, but i think 2.4/2.0 draft 3 5.0.14 is a good idea. At least it's more specific than Beta. P.S. Btw, as far as bugs i couldn't use custom error pages in Sun's 1.4 Beta 2 (Tomcat 5). Reported to Sun, and they forwarded me to Apache, and i didn't have time. Could report that on BZ. It might of course all be my fault, but it works in 4.1, and 4.2. There are tests for that in both the tester and watchdog, so you'll have to submit a test WAR. (BTW, there's no 4.2) My bad. I meant 4.1.1, and 4.1.2 (i've used 4.1.8, 4.1.9, 4.1.12, and 4.1.24). How do i submit a test war to tester or watchdog (i only know Bugzilla). Thanks. -- Sincerely, Reshat. --- If you see my certificate with this message, you should be able to send me encrypted e-mail. Please consult your e-mail client for details if you would like to do that. smime.p7s Description: S/MIME Cryptographic Signature
cvs commit: jakarta-tomcat-connectors/procrun tomcat.c
mturk 2003/10/02 00:24:25
Modified:procrun tomcat.c
Log:
Improve the listview parsing and creation, and make sure that stderr
messages gets display as error.
Revision ChangesPath
1.3 +46 -25jakarta-tomcat-connectors/procrun/tomcat.c
Index: tomcat.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/procrun/tomcat.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- tomcat.c 1 Oct 2003 18:08:58 - 1.2
+++ tomcat.c 2 Oct 2003 07:24:25 - 1.3
@@ -91,23 +91,32 @@
#include jni.h
#include procrun.h
-
+
prcrun_lview_t tac_columns[] = {
-{ Status, 140 },
+{ Type, 60 },
+{ Date, 80 },
+{ Time, 60 },
{ Class,172 },
{ Message, 300 },
-{ NULL, 0 },
+{ NULL, 0 },
};
-static char *ac_lv_stat = NULL;
-static char ac_lv_clbuf[1024] = {0};
+static char ac_lv_buf[1024] = {0};
static char *ac_lv_class = NULL;
-static char *ac_lv_clmsg = NULL;
+static char *ac_lv_msg = NULL;
+static char *ac_lv_date = NULL;
+static char *ac_lv_time = NULL;
static int ac_lv_iicon = 0;
-
+
+static char *lv_infos[] = {
+Info,
+Warning,
+Error,
+Severe
+};
-void tc_parse_list_string(const char *str)
+void tc_parse_list_string(const char *str, int from)
{
int row = 0x7FFF;
LV_ITEM lvi;
@@ -116,12 +125,16 @@
if (isdigit(*str)) {
char *p;
-strncpy(ac_lv_clbuf, str, 1023);
-ac_lv_stat = p = ac_lv_clbuf[0];
+strncpy(ac_lv_buf, str, 1023);
+ac_lv_date = p = ac_lv_buf[0];
while (*p !isspace(*p))
++p;
-++p;
+*(p++) = 0;
+while (*p isspace(*p))
+++p;
+ac_lv_time = p;
+
while (*p !isspace(*p))
++p;
*(p++) = 0;
@@ -132,7 +145,7 @@
while (*p !isspace(*p))
++p;
*(p++) = 0;
-ac_lv_clmsg = p;
+ac_lv_msg = p;
}
else {
@@ -149,31 +162,38 @@
off = STRN_SIZE(ERROR:) + 1;
}
else if (STRN_COMPARE(str, SEVERE:)) {
-ac_lv_iicon = 2;
+ac_lv_iicon = 3;
off = STRN_SIZE(SEVERE:) + 1;
}
-ac_lv_clmsg = (char *)str + off;
+ac_lv_msg = (char *)str + off;
/* skip leading spaces */
-while (*ac_lv_clmsg isspace(*ac_lv_clmsg))
-++ac_lv_clmsg;
+while (*ac_lv_msg isspace(*ac_lv_msg))
+++ac_lv_msg;
}
+
+/* if this is from stderr set the error icon */
+if (from)
+ac_lv_iicon = 2;
STR_NOT_NULL(ac_lv_class);
-STR_NOT_NULL(ac_lv_clmsg);
-STR_NOT_NULL(ac_lv_stat);
+STR_NOT_NULL(ac_lv_msg);
+STR_NOT_NULL(ac_lv_date);
+STR_NOT_NULL(ac_lv_time);
memset(lvi, 0, sizeof(LV_ITEM));
lvi.mask= LVIF_IMAGE | LVIF_TEXT;
lvi.iItem = ac_lview_current;
lvi.iImage = ac_lv_iicon;
-lvi.pszText = ac_lv_stat;
-lvi.cchTextMax = strlen(ac_lv_stat) + 1;
+lvi.pszText = lv_infos[ac_lv_iicon];
+lvi.cchTextMax = 8;
row = ListView_InsertItem(ac_list_hwnd, lvi);
if (row == -1)
return;
-ListView_SetItemText(ac_list_hwnd, row, 1, ac_lv_class);
-ListView_SetItemText(ac_list_hwnd, row, 2, ac_lv_clmsg);
+ListView_SetItemText(ac_list_hwnd, row, 1, ac_lv_date);
+ListView_SetItemText(ac_list_hwnd, row, 2, ac_lv_time);
+ListView_SetItemText(ac_list_hwnd, row, 3, ac_lv_class);
+ListView_SetItemText(ac_list_hwnd, row, 4, ac_lv_msg);
ListView_EnsureVisible(ac_list_hwnd,
ListView_GetItemCount(ac_list_hwnd) - 1,
FALSE);
@@ -184,10 +204,11 @@
void acx_init_extended()
{
-ac_use_lview = 1;
-ac_splash_msg = INFO: Jk running;
-ac_columns = tac_columns[0];
+ac_splash_timeout = 2;
+ac_splash_msg = INFO: Jk running;
+ac_columns = tac_columns[0];
lv_parser = tc_parse_list_string;
+
}
#endif
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe
mturk 2003/10/02 00:25:23 Modified:procrun/bin tomcat.exe tomcatw.exe Log: Latest binaries (VC6/SP5). Revision ChangesPath 1.3 +14 -14jakarta-tomcat-connectors/procrun/bin/tomcat.exe Binary file 1.3 +37 -38jakarta-tomcat-connectors/procrun/bin/tomcatw.exe Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Schedule change
Reshat Sabiq wrote: My bad. I meant 4.1.1, and 4.1.2 (i've used 4.1.8, 4.1.9, 4.1.12, and 4.1.24). How do i submit a test war to tester or watchdog (i only know Bugzilla). No, if you have a test case, submit it in BZ. The tester and watchdog are the test suites we use. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22701] - commons-logging and SSL in tomcat with struts
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=22701. 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=22701 commons-logging and SSL in tomcat with struts --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 07:40 --- I remember more details about my fix. It is probably less needed for TC 4.1. In 5.0, the problem was that Jasper used commons-logging. In 4.1, this is not the case, but I don't know what cleaner fix is needed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat build.xml
[EMAIL PROTECTED] a écrit : larryi 2003/10/01 19:50:59 Modified:.build.xml Log: Update to build using MAIN branch of JTC coyote and http11. The jars are a little different from coyote_10 version. Thanks Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22701] - commons-logging and SSL in tomcat with struts
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=22701. 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=22701 commons-logging and SSL in tomcat with struts --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 08:25 --- JSSESupport.java in the CVS works well and this bug was solved in my environment. - Tomcat/4.1.27 - log4j/1.2.8 - WWW browser/IE6 In my environment, this bug can be reproduced by following steps. 1. Access to application by HTTPS (ex. https://localhost:8443/my-application/) Tomcat will work well. 2. Wait about 5 minutes. 3. Access to application by HTTPS again. (click browser's [reload] button several times) If JSSESupport.class is genuine 4.1.27, LogConfigurationException will be printed in console. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardHostValve.java
remm2003/10/02 01:29:50 Modified:catalina/src/share/org/apache/catalina/core StandardHostValve.java Log: - Reset the context CL after the end of the request processing. This could fix bug 22701 for TC 4.1. - Note: I'm not doing it in a finally, since uncaught exceptions here are a critical error. Revision ChangesPath 1.7 +7 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostValve.java Index: StandardHostValve.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostValve.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- StandardHostValve.java4 Jan 2002 16:33:40 - 1.6 +++ StandardHostValve.java2 Oct 2003 08:29:50 - 1.7 @@ -179,6 +179,9 @@ // Ask this Context to process this request context.invoke(request, response); +Thread.currentThread().setContextClassLoader +(StandardHostValve.class.getClassLoader()); + } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22701] - commons-logging and SSL in tomcat with struts
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=22701. 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=22701 commons-logging and SSL in tomcat with struts [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 08:33 --- There's another fix I added in 5.0: resetting the context classloader after finishing processing the request. This will likely fix it, and would explain the randomness. I'll mark the bug as fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[next] What's next ?
Usually, when a Tomcat branch nears its release, a new branch is created. However, I only have a few feature ideas that make some sense, and the problem is that they are minor evolutions (hence, they could perfectly fit inside the 5.0 branch). This includes: - Updating JK2 to use the JMX events (the same ones the mapper uses) to get autoconfiguration, as an option. That seems useful, but it might well be a really stupid thing in the real world. - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat. - Use an in memory Java compiler to be able to automatically precompile webapps upon deployment. I heard such a compiler now exists, and this could be added fairly easily if it works well enough. I'm not a very big fan, but maybe it would make sense for some people. So to summarize, I have nothing to propose (sorry), and will focus on bugfixes and small additions in the 5.0 branch. If people want to see something more radical happen for the next major release, it's probably time to come up with proposals :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC4.1: StandardWrapperValve infinite recursion
On Wed, 1 Oct 2003, Filip Hanik wrote: My pardon on behalf of the dev community for lagging behind. People forget, stuff gets dropped. Besides, I didn't have to wait long. So I'm happy. :) /Urban - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote problems on a EBCDIC machine
Remy Maucherat wrote: jean-frederic clere wrote: Hi, I have a funny problem with Coyote: The response body are Ok (in ASCII) but the headers are corrupted (probably in EBCDIC). May be somewhere I have to tell Coyote to do ASCII instead default encoding. Has someone a hint? The header writing is in http11.InternalOutputBuffer. Is something special needed ? Probably some getBytes(ISO-8859-1) instead of getBytes() Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23525] - HttpSessionListener implementors are called to late according to Servlet Specification 2.4 Final Draft 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=23525.
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=23525
HttpSessionListener implementors are called to late according to Servlet Specification
2.4 Final Draft 3
--- Additional Comments From [EMAIL PROTECTED] 2003-10-02 10:26 ---
I'm considering this patch (which I don't have time to test). Jean-Francois, can
you test if it actually works ?
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.22
diff -r1.22 StandardSession.java
578c578
if (!this.isValid || this.expiring) {
---
if (!this.isValid) {
579a580,582
}
if (this.expiring) {
return true;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
problems with ant download
Hi, I have noted the redirect to binindex.cgi disturbs the ant download: +++ testexist: [echo] Testing for /home/jakarta/jakarta-struts-1.1/lib/struts.jar downloadgz: [get] Getting: http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz [gunzip] Expanding /home/jakarta/file.tar.gz to /home/jakarta/file.tar BUILD FAILED file:/home/jakarta/jakarta-tomcat-4.1.27-src/build.xml:573: Problem expanding gzip Not in GZIP format +++ The problem is the redirect: +++ [EMAIL PROTECTED]:~/jakarta-tomcat-4.1.27-src wget http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz --12:13:21-- http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz = `jakarta-struts-1.0.2.tar.gz' Connecting to proxy.mch.fsc.net:81... connected! Proxy request sent, awaiting response... 301 Moved Permanently Location: http://jakarta.apache.org/site/binindex.cgi [following] --12:13:29-- http://jakarta.apache.org/site/binindex.cgi = `binindex.cgi' Connecting to proxy.mch.fsc.net:81... connected! Proxy request sent, awaiting response... 200 OK Length: unspecified [text/html] 0K - .. .. .. .. .. 50K - 12:13:31 (41.41 KB/s) - `binindex.cgi' saved [51607] +++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
The AccessLog Valves might be nice to simplify so a Logging element is a nested inside of the Valve declaration. This way the access log valve can just do 3 things: - determine if it should log (conditional logging) - format a string to be logged - Pass it along to a logging element which can then store the log entry somewhere This way the Accesslog valve code with respect to File rotation, handling, ... can be greatly simplified. for example: (some names are wrong but just an example) Valve className=org.apache.catalina.valves.AccessLogValve pattern=common resolveHosts=false Logger className=org.apache.catalina.logger.SimpleLogger directory=logs prefix=localhost_access_log. suffix=.txt / /Valve Valve className=org.apache.catalina.valves.AccessLogValve pattern=common resolveHosts=false Logger className=org.apache.catalina.logger.PipedLogger exec=logrotate.pl / /Valve Valve className=org.apache.catalina.valves.AccessLogValve pattern=common resolveHosts=false Logger className=org.apache.catalina.logger.FileDateFormatLogger directory=logs dateStamp=mm-DD- prefix=localhost_access_log. suffix=.txt / /Valve -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems with ant download
I suspect that you might be able to fix this: /x1/www/jakarta.apache.org/builds/jakarta-struts/.htaccess Hope this helps -- Tetsuya. ([EMAIL PROTECTED]) On Thu, 02 Oct 2003 12:49:03 +0200 (Subject: problems with ant download) jean-frederic clere [EMAIL PROTECTED] wrote: Hi, I have noted the redirect to binindex.cgi disturbs the ant download: +++ testexist: [echo] Testing for /home/jakarta/jakarta-struts-1.1/lib/struts.jar downloadgz: [get] Getting: http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz [gunzip] Expanding /home/jakarta/file.tar.gz to /home/jakarta/file.tar BUILD FAILED file:/home/jakarta/jakarta-tomcat-4.1.27-src/build.xml:573: Problem expanding gzip Not in GZIP format +++ The problem is the redirect: +++ [EMAIL PROTECTED]:~/jakarta-tomcat-4.1.27-src wget http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz --12:13:21-- http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz = `jakarta-struts-1.0.2.tar.gz' Connecting to proxy.mch.fsc.net:81... connected! Proxy request sent, awaiting response... 301 Moved Permanently Location: http://jakarta.apache.org/site/binindex.cgi [following] --12:13:29-- http://jakarta.apache.org/site/binindex.cgi = `binindex.cgi' Connecting to proxy.mch.fsc.net:81... connected! Proxy request sent, awaiting response... 200 OK Length: unspecified [text/html] 0K - .. .. .. .. .. 50K - 12:13:31 (41.41 KB/s) - `binindex.cgi' saved [51607] +++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19869] - BUILDING.txt is v4.0
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=19869. 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=19869 BUILDING.txt is v4.0 --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 11:20 --- This bug is still true for 4.1.27 source tar.gz. Have not checked if there is an updated file in the CVS tree. The URLs are out of sync with reality, not sure if it was when released. Here are the ones I found: http://jakarta.apache.org/builds/jakarta-ant/release/v1.5/bin (http://ant.apache.org/bindownload.cgi) http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/src (http://jakarta.apache.org/site/sourceindex.cgi) http://jakarta.apache.org/builds/jakarta-servletapi-4/nightly (http://cvs.apache.org/builds/jakarta-servletapi-4/nightly) http://jakarta.apache.org/builds/jakarta-commons/release/... (http://jakarta.apache.org/site/binindex.cgi) ant download is broken because of these changes. A related Bugid is 18999 (WONTFIX ???) commons-fileupload is still not mentioned in BUILDING.txt but is required. Surely that is not a WONTFIX. Also there are no instructions in BUILDING.txt on how to get jasper working. The build.properties.sample has a default value that does not work out-of-the-box. And there is no mention on where or how to download jakarta-tomcat-jasper. 18999 says that you should use the files in the included jasper directory. Either the documentation should say that you must change jasper.home to that value or (better) the .sample file should have a default that works. suggested change to build.properties.sample: -#jasper.home=../jakarta-tomcat-jasper/jasper2 +jasper.home=jasper /Urban - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18433] - autoDeploy=false 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=18433. 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=18433 autoDeploy=false doesn't work [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 11:31 --- I agree with Tomasz Nowak that the configuration parameters autoDeploy and liveDeploy are not intuitive. I agree that autoDeploy is needed but what use is of setting autoDeploy=false and liveDeploy=true. As this combination gives us nothing I think it would be logical if autoDeploy means that there is any automatic deployment done and the liveDeploy parameter controlls if you want monitoring and multiple deployment. If nothing else then this point should be brought out in the documentation with an asterix or something. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22328] - javax.management.ReflectionException: Cannot find method getClassName with this signature
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=22328. 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=22328 javax.management.ReflectionException: Cannot find method getClassName with this signature --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 12:25 --- Created an attachment (id=8428) beans xml config - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23564] New: - Tomcat 4.1.24: Dynamic loading classes in Tomcat causes java.lang.UnsatisfiedLinkError
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=23564. 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=23564 Tomcat 4.1.24: Dynamic loading classes in Tomcat causes java.lang.UnsatisfiedLinkError Summary: Tomcat 4.1.24: Dynamic loading classes in Tomcat causes java.lang.UnsatisfiedLinkError Product: Tomcat 4 Version: 4.0 Beta 1 Platform: PC OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I use JNI to load up my library(load up statically). Everything will run well if I don't compile any classes when tomcat 4.1.24 is running. I can fetch data etc using JNI. The moment I compile a new class and it gets loaded(you can see it in the Tomcat window), any screens that uses JNI will complain:- java.lang.UnsatisfiedLinkError. Somehow when a class is recompiled, Tomcat resets something but does not unload the DLL. However, it tries to load up the DLL again after a class is loaded. I am as ascertained of this behavior. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23565] New: - Reload in the manager app does not 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=23565. 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=23565 Reload in the manager app does not work Summary: Reload in the manager app does not work Product: Tomcat 4 Version: 4.1.27 Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The reload command of the manager ends in an ClassNotFoundException and the servlet is marked as unavailable. This was tested under AIX, Suse, WinNT. It does not matter if you run the reload URL from manager/html or use /reload? path=. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22328] - javax.management.ReflectionException: Cannot find method getClassName with this signature
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=22328. 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=22328 javax.management.ReflectionException: Cannot find method getClassName with this signature [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 12:40 --- The beans xml config file attachment (id=8428) does not resolve this problem when added to the descriptors attribute of the ServerLifecycleListener tag. attachment contents -- ?xml version=1.0? !DOCTYPE mbeans-descriptors PUBLIC -//Apache Software Foundation//DTD Model MBeans Configuration File http://jakarta.apache.org/commons/dtds/mbeans-descriptors.dtd;; !-- Descriptions of JMX MBeans for Catalina -- mbeans-descriptors mbean name=AccessLogValve className=org.apache.catalina.mbeans.ClassNameMBean description=Valve that generates a web server access log domain=Catalina group=Valve type=org.apache.catalina.valves.AccessLogValve /mbeans-descriptors - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems with ant download
Tetsuya Kitahata wrote: I suspect that you might be able to fix this: /x1/www/jakarta.apache.org/builds/jakarta-struts/.htaccess Hope this helps Yes, but not... http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz must be changed into: http://www.apache.org/dyn/closer.cgi/jakarta/struts/binaries/jakarta-struts-1.1.tar.gz The change from 1.0.2 to 1.1 is impossible but the interesting would be to have cgi that redirects to the result of closer.cgi instead displaying it. BTW: Where could I get jakarta-struts-1.0.2.tar.gz? Cheers Jean-Frederic -- Tetsuya. ([EMAIL PROTECTED]) On Thu, 02 Oct 2003 12:49:03 +0200 (Subject: problems with ant download) jean-frederic clere [EMAIL PROTECTED] wrote: Hi, I have noted the redirect to binindex.cgi disturbs the ant download: +++ testexist: [echo] Testing for /home/jakarta/jakarta-struts-1.1/lib/struts.jar downloadgz: [get] Getting: http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz [gunzip] Expanding /home/jakarta/file.tar.gz to /home/jakarta/file.tar BUILD FAILED file:/home/jakarta/jakarta-tomcat-4.1.27-src/build.xml:573: Problem expanding gzip Not in GZIP format +++ The problem is the redirect: +++ [EMAIL PROTECTED]:~/jakarta-tomcat-4.1.27-src wget http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz --12:13:21-- http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz = `jakarta-struts-1.0.2.tar.gz' Connecting to proxy.mch.fsc.net:81... connected! Proxy request sent, awaiting response... 301 Moved Permanently Location: http://jakarta.apache.org/site/binindex.cgi [following] --12:13:29-- http://jakarta.apache.org/site/binindex.cgi = `binindex.cgi' Connecting to proxy.mch.fsc.net:81... connected! Proxy request sent, awaiting response... 200 OK Length: unspecified [text/html] 0K - .. .. .. .. .. 50K - 12:13:31 (41.41 KB/s) - `binindex.cgi' saved [51607] +++ - 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: problems with ant download
On Thu, 02 Oct 2003 14:55:22 +0200 (Subject: Re: problems with ant download) jean-frederic clere [EMAIL PROTECTED] wrote: Tetsuya Kitahata wrote: I suspect that you might be able to fix this: /x1/www/jakarta.apache.org/builds/jakarta-struts/.htaccess Hope this helps Yes, but not... http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz must be changed into: http://www.apache.org/dyn/closer.cgi/jakarta/struts/binaries/jakarta-struts-1.1.tar.gz The change from 1.0.2 to 1.1 is impossible but the interesting would be to have cgi that redirects to the result of closer.cgi instead displaying it. Okeydokey. BTW: Where could I get jakarta-struts-1.0.2.tar.gz? Try to use: http://archive.apache.org/dist/jakarta/struts/ (http://archive.apache.org/dist/jakarta/struts/old/release/v1.0.2/) Cheers, -- Tetsuya. ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23146] - Calling socket.setTcpNoDelay causes connector to disconnect
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=23146. 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=23146 Calling socket.setTcpNoDelay causes connector to disconnect [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 13:54 --- We have encountered this bug on a Tru64 platform, so it is probably not an OS related problem. We are using Tomcat version 4.1.24. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [next] What's next ?
Howdy, On the subject of AccessLogValve: I hadn't thought of the things Tim suggested, but I have a different suggestion, part of a more general suggestion: 1. Convert AccessLogValve to be a servlet specification 2.3 filter, i.e. something portable. We can define it in $CATALINA_HOME/conf/web.xml, commented out by default perhaps, and users can move the definition around as they need just like they do with the servlets defined conf/web.xml. Furthermore, people can then extend/customize AccessLogFilter much more easily, without needing to touch any tomcat classes. And finally, this will allow the full power of filter-mapping to be applied to access logging. (I imagine the default in conf/web.xml would be the /* url-pattern mapping, but I know I and other users have different use cases). If you think this is useful, I'd like to start working on it myself ;) If you think it's not useful/bad/stupid, please let me know ;) 2. As an extension of the above idea, I would propose converting more of the tomcat non-standard features into portable implementations. This includes the other filters, e.g. RemoteAddressFilter, RemoteHostFilter, RequestDumperValve, and others you think are appropriate. Then I have other ideas, of varying degrees of radicality and I'm sure stupidity ;) I'm proposing them for discussion, as I think they're all interesting. 1. Logging: use commons-logging throughout. Eliminate tomcat logger implementation classes (FileLogger, SystemErrLogger, SystemOutLogger). Eliminate catalina.out file, instead having swallowOutput=true always without option to change. Default logging configuration should still rotate nightly. 2. Eliminate the shared and common classloader repositories. Unless these are required by the spec? Force webapps to be self-contained by putting all their classes in WEB-INF/lib or WEB-INF/classes of their webapp. Have the WEB-INF/clases - WEB-INF/lib - endorsed - system classloader hierarchy, much simpler than current. 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. 4. Have no default objects created at runtime. That means no default session manager if one is not configured, no default context if one is not configured, etc. Ship tomcat with an example server.xml containing all the default settings, and nothing more. Of course, I'm willing to help on all of the above if we decide to do any of them. That should be enough to get some talk going ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 6:55 AM To: Tomcat Developers List Subject: Re: [next] What's next ? The AccessLog Valves might be nice to simplify so a Logging element is a nested inside of the Valve declaration. This way the access log valve can just do 3 things: - determine if it should log (conditional logging) - format a string to be logged - Pass it along to a logging element which can then store the log entry somewhere This way the Accesslog valve code with respect to File rotation, handling, ... can be greatly simplified. for example: (some names are wrong but just an example) Valve className=org.apache.catalina.valves.AccessLogValve pattern=common resolveHosts=false Logger className=org.apache.catalina.logger.SimpleLogger directory=logs prefix=localhost_access_log. suffix=.txt / /Valve Valve className=org.apache.catalina.valves.AccessLogValve pattern=common resolveHosts=false Logger className=org.apache.catalina.logger.PipedLogger exec=logrotate.pl / /Valve Valve className=org.apache.catalina.valves.AccessLogValve pattern=common resolveHosts=false Logger className=org.apache.catalina.logger.FileDateFormatLogger directory=logs dateStamp=mm-DD- prefix=localhost_access_log. suffix=.txt / /Valve -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: problems with ant download
Tetsuya Kitahata wrote: On Thu, 02 Oct 2003 14:55:22 +0200 (Subject: Re: problems with ant download) jean-frederic clere [EMAIL PROTECTED] wrote: Tetsuya Kitahata wrote: I suspect that you might be able to fix this: /x1/www/jakarta.apache.org/builds/jakarta-struts/.htaccess Hope this helps Yes, but not... http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz must be changed into: http://www.apache.org/dyn/closer.cgi/jakarta/struts/binaries/jakarta-struts-1.1.tar.gz The change from 1.0.2 to 1.1 is impossible but the interesting would be to have cgi that redirects to the result of closer.cgi instead displaying it. Okeydokey. Should we ask infrastructure? BTW: Where could I get jakarta-struts-1.0.2.tar.gz? Try to use: http://archive.apache.org/dist/jakarta/struts/ (http://archive.apache.org/dist/jakarta/struts/old/release/v1.0.2/) That helps, thanks. Cheers, -- Tetsuya. ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23525] - HttpSessionListener implementors are called to late according to Servlet Specification 2.4 Final Draft 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=23525. 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=23525 HttpSessionListener implementors are called to late according to Servlet Specification 2.4 Final Draft 3 --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 14:14 --- Yes, will do it right now. -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12810] - socket write error clicking between pages to fast
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=12810.
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=12810
socket write error clicking between pages to fast
[EMAIL PROTECTED] changed:
What|Removed |Added
Keywords||JDK1.4
OS/Version|Windows XP |Windows NT/2K
Platform|Other |PC
Version|4.1.10 |4.0.6 Final
--- Additional Comments From [EMAIL PROTECTED] 2003-10-02 14:18 ---
When my controler (servlet) forward quickly to my view (jsp), I get the message
below:
...
else if (query.equals(pages/login.do)) {
if (usrActuel != null ) {
response.sendRedirect(response.encodeURL
(chantier/chantierListe.do));
return;
}
DoUsername collaborateurs[] = null;
collaborateurs = BoUsername.getLogin();
request.setAttribute(collaborateurs, collaborateurs);
request.getRequestDispatcher(login.jsp).forward(request,
response);
return;
...
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.catalina.connector.ResponseBase.flushBuffer
(ResponseBase.java:674)
at org.apache.catalina.connector.HttpResponseBase.flushBuffer
(HttpResponseBase.java:764)
at org.apache.catalina.connector.ResponseBase.write
(ResponseBase.java:647)
at org.apache.catalina.connector.ResponseStream.write
(ResponseStream.java:312)
at org.apache.catalina.connector.http.HttpResponseStream.write
(HttpResponseStream.java:189)
at org.apache.catalina.servlets.DefaultServlet.copyRange
(DefaultServlet.java:1921)
at org.apache.catalina.servlets.DefaultServlet.copy
(DefaultServlet.java:1670)
at org.apache.catalina.servlets.DefaultServlet.serveResource
(DefaultServlet.java:1215)
at org.apache.catalina.servlets.DefaultServlet.doGet
(DefaultServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:190)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.valves.CertificatesValve.invoke
(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2347)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
Re: problems with ant download
From: jean-frederic clere [EMAIL PROTECTED] ... but the interesting would be to have cgi that redirects to the result of closer.cgi instead displaying it. This would be useful for the *BSD porting systems to use. A method to download source tar files (without viewing/parsing an html page) from the closest mirror would allow *BSD ports to more effectively use the mirrors. If the 'closer' mirror fails they could fall back to a static list of the mirrors and put apache.org last. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [next] What's next ?
-Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 9:56 AM To: Tomcat Developers List Subject: RE: [next] What's next ? Then I have other ideas, of varying degrees of radicality and I'm sure stupidity ;) I'm proposing them for discussion, as I think they're all interesting. 1. Logging: use commons-logging throughout. Eliminate tomcat logger implementation classes (FileLogger, SystemErrLogger, SystemOutLogger). Eliminate catalina.out file, instead having swallowOutput=true always without option to change. Default logging configuration should still rotate nightly. +1 with reservations. If this happens please make sure you use your own file name and not the Default commons-logging file name. I have been tripped up when using 2 Third party libs and my own that all used the commons-logging default file name. Ick. 2. Eliminate the shared and common classloader repositories. Unless these are required by the spec? Force webapps to be self-contained by putting all their classes in WEB-INF/lib or WEB-INF/classes of their webapp. Have the WEB-INF/clases - WEB-INF/lib - endorsed - system classloader hierarchy, much simpler than current. -1 Ugh! No. I love the current format. I have full control of what webapps are in use on my system and I don't wish to have to maintain the build config that has each of my 5 web apps copy from a central repository instead of just using commons. I find the current solution rather elegant because I can use it but am not forced to. 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. +1 A must have. Might also want to think of adding a way to have a DB be the cluster session store. I currently do this and love it. 4. Have no default objects created at runtime. That means no default session manager if one is not configured, no default context if one is not configured, etc. Ship tomcat with an example server.xml containing all the default settings, and nothing more. +0 Would make people more aware of what is going on in the background. I worry about the support headaches this might inflict on tomcat-users. Of course, I'm willing to help on all of the above if we decide to do any of them. That should be enough to get some talk going ;) Yup. Should be fun. Yoav Shapira Millennium ChemInformatics --Angus Mezick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [next] What's next ?
On Thu, 2 Oct 2003, Angus Mezick wrote: 2. Eliminate the shared and common classloader repositories. Unless these are required by the spec? Force webapps to be self-contained by putting all their classes in WEB-INF/lib or WEB-INF/classes of their webapp. Have the WEB-INF/clases - WEB-INF/lib - endorsed - system classloader hierarchy, much simpler than current. -1 Ugh! No. I love the current format. I have full control of what webapps are in use on my system and I don't wish to have to maintain the build config that has each of my 5 web apps copy from a central repository instead of just using commons. I find the current solution rather elegant because I can use it but am not forced to. Ack. In contrast, I've sometimes wished to have webapp (classloader) hierarchies. A context nested in another context would see the outer classes but would be independently restartable. However, if a parent context is restarted, all children are restarted, too. Matthias -- Matthias Ernst Software Engineer CoreMedia - Smart Content Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23572] New: - alternateURL in JNDIRealm.class does not 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=23572.
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=23572
alternateURL in JNDIRealm.class does not work
Summary: alternateURL in JNDIRealm.class does not work
Product: Tomcat 4
Version: 4.1.27
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When using the alternateURL option in the JNDI Realm, if the first LDAP server
(designed by the connectionURL option) is not present or the LDAP service is
not available on this host, the application does not start, and the following
log appears :
Exception performing authentication
javax.naming.CommunicationException: ldap-server1:389.
Root exception is java.net.ConnectException: Connection refused
I corrected this behaviour by modifying JNDIRealm.java as follows
OLD SOURCE
try {
// Ensure that we have a directory context available
context = new InitialDirContext(getDirectoryContextEnvironment());
} catch (NamingException e) {
END OLD SOURCE ===
NEW SOURCE
try {
// Ensure that we have a directory context available
context = new InitialDirContext(getDirectoryContextEnvironment());
} catch (Exception e) {
END NEW SOURCE
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [next] What's next ?
Hello all, Potential new feature (for Jasper really): -JSP Line level error reporting for exceptions that occur during jsp execution IE. Leverage bcel to do some class munging on the generated class files. Chad Johnson WS Packaging Group, Inc. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 3:32 AM To: Tomcat Developers List Subject: [next] What's next ? Usually, when a Tomcat branch nears its release, a new branch is created. However, I only have a few feature ideas that make some sense, and the problem is that they are minor evolutions (hence, they could perfectly fit inside the 5.0 branch). This includes: - Updating JK2 to use the JMX events (the same ones the mapper uses) to get autoconfiguration, as an option. That seems useful, but it might well be a really stupid thing in the real world. - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat. - Use an in memory Java compiler to be able to automatically precompile webapps upon deployment. I heard such a compiler now exists, and this could be added fairly easily if it works well enough. I'm not a very big fan, but maybe it would make sense for some people. So to summarize, I have nothing to propose (sorry), and will focus on bugfixes and small additions in the 5.0 branch. If people want to see something more radical happen for the next major release, it's probably time to come up with proposals :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
Remy Maucherat a écrit : Usually, when a Tomcat branch nears its release, a new branch is created. However, I only have a few feature ideas that make some sense, and the problem is that they are minor evolutions (hence, they could perfectly fit inside the 5.0 branch). This includes: - Updating JK2 to use the JMX events (the same ones the mapper uses) to get autoconfiguration, as an option. That seems useful, but it might well be a really stupid thing in the real world. +0 - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat. There is allready cluster support in TC isn't it ? - Use an in memory Java compiler to be able to automatically precompile webapps upon deployment. I heard such a compiler now exists, and this could be added fairly easily if it works well enough. I'm not a very big fan, but maybe it would make sense for some people. Well another add-on which could be usefull for site which hosts many Tomcat instances but want to have them running on different JVM. I know Websphere does it and when it's managed via a decent user interface it make IT managers more than happy :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
Shapira, Yoav wrote: Howdy, On the subject of AccessLogValve: I hadn't thought of the things Tim suggested, but I have a different suggestion, part of a more general suggestion: 1. Convert AccessLogValve to be a servlet specification 2.3 filter, i.e. something portable. We can define it in $CATALINA_HOME/conf/web.xml, commented out by default perhaps, and users can move the definition around as they need just like they do with the servlets defined conf/web.xml. Furthermore, people can then extend/customize AccessLogFilter much more easily, without needing to touch any tomcat classes. And finally, this will allow the full power of filter-mapping to be applied to access logging. (I imagine the default in conf/web.xml would be the /* url-pattern mapping, but I know I and other users have different use cases). If you think this is useful, I'd like to start working on it myself ;) If you think it's not useful/bad/stupid, please let me know ;) Interesting. The pitfall is that optimizations could be harder, but otherwise, it could be a good idea. I think a significant amount of stuff did exist in TC 4.0 because of the fact that many things weren't there in the servlet API. A massive refactoring could be a good idea. 2. As an extension of the above idea, I would propose converting more of the tomcat non-standard features into portable implementations. This includes the other filters, e.g. RemoteAddressFilter, RemoteHostFilter, RequestDumperValve, and others you think are appropriate. Then I have other ideas, of varying degrees of radicality and I'm sure stupidity ;) I'm proposing them for discussion, as I think they're all interesting. 1. Logging: use commons-logging throughout. Eliminate tomcat logger implementation classes (FileLogger, SystemErrLogger, SystemOutLogger). Eliminate catalina.out file, instead having swallowOutput=true always without option to change. Default logging configuration should still rotate nightly. Migration to commons-logging can IMO be restarted in 5.0, since the issues with commons-logging have been fixed. I think per instance loggers, with category names including the full component name, are needed. 2. Eliminate the shared and common classloader repositories. Unless these are required by the spec? Force webapps to be self-contained by putting all their classes in WEB-INF/lib or WEB-INF/classes of their webapp. Have the WEB-INF/clases - WEB-INF/lib - endorsed - system classloader hierarchy, much simpler than current. I believe many people won't like that one. It's quite radical :) It is true that it would be much simpler to run only straight webapps, without exceptions. I think this kind of classloading structure can be configured in TC 5 using the catalina.properties. 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. So you want to do a HTTP load balancer ? I think this would be a really good project for the commons. 4. Have no default objects created at runtime. That means no default session manager if one is not configured, no default context if one is not configured, etc. Ship tomcat with an example server.xml containing all the default settings, and nothing more. Is that useful ? I don't really see how. (ex: if you have no loader for a webapp, it won't work) I think you should elaborate more. Of course, I'm willing to help on all of the above if we decide to do any of them. That should be enough to get some talk going ;) Let's see :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. So you want to do a HTTP load balancer ? I think this would be a really good project for the commons. It's was one of the goal of ajp13++ (ajp14) since mod_jk allready provide load balancing, may be we should take another look at it - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
I would be interested to: - implement jsr115 as an optional feature (based on a previous discussion with Costin on this thread (that may bring Costing back :-) ). - turn SecurityManager on by default ( already proposed by Costin sometime ago if I remember). - improve xml parsing performance (may found that the problem is with my favorite parser ;-) ) -- Jeanfrancois Remy Maucherat wrote: Usually, when a Tomcat branch nears its release, a new branch is created. However, I only have a few feature ideas that make some sense, and the problem is that they are minor evolutions (hence, they could perfectly fit inside the 5.0 branch). This includes: - Updating JK2 to use the JMX events (the same ones the mapper uses) to get autoconfiguration, as an option. That seems useful, but it might well be a really stupid thing in the real world. - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat. - Use an in memory Java compiler to be able to automatically precompile webapps upon deployment. I heard such a compiler now exists, and this could be added fairly easily if it works well enough. I'm not a very big fan, but maybe it would make sense for some people. So to summarize, I have nothing to propose (sorry), and will focus on bugfixes and small additions in the 5.0 branch. If people want to see something more radical happen for the next major release, it's probably time to come up with proposals :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
Henri Gomez wrote: Remy Maucherat a écrit : Usually, when a Tomcat branch nears its release, a new branch is created. However, I only have a few feature ideas that make some sense, and the problem is that they are minor evolutions (hence, they could perfectly fit inside the 5.0 branch). This includes: - Updating JK2 to use the JMX events (the same ones the mapper uses) to get autoconfiguration, as an option. That seems useful, but it might well be a really stupid thing in the real world. +0 I'm not convinced either, but often I see people who want an easier to use JK. Having control over what is mounted where seems useful. - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat. There is allready cluster support in TC isn't it ? Yes. - Use an in memory Java compiler to be able to automatically precompile webapps upon deployment. I heard such a compiler now exists, and this could be added fairly easily if it works well enough. I'm not a very big fan, but maybe it would make sense for some people. Well another add-on which could be usefull for site which hosts many Tomcat instances but want to have them running on different JVM. Interesting. How do they do that ? I know Websphere does it and when it's managed via a decent user interface it make IT managers more than happy :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22390] - init() method called twice
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=22390. 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=22390 init() method called twice [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 15:16 --- Dan is right. Actually I forgot there are 2 vitual hosts configured on the same Tomcat. In my case I don't have Apache connector. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [next] What's next ?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 10:50 AM To: Tomcat Developers List Subject: RE: [next] What's next ? On Thu, 2 Oct 2003, Angus Mezick wrote: 2. Eliminate the shared and common classloader repositories. Unless these are required by the spec? Force webapps to be self-contained by putting all their classes in WEB-INF/lib or WEB-INF/classes of their webapp. Have the WEB-INF/clases - WEB-INF/lib - endorsed - system classloader hierarchy, much simpler than current. -1 Ugh! No. I love the current format. I have full control of what webapps are in use on my system and I don't wish to have to maintain the build config that has each of my 5 web apps copy from a central repository instead of just using commons. I find the current solution rather elegant because I can use it but am not forced to. Ack. In contrast, I've sometimes wished to have webapp (classloader) hierarchies. A context nested in another context would see the outer classes but would be independently restartable. However, if a parent context is restarted, all children are restarted, too. -1 where would we put native libraries? I can't put them in /WEB-INF/lib without giving up reloading. I don't think we want to encourage people to put anything in the jvm's lib directory now that we got rid of classpath hell. I could see combining 'shared' and 'common' since they are essentially the same. Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
Henri Gomez a écrit : 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. One of the features I'd like to see in Tomcat 5.x, a features which prevent me to use TC 4.0.x, 4.1.x and 5.x on my production server is the ability to use external entities from within a web.xml. Let me explain : We have many customers which run the same application but with differents settings. All the settings are present in the web.xml via the use of external entities which are included at run-time. The security mechanism in TC 4.x and higher (due to digester) avoid me to use such easy configuration tuning and so we have to stay with Tomcat 3.3.x for now. If we could have a 'relaxed mode', I could switch all my productions servers to 5.x immediatly. We allready discuss in the past and option like JNDI and DSML provider are not valid options for us (for admins and historics reasons). So I'll welcome such 'relaxed mode' since I still wonder what the diff between load external xml entities from outside webapp or loading from JDNI + DSML... I'd like to have your opinions here - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
Henri Gomez wrote: Henri Gomez a écrit : 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. One of the features I'd like to see in Tomcat 5.x, a features which prevent me to use TC 4.0.x, 4.1.x and 5.x on my production server is the ability to use external entities from within a web.xml. Let me explain : We have many customers which run the same application but with differents settings. All the settings are present in the web.xml via the use of external entities which are included at run-time. +1 The security mechanism in TC 4.x and higher (due to digester) avoid me to use such easy configuration tuning and so we have to stay with Tomcat 3.3.x for now. I'm probably missing something herewhy the digester suffer from that limitation? What kind of security exception are you seeing. If you give all permissions to the Digester, does it change something? -- Jeanfrancois If we could have a 'relaxed mode', I could switch all my productions servers to 5.x immediatly. We allready discuss in the past and option like JNDI and DSML provider are not valid options for us (for admins and historics reasons). So I'll welcome such 'relaxed mode' since I still wonder what the diff between load external xml entities from outside webapp or loading from JDNI + DSML... I'd like to have your opinions here - 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: [next] What's next ?
Jean-Francois Arcand a écrit : Henri Gomez wrote: Henri Gomez a écrit : 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. One of the features I'd like to see in Tomcat 5.x, a features which prevent me to use TC 4.0.x, 4.1.x and 5.x on my production server is the ability to use external entities from within a web.xml. Let me explain : We have many customers which run the same application but with differents settings. All the settings are present in the web.xml via the use of external entities which are included at run-time. +1 The security mechanism in TC 4.x and higher (due to digester) avoid me to use such easy configuration tuning and so we have to stay with Tomcat 3.3.x for now. I'm probably missing something herewhy the digester suffer from that limitation? What kind of security exception are you seeing. If you give all permissions to the Digester, does it change something? i don't know how to setup digester to do it but the last time I tried with TC 4.1.x, I couldn't get external entities : Here is a sample web.xml : In my case env and defusr are located in ../../etc/webapp/app.xml which differs from one client to another. With the current limitation (tested on TC 4.1.x), I couldn't have them loaded from ../../etc/webapp/app.xml... --- ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2.2.dtd; [ !ENTITY % appconf SYSTEM ../../etc/webapp/app.xml %appconf; ] web-app context-param param-namedef.user/param-name param-valuedefusr;/param-value /context-param servlet servlet-namestartup/servlet-name servlet-classmy.StartupServlet/servlet-class init-param param-nameenv/param-name param-valueenvid;/param-value /init-param /servlet session-config session-timeout30/session-timeout /session-config welcome-file-list welcome-file/index/welcome-file /welcome-file-list /web-app - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote problems on a EBCDIC machine
Clere, Jean-Frederic wrote:
Remy Maucherat wrote:
jean-frederic clere wrote:
Hi,
I have a funny problem with Coyote: The response body are Ok (in
ASCII) but the headers are corrupted (probably in EBCDIC). May be
somewhere I have to tell Coyote to do ASCII instead default encoding.
Has someone a hint?
The header writing is in http11.InternalOutputBuffer. Is something
special needed ?
Probably some getBytes(ISO-8859-1) instead of getBytes()
Oops...
Mostly in http11/src/java/org/apache/coyote/http11/Constants.java getBytes(char
encoding) throws execptions so I have to use:
{ (byte) 'a', (byte) 'b' ... };
instead of:
ab.getBytes();
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23565] - Reload in the manager app does not 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=23565. 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=23565 Reload in the manager app does not work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 15:51 --- Look for the Hotfix on the Jakarta site to fix this issue. *** This bug has been marked as a duplicate of 22096 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22096] - reload through manager webapp fails to redeploy classes/jars
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=22096. 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=22096 reload through manager webapp fails to redeploy classes/jars [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 15:51 --- *** Bug 23565 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote problems on a EBCDIC machine
jean-frederic clere wrote:
Clere, Jean-Frederic wrote:
Remy Maucherat wrote:
jean-frederic clere wrote:
Hi,
I have a funny problem with Coyote: The response body are Ok (in
ASCII) but the headers are corrupted (probably in EBCDIC). May be
somewhere I have to tell Coyote to do ASCII instead default encoding.
Has someone a hint?
The header writing is in http11.InternalOutputBuffer. Is something
special needed ?
Probably some getBytes(ISO-8859-1) instead of getBytes()
Oops...
Mostly in http11/src/java/org/apache/coyote/http11/Constants.java
getBytes(char encoding) throws execptions so I have to use:
{ (byte) 'a', (byte) 'b' ... };
instead of:
ab.getBytes();
Ah, ok, I wasn't seeing any getBytes in InternalOutputBuffer, so this
was a bit confusing.
Maybe we can add a static method which does the byte by byte copy to
preserve some kind of readability, while still fixing the issue.
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [next] What's next ?
Howdy, 2. Eliminate the shared and common classloader repositories. Unless these are required by the spec? Force webapps to be self-contained by putting all their classes in WEB-INF/lib or WEB-INF/classes of their webapp. Have the WEB-INF/clases - WEB-INF/lib - endorsed - system classloader hierarchy, much simpler than current. I believe many people won't like that one. It's quite radical :) It is true that it would be much simpler to run only straight webapps, without exceptions. I think this kind of classloading structure can be configured in TC 5 using the catalina.properties. If it can be achieved via configuration, I'm happy ;) How can it be done? Vis a vis native libraries and reloading -- I didn't have that scenario in mind. I don't know what to do about that one. So what you're saying is there's no way to deploy a self-contained webapp (everything under the webapp root), and be able to restart it without restarting the server, if you're using a native library in your webapp? 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. So you want to do a HTTP load balancer ? I think this would be a really good project for the commons. I had something even simpler in mind: - A cluster of backend tomcat servers - A single tomcat front-end server, with one filter mapped to /* that has configurable rules on how to direct requests to the backend servers. (e.g. string match in URL rules, remote address rules, etc.) But as someone mentioned, I also think an HTTP load-balancer was discussed as a future version of ajp1[3-4]. I should search the archives for those threads. 4. Have no default objects created at runtime. That means no default session manager if one is not configured, no default context if one is not configured, etc. Ship tomcat with an example server.xml containing all the default settings, and nothing more. Is that useful ? I don't really see how. (ex: if you have no loader for a webapp, it won't work) I think you should elaborate more. I suggested that one in order to simply supporting users. The less stuff that happens behind the scenes as far as configuration, the better. It should all be visible, so that on the user mailing list we can say this happens because line XXX of server.xml you have this string. Contrast with as part of tomcat's default context initialization, the property gets assigned this default value, which you can override by adding this element to server.xml, see config reference here. The more users can see by themselves by inspecting server.xml, the better IMHO. Yoav Shapira 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: [next] What's next ?
Shapira, Yoav wrote: Howdy, I think this kind of classloading structure can be configured in TC 5 using the catalina.properties. If it can be achieved via configuration, I'm happy ;) How can it be done? You can set empty contents to the repositories list in catalina.properties, and then move whatever is required to common/endorsed. The CL ierarchy will still exist (but they won't contain anything). Is that useful ? I don't really see how. (ex: if you have no loader for a webapp, it won't work) I think you should elaborate more. I suggested that one in order to simply supporting users. The less stuff that happens behind the scenes as far as configuration, the better. It should all be visible, so that on the user mailing list we can say this happens because line XXX of server.xml you have this string. Contrast with as part of tomcat's default context initialization, the property gets assigned this default value, which you can override by adding this element to server.xml, see config reference here. The more users can see by themselves by inspecting server.xml, the better IMHO. Possibly :) It's a bit hard to answer. The more XML is needed, the more intimidating it looks. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JK2 connection timeout
Hi all, Since posting to the Tomcat user list did not bring forward satisfing answers - and since this may be a JK2 bug - I'm posting here, too. I'm using JK2 to connect Tomcat 4.1.18 and IIS 5.1 (on XP) with JRE 1.4.0_02. Tomcat's stderr.log contains hundreds of the following messages. 01.10.2003 13:56:20 org.apache.jk.common.ChannelSocket processConnection INFO: connection timeout reached The connector operates just fine but how can I avoid timeouts? A connection should be opened, used, and then closed. Timeout to me means that someone (developer who writes code) forgot to close it. Regards, Marcel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Logging filter (was RE: [next] What's next ?)
--- Shapira, Yoav [EMAIL PROTECTED] wrote: 1. Convert AccessLogValve to be a servlet specification 2.3 filter, i.e. something portable. We can define it in $CATALINA_HOME/conf/web.xml, commented out by default perhaps, and users can move the definition around as they need just like they do with the servlets defined conf/web.xml. Furthermore, people can then extend/customize AccessLogFilter much more easily, without needing to touch any tomcat classes. And finally, this will allow the full power of filter-mapping to be applied to access logging. (I imagine the default in conf/web.xml would be the /* url-pattern mapping, but I know I and other users have different use cases). If you think this is useful, I'd like to start working on it myself ;) If you think it's not useful/bad/stupid, please let me know ;) That sounds wonderful and useful, but there are a few problems here. Filters don't have access to all the information that is needed to make a log entry the way the AccessLogValve does it. Content length, response code and content type variables may not be known when the filter is processing, and (last time I checked) there is no byte[] Response.getContentType() method. There is setContentType() but no getContentType(). I'm not sure what would need to be changed in the Filter implementation to allow these variables to be exposed, but until they are, a Filter won't provide enough information to the log users. We definitely definitely need to know response codes every time, for example. Either the Filter functionality needs to be changed, or perhaps there should be a Loglet (ugh) API specification so we can write logging classes in a standard way. This is a problem throughout Tomcat/Servlets: some parts of the core functionality should be more exposed. For example, have you ever tried to write a customer class loader for your webapp? It is a mess. You need to subclass WebappClassLoader, which was clearly never designed to be subclassed (and should be marked final for that reason, according to Joshua Bloch's book). I still can't figure out how to tell Jasper about using some different classloader. All of this is a mess and shouldn't be this way. Sometime when I have more time maybe I will work on these things. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging filter (was RE: [next] What's next ?)
Howdy, --- Shapira, Yoav [EMAIL PROTECTED] wrote: 1. Convert AccessLogValve to be a servlet specification 2.3 filter, i.e. That sounds wonderful and useful, but there are a few problems here. Filters don't have access to all the information that is needed to make a log entry the way the AccessLogValve does it. Content length, response code and content type variables may not be known when the filter is processing, and (last time I checked) there is no byte[] Response.getContentType() method. There is setContentType() but no getContentType(). That's unfortunate ;( getContentType() is there, actually, in ServletResponse. But not getContentLength() nor getStatusCode(). I was planning the AccessLogFilter just support the Common and Combined access log files patterns, and I imagined all the required fields for those patterns are part of standard interfaces. In fact, why aren't there methods like getHeader(String name) and getContentLength() in the ServletResponse interface? Can someone familiar with the Servlet Specification comment on this? Yoav Shapira 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: Coyote problems on a EBCDIC machine
Remy Maucherat wrote:
jean-frederic clere wrote:
Clere, Jean-Frederic wrote:
Remy Maucherat wrote:
jean-frederic clere wrote:
Hi,
I have a funny problem with Coyote: The response body are Ok (in
ASCII) but the headers are corrupted (probably in EBCDIC). May be
somewhere I have to tell Coyote to do ASCII instead default encoding.
Has someone a hint?
The header writing is in http11.InternalOutputBuffer. Is something
special needed ?
Probably some getBytes(ISO-8859-1) instead of getBytes()
Oops...
Mostly in http11/src/java/org/apache/coyote/http11/Constants.java
getBytes(char encoding) throws execptions so I have to use:
{ (byte) 'a', (byte) 'b' ... };
instead of:
ab.getBytes();
Ah, ok, I wasn't seeing any getBytes in InternalOutputBuffer, so this
was a bit confusing.
Sorry.
Maybe we can add a static method which does the byte by byte copy to
preserve some kind of readability, while still fixing the issue.
Well that is true that:
+++
public static final byte[] ACK =
HTTP/1.1 100 Continue\r\n\r\n.getBytes();
+++
Is more readable than:
+++
public static final byte[] ACK = {
(byte) '1',
(byte) '.',
(byte) '1',
(byte) ' ',
(byte) '1',
(byte) '0',
(byte) '0',
(byte) ' ',
(byte) 'C',
(byte) 'o',
(byte) 'n',
(byte) 't',
(byte) 'i',
(byte) 'n',
(byte) 'u',
(byte) 'e',
(byte) '\r',
(byte) '\n',
(byte) '\r',
(byte) '\n'
};
+++
But that is still readable ;-)
And now my EBCDIC machine seems to return understandable headers :-) (Well it
seems now that the body of other things that errors are also somehow in EBCDIC
but I will look how to arrange it).
I will commit the changes in
http11/src/java/org/apache/coyote/http11/Constants.java tomorrow if noone
complains in the meantime.
Cheers
Jean-Frederic
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: http11/src/java/org/apache/coyote/http11/Constants.java
===
RCS file:
/home/cvs/mirror/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Constants.java,v
retrieving revision 1.12
diff -u -r1.12 Constants.java
--- http11/src/java/org/apache/coyote/http11/Constants.java 24 Nov 2002 22:00:04
- 1.12
+++ http11/src/java/org/apache/coyote/http11/Constants.java 2 Oct 2003 16:29:38
-
@@ -159,25 +159,42 @@
/**
* CRLF bytes.
*/
-public static final byte[] CRLF_BYTES = \r\n.getBytes();
+public static final byte[] CRLF_BYTES = {(byte) '\r', (byte) '\n'};
/**
* Colon bytes.
*/
-public static final byte[] COLON_BYTES = : .getBytes();
+public static final byte[] COLON_BYTES = {(byte) ':', (byte) ' '};
/**
* Close bytes.
*/
-public static final byte[] CLOSE_BYTES = close.getBytes();
+public static final byte[] CLOSE_BYTES = {
+(byte) 'c',
+(byte) 'l',
+(byte) 'o',
+(byte) 's',
+(byte) 'e'
+};
/**
* Keep-alive bytes.
*/
-public static final byte[] KEEPALIVE_BYTES = keep-alive.getBytes();
+public static final byte[] KEEPALIVE_BYTES = {
+(byte) 'k',
+(byte) 'e',
+(byte) 'e',
+(byte) 'p',
+(byte) '-',
+(byte) 'a',
+(byte) 'l',
+(byte) 'i',
+(byte) 'v',
+(byte) 'e'
+};
/**
@@ -231,8 +248,26 @@
/**
* Ack string when pipelining HTTP requests.
*/
-public static final byte[] ACK =
-HTTP/1.1 100 Continue\r\n\r\n.getBytes();
-
-
+public static final byte[] ACK = {
+(byte) '1',
+(byte) '.',
+(byte) '1',
+(byte) ' ',
+(byte) '1',
+(byte) '0',
+(byte) '0',
+(byte) ' ',
+(byte) 'C',
+(byte) 'o',
+(byte) 'n',
+(byte) 't',
+(byte) 'i',
+(byte) 'n',
+(byte) 'u',
+(byte) 'e',
+(byte) '\r',
+(byte) '\n',
+(byte) '\r',
+(byte) '\n'
+};
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging filter (was RE: [next] What's next ?)
--- Shapira, Yoav [EMAIL PROTECTED] wrote: That's unfortunate ;( Yes it is. Those methods may not really belong in the Filter interface, though. That's why I think it may be a better idea to start thinking about a real API for more of the core components of the server: logging, classloading, network interface, etc. This would not have to be part of the Servlet specification, because it's a separate issue. Maybe this could be called the Jakarta Container API or something. Just a few simple interfaces (starting with logging perhaps) would be very handy. Does anyone think this is interesting? getContentType() is there, actually, in Ah, it's good that getContentType() is there. That is new I think. In fact, why aren't there methods like getHeader(String name) and getContentLength() in the ServletResponse interface? Can someone familiar with the Servlet Specification comment on this? I think that many of those values, such as ContentLength, are not known until all the webapp stuff is completely done touching the response. The filter could change the response in some way at any time, so those values cannot be set. Also, values like the response code cannot be known because if there is a Java error ANYWHERE in the webapps's chain of processing, including in a logging filter, that changes the response code. Filters sound like a good way to do this but I don't think they're exactly the right level for it. But there should be an exposed, supported API for writing custom logging. It is something which so many people need to do. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging filter (was RE: [next] What's next ?)
Howdy,
There's already an exposed API for writing tomcat loggers (just
implement org.apache.catalina.Logger and configure your logger in
server.xml). Let's get off that topic please and stick to the access
log filter I was proposing.
I think that many of those values, such as
ContentLength, are not known until all the webapp
stuff is completely done touching the response. The
This is true. This stuff, and the access log record, would be written
on the outgoing part of the filter, i.e. (abbreviated form)
doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
... Start new log record ...
... Enter request parameters into log record ...
... chain.doFilter(req, res); // After this, response is done
... Gather response parameters for log record
... Write log record to file
}
But your also make an interesting point about errors during the
response. The chain.doFilter method throws IO and Servlet exceptions.
Perhaps they could be caught in the filter, logged, and thrown again
after the log record is written?
Yoav Shapira
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: [next] What's next ?
Henri Gomez wrote: Jean-Francois Arcand a écrit : Henri Gomez wrote: Henri Gomez a écrit : 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. One of the features I'd like to see in Tomcat 5.x, a features which prevent me to use TC 4.0.x, 4.1.x and 5.x on my production server is the ability to use external entities from within a web.xml. Let me explain : We have many customers which run the same application but with differents settings. All the settings are present in the web.xml via the use of external entities which are included at run-time. +1 The security mechanism in TC 4.x and higher (due to digester) avoid me to use such easy configuration tuning and so we have to stay with Tomcat 3.3.x for now. I'm probably missing something herewhy the digester suffer from that limitation? What kind of security exception are you seeing. If you give all permissions to the Digester, does it change something? i don't know how to setup digester to do it but the last time I tried with TC 4.1.x, I couldn't get external entities : Here is a sample web.xml : In my case env and defusr are located in ../../etc/webapp/app.xml which differs from one client to another. With the current limitation (tested on TC 4.1.x), I couldn't have them loaded from ../../etc/webapp/app.xml... Loading relative references like this works fine for me when I have the side files in the WEB-INF directory next to the web.xml file. Without describing what error messages you get when you try this, it's impossible to know what's really going on. However, your relative references to the app.xml file will certainly not work in at least three scenarios: * You run the webapp from a WAR file directly (because you'd be trying to navigate above the WAR, and .. doesn't mean anything in that scenario. * You run the webapp by dynamic deployment (via Manager) instead of under the webapps directory -- thus invalidating the directory navigation (../..) because Manager puts the deployed webapp in a different place in the filesystem. * You run under a security manager that disallows access to any file outside your webapp. One obvious thing to try would be using an absolute file: (or even http:) URL -- that would fix the first two cases. For the third case, you'll have to adjust your security manager permissions no matter what. But without knowing what error mesage you get when you try, there's nothing anyone can do but guess. Craig --- ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2.2.dtd; [ !ENTITY % appconf SYSTEM ../../etc/webapp/app.xml %appconf; ] web-app context-param param-namedef.user/param-name param-valuedefusr;/param-value /context-param servlet servlet-namestartup/servlet-name servlet-classmy.StartupServlet/servlet-class init-param param-nameenv/param-name param-valueenvid;/param-value /init-param /servlet session-config session-timeout30/session-timeout /session-config welcome-file-list welcome-file/index/welcome-file /welcome-file-list /web-app - 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]
cvs commit: jakarta-tomcat-catalina/catalina/src/bin catalina.sh catalina.bat
jfarcand2003/10/02 10:07:40 Modified:catalina/src/bin catalina.sh catalina.bat Log: Minor fixes (should we remove that props?). Revision ChangesPath 1.9 +3 -3 jakarta-tomcat-catalina/catalina/src/bin/catalina.sh Index: catalina.sh === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/catalina.sh,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- catalina.sh 2 Sep 2003 12:23:13 - 1.8 +++ catalina.sh 2 Oct 2003 17:07:40 - 1.9 @@ -155,7 +155,7 @@ shift exec $_RUNJDB $JAVA_OPTS $CATALINA_OPTS \ -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS -classpath $CLASSPATH \ --sourcepath $CATALINA_HOME/../../jakarta-tomcat-4.0/catalina/src/share \ +-sourcepath $CATALINA_HOME/../../jakarta-tomcat-catalina/catalina/src/share \ -Djava.security.manager \ -Djava.security.policy==$CATALINA_BASE/conf/catalina.policy \ -Dcatalina.base=$CATALINA_BASE \ @@ -165,7 +165,7 @@ else exec $_RUNJDB $JAVA_OPTS $CATALINA_OPTS \ -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS -classpath $CLASSPATH \ --sourcepath $CATALINA_HOME/../../jakarta-tomcat-4.0/catalina/src/share \ +-sourcepath $CATALINA_HOME/../../jakarta-tomcat-catalina/catalina/src/share \ -Dcatalina.base=$CATALINA_BASE \ -Dcatalina.home=$CATALINA_HOME \ -Djava.io.tmpdir=$CATALINA_TMPDIR \ 1.5 +2 -2 jakarta-tomcat-catalina/catalina/src/bin/catalina.bat Index: catalina.bat === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/catalina.bat,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- catalina.bat 29 Sep 2003 10:27:20 - 1.4 +++ catalina.bat 2 Oct 2003 17:07:40 - 1.5 @@ -123,7 +123,7 @@ :doDebug shift set _EXECJAVA=%_RUNJDB% -set DEBUG_OPTS=-sourcepath %CATALINA_HOME%\..\..\jakarta-tomcat-4.0\catalina\src\share +set DEBUG_OPTS=-sourcepath %CATALINA_HOME%\..\..\jakarta-tomcat-catalina\catalina\src\share if not %1 == -security goto execCmd shift echo Using Security Manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging filter (was RE: [next] What's next ?)
joe user wrote: --- Shapira, Yoav [EMAIL PROTECTED] wrote: 1. Convert AccessLogValve to be a servlet specification 2.3 filter, i.e. something portable. We can define it in $CATALINA_HOME/conf/web.xml, commented out by default perhaps, and users can move the definition around as they need just like they do with the servlets defined conf/web.xml. Furthermore, people can then extend/customize AccessLogFilter much more easily, without needing to touch any tomcat classes. And finally, this will allow the full power of filter-mapping to be applied to access logging. (I imagine the default in conf/web.xml would be the /* url-pattern mapping, but I know I and other users have different use cases). If you think this is useful, I'd like to start working on it myself ;) If you think it's not useful/bad/stupid, please let me know ;) That sounds wonderful and useful, but there are a few problems here. Filters don't have access to all the information that is needed to make a log entry the way the AccessLogValve does it. Content length, response code and content type variables may not be known when the filter is processing, and (last time I checked) there is no byte[] Response.getContentType() method. There is setContentType() but no getContentType(). Easily solved by having the filter add a response wrapper that provides access to the needed information. There's a jakarta-commons sandbox package called filters that was originally designed to be a home for general purpose Filters like this. If you want to experiment with creating Filter implementations of some things that are currently Valves in Tomcat, that would be a good place to do it. For access logging in particular, I'd be concerned about a couple of things: * Filters don't see every request (for example, the authentication challenges when you're using BASIC authentication). * Filters only see the requests for their particular webapp. * Filters require the webapp to be configured itself to enable them, versus the current approach where access logging is a container configuration issue. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session StandardSession.java
jfarcand2003/10/02 10:10:54
Modified:catalina/src/share/org/apache/catalina/session
StandardSession.java
Log:
Fix for bugzilla 23525 HttpSessionListener implementors are called to late according
to Servlet Specification 2.4 Final Draft 3.
Revision ChangesPath
1.23 +11 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
Index: StandardSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- StandardSession.java 2 Sep 2003 21:22:01 - 1.22
+++ StandardSession.java 2 Oct 2003 17:10:54 - 1.23
@@ -575,10 +575,14 @@
*/
public boolean isValid() {
-if (!this.isValid || this.expiring) {
+if (this.expiring){
+return true;
+}
+
+if (!this.isValid ) {
return false;
}
-
+
if (maxInactiveInterval = 0) {
long timeNow = System.currentTimeMillis();
int timeIdle = (int) ((timeNow - lastAccessedTime) / 1000L);
@@ -1154,7 +1158,7 @@
public void removeAttribute(String name, boolean notify) {
// Validate our current state
-if (!expiring !isValid())
+if (!isValid())
throw new IllegalStateException
(sm.getString(standardSession.removeAttribute.ise));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23525] - HttpSessionListener implementors are called to late according to Servlet Specification 2.4 Final Draft 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=23525. 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=23525 HttpSessionListener implementors are called to late according to Servlet Specification 2.4 Final Draft 3 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 17:15 --- Applied modified Remy's patche. Now it works as expected. Thanks, -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging filter (was RE: [next] What's next ?)
Shapira, Yoav wrote:
Howdy,
--- Shapira, Yoav [EMAIL PROTECTED] wrote:
1. Convert AccessLogValve to be a servlet
specification 2.3 filter, i.e.
That sounds wonderful and useful, but there are a few
problems here. Filters don't have access to all the
information that is needed to make a log entry the way
the AccessLogValve does it. Content length, response
code and content type variables may not be known when
the filter is processing, and (last time I checked)
there is no byte[] Response.getContentType() method.
There is setContentType() but no getContentType().
That's unfortunate ;(
getContentType() is there, actually, in ServletResponse. But not
getContentLength() nor getStatusCode(). I was planning the
AccessLogFilter just support the Common and Combined access log files
patterns, and I imagined all the required fields for those patterns are
part of standard interfaces.
In fact, why aren't there methods like getHeader(String name) and
getContentLength() in the ServletResponse interface? Can someone
familiar with the Servlet Specification comment on this?
That's what HttpServletResponseWrapper is for. Simply have your logging
filter wrap the response (on the way in) with a wrapper class that adds
the necessary getters, and overrides the setters to store what you need
where the getters can get to it. Skeleton implementation for just the
content length:
public class MyResponseWrapper implements HttpServletResponseWrapper {
...
// Local variable in which to cache the content length
private int saveContentLength;
// The standard response method
public void setContentLength(int contentLength) {
saveContentLength = contentLength;
super.setContentLength(contentLength);
}
// Added method in my wrapper class
public int getContentLength() { return saveContentLength; }
}
Yoav Shapira
Craig
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
- Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat After looking into it, writing a load balancer in Java will only cause the load balancer to become a bottleneck nothing else, Java doesn't offer enough low level to be able to do TCP load balancing well. Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 02, 2003 1:31 AM Subject: [next] What's next ? Usually, when a Tomcat branch nears its release, a new branch is created. However, I only have a few feature ideas that make some sense, and the problem is that they are minor evolutions (hence, they could perfectly fit inside the 5.0 branch). This includes: - Updating JK2 to use the JMX events (the same ones the mapper uses) to get autoconfiguration, as an option. That seems useful, but it might well be a really stupid thing in the real world. - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat. - Use an in memory Java compiler to be able to automatically precompile webapps upon deployment. I heard such a compiler now exists, and this could be added fairly easily if it works well enough. I'm not a very big fan, but maybe it would make sense for some people. So to summarize, I have nothing to propose (sorry), and will focus on bugfixes and small additions in the 5.0 branch. If people want to see something more radical happen for the next major release, it's probably time to come up with proposals :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
Filip Hanik wrote: - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat After looking into it, writing a load balancer in Java will only cause the load balancer to become a bottleneck nothing else, Java doesn't offer enough low level to be able to do TCP load balancing well. I know there's the project called balance that you pointed out before, but I don't think it supports session affinity (bad, since session affinity is mandated by the spec). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
yeah it is a very simple solution, round robin, http://www.inlab.de/balance.html no session affinity, which requires introspection to do. ie, look up the session id (for example) in the request, and pass it on to the correct server kind of like jvmRoute Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 02, 2003 10:38 AM Subject: Re: [next] What's next ? Filip Hanik wrote: - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat After looking into it, writing a load balancer in Java will only cause the load balancer to become a bottleneck nothing else, Java doesn't offer enough low level to be able to do TCP load balancing well. I know there's the project called balance that you pointed out before, but I don't think it supports session affinity (bad, since session affinity is mandated by the spec). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [next] What's next ?
-Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 11:57 AM To: Tomcat Developers List Subject: RE: [next] What's next ? Howdy, 2. Eliminate the shared and common classloader repositories. Unless these are required by the spec? Force webapps to be self-contained by putting all their classes in WEB-INF/lib or WEB-INF/classes of their webapp. Have the WEB-INF/clases - WEB-INF/lib - endorsed - system classloader hierarchy, much simpler than current. I believe many people won't like that one. It's quite radical :) It is true that it would be much simpler to run only straight webapps, without exceptions. I think this kind of classloading structure can be configured in TC 5 using the catalina.properties. If it can be achieved via configuration, I'm happy ;) How can it be done? Vis a vis native libraries and reloading -- I didn't have that scenario in mind. I don't know what to do about that one. So what you're saying is there's no way to deploy a self-contained webapp (everything under the webapp root), and be able to restart it without restarting the server, if you're using a native library in your webapp? yes, that's it. Once you drop the classloader that holds the library reference, you can no longer access the library and can not load it again(error:'library already loaded in another classloader'). Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [next] What's next ?
On Thu, October 2, 2003 at 8:56 am, Shapira, Yoav sent the following 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. So you want to do a HTTP load balancer ? I think this would be a really good project for the commons. I had something even simpler in mind: - A cluster of backend tomcat servers - A single tomcat front-end server, with one filter mapped to /* that has configurable rules on how to direct requests to the backend servers. (e.g. string match in URL rules, remote address rules, etc.) But as someone mentioned, I also think an HTTP load-balancer was discussed as a future version of ajp1[3-4]. I should search the archives for those threads. Going a bit further with what you said, it seems that all that is required is a load balancing filter and some documentation written to support it. The load balancing filter itself should probably go into the commons project as it should would work with any servlet container. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
bottom line is writing a Java loadbalancer is like trying to cross the atlantic ocean with a canoe. there is no point. Java simply can't handle enough concurrent connections, and then if you want session affinity you need introspection, which means you will be parsing the HTTP request coming in, Load balancing belongs to hardware, and in software (native code) on nothing but the smallest projects Filip - Original Message - From: David Rees [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 02, 2003 11:17 AM Subject: RE: [next] What's next ? On Thu, October 2, 2003 at 8:56 am, Shapira, Yoav sent the following 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. So you want to do a HTTP load balancer ? I think this would be a really good project for the commons. I had something even simpler in mind: - A cluster of backend tomcat servers - A single tomcat front-end server, with one filter mapped to /* that has configurable rules on how to direct requests to the backend servers. (e.g. string match in URL rules, remote address rules, etc.) But as someone mentioned, I also think an HTTP load-balancer was discussed as a future version of ajp1[3-4]. I should search the archives for those threads. Going a bit further with what you said, it seems that all that is required is a load balancing filter and some documentation written to support it. The load balancing filter itself should probably go into the commons project as it should would work with any servlet container. -Dave - 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: [next] What's next ?
On Thu, October 2, 2003 1at 0:33 am, Filip Hanik sent the following - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat After looking into it, writing a load balancer in Java will only cause the load balancer to become a bottleneck nothing else, Java doesn't offer enough low level to be able to do TCP load balancing well. Well, the typical bottleneck in a dynamic application isn't TCP bandwidth/connections, but the CPU power required to process requests. I think a TCP load balancer would be useful for a large number of people, but may not belong to the Tomcat project unless it is designed specifically to integrate with Tomcat. This may be the case anyway as the load balancer would have to match the jvmRoute with the appropriate container. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [next] What's next ?
-Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 12:06 PM To: Tomcat Developers List Subject: Re: [next] What's next ? Shapira, Yoav wrote: Howdy, I think this kind of classloading structure can be configured in TC 5 using the catalina.properties. If it can be achieved via configuration, I'm happy ;) How can it be done? You can set empty contents to the repositories list in catalina.properties, and then move whatever is required to common/endorsed. The CL ierarchy will still exist (but they won't contain anything). Will I be able to drop my own libraries in /common/endorsed to be used as the /common/lib is today? per the other thread, native libraries will not work in /WEB-INF/lib, so if I can put whatever I need into /common/endorsed, then that would be ok. But I thought everything in the endorsed dir would be treated as 'endorsed' libraries, or would I be able to configure that? Maybe I don't understand enough about the endorsed libraries, if I put something into /common/endorsed, that doesn't override an existing library, is it just loaded as normal? am I asking too many questions? :) Charlie Is that useful ? I don't really see how. (ex: if you have no loader for a webapp, it won't work) I think you should elaborate more. I suggested that one in order to simply supporting users. The less stuff that happens behind the scenes as far as configuration, the better. It should all be visible, so that on the user mailing list we can say this happens because line XXX of server.xml you have this string. Contrast with as part of tomcat's default context initialization, the property gets assigned this default value, which you can override by adding this element to server.xml, see config reference here. The more users can see by themselves by inspecting server.xml, the better IMHO. Possibly :) It's a bit hard to answer. The more XML is needed, the more intimidating it looks. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Form login page doesn't show up for custom authenticator?
Dear all,
I had a wierd problem working with my own authenticator. The form login
page did not appear at all but I got an error message stating
Configuration error: Cannot perform access control without an authenticated
principal. By checking the log file, I understood how this error was
triggered but still could not solve it.
Since the login page did not appear, I had no chance to invoke
j_security_check (by clicking the submit button). Consequently the request url
did not end with the string j_security_check. Somewhere in the
program, the following check thus failed.
// Is this the action request from the login page?
boolean loginAction =
requestURI.startsWith(contextPath)
requestURI.endsWith(Constants.FORM_ACTION);
// No -- Save this request and redirect to the form login page
if (!loginAction) {
session = getSession(request, true);
if (debug = 1)
log(Save request in session ' + session.getId() +
');
saveRequest(request, session);
if (debug = 1)
log(Redirect to login page ' + loginURI + ');
hres.sendRedirect(hres.encodeRedirectURL(loginURI));
return (false);
}
So I was redirected to the login page (again it did not appear at all).
This time the following check succeeded:
// Is this a request for the login page itself? Test here to avoid
// displaying it twice (from the user's perspective) -- once
because
// of the save and redirect and once because of the restore
and
// redirect performed below.
String loginURI = contextPath + config.getLoginPage();
if (requestURI.equals(loginURI)) {
if (debug = 1)
log(Requesting login page normally);
return (true); // Display the login page in the usual
manner
}
I think this code assumes I have been already authenticated. That's why
finally I got the error.
My questions are:
1. When should the login page appear? I think it should appear before
the call of the corresponding authenticator, am I right?
2. Is there some special configuration to bring up the login page for
user's custom authenticator?
Any suggestions or hints would be greatly appreciated.
-
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
RE: Logging filter (was RE: [next] What's next ?)
Howdy, Thanks for the response wrapper idea and skeleton -- that seems to solve most of the problems we discussed. For access logging in particular, I'd be concerned about a couple of things: * Filters don't see every request (for example, the authentication challenges when you're using BASIC authentication). This is a problem. I also think until servlet spec 2.4, filters don't see requests from request dispatchers, right? How can we get around this, if at all possible, with a portable filter? * Filters only see the requests for their particular webapp. It also just occurred to me that a legitimate, common use-case of these access logs is for broken link analysis. Having the filter just for the webapp would miss out on all requests outside the webapp like you say. Even if there's only one webapp installed on the server, you'd still miss out on broken links. * Filters require the webapp to be configured itself to enable them, versus the current approach where access logging is a container configuration issue. True, and there's the role separation idea between developer delivering the webapp and deployer/sysadmin controlling the server. The current Valve implementation nicely separates those human roles, which my Filter idea would kind of break... Yoav Shapira 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: problems with ant download
On Thu, 02 Oct 2003 16:02:53 +0200 jean-frederic clere [EMAIL PROTECTED] wrote: Yes, but not... http://jakarta.apache.org/builds/jakarta-struts/release/v1.1/jakarta-struts-1.0.2.tar.gz must be changed into: http://www.apache.org/dyn/closer.cgi/jakarta/struts/binaries/jakarta-struts-1.1.tar.gz The change from 1.0.2 to 1.1 is impossible but the interesting would be to have cgi that redirects to the result of closer.cgi instead displaying it. Okeydokey. Should we ask infrastructure? I think no (i am afraid infra team can do nothing :-). I fixed some. Please $ cat /x1/www/jakarta.apache.org/builds/jakarta-struts/.htaccess and confirm. -- Also, please note that the directory, /www/www.apache.org/dist/jakarta/ would be resync-ed everyday into mirrored-sites and /www/archive.apache.org/dist/jakarta/ (without *delete*). Once you put something, they won't be deleted @ mirrored and archive.apache.org sites. hope this helps. -- Tetsuya. ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23582] New: - Cannot build Tomcat 5.0.12 because jakarta-commons/daemon does not exist
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=23582. 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=23582 Cannot build Tomcat 5.0.12 because jakarta-commons/daemon does not exist Summary: Cannot build Tomcat 5.0.12 because jakarta- commons/daemon does not exist Product: Tomcat 5 Version: 5.0.12 Platform: PC OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When trying to install Tomcat with methods from http://jakarta.apache.org/tomcat/tomcat-5.0-doc/building.html installations fails with: build-commons-daemon: [echo] == Building: commons-daemon BUILD FAILED /server/install/jakarta-tomcat-5.0.12-src/src/jakarta-tomcat-5/build.xml:482: Basedir /server/install/jakarta-tomcat-5.0.12-src/src/jakarta-commons/daemon does not exist Total time: 6 seconds I found http://www.mail-archive.com/[EMAIL PROTECTED]/msg45445.html confirming this bug, but i cannot admit it's firewall-only bug. Server on which i'm installing it is not behind firewall. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
An AccessLogFilter will not work since the filter is only valid for a single webapplication. If you wish to log all requests for a server (or Host) to the same log file, you could in theory have multiple Filters running at the same time, one for each webapp - but I'd hate to see the messy file locking and synchronization involved. -Tim Shapira, Yoav wrote: 1. Convert AccessLogValve to be a servlet specification 2.3 filter, i.e. something portable. We can define it in $CATALINA_HOME/conf/web.xml, commented out by default perhaps, and users can move the definition around as they need just like they do with the servlets defined conf/web.xml. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Schedule change
Hans/Remy, I don't know more than you do about when J2EE 1.4 will be released, but the specs are starting to move through final approval now, so I'm pretty sure it will happen in a month or two. Three months for running a few Beta releases instead of releasing it as something it's not doesn't seem to bad to me ... Sun expects to ship J2EE 1.4 FCS sometime around the last week of November. Hope this helps. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session StandardSession.java
jfarcand2003/10/02 18:53:17
Modified:catalina/src/share/org/apache/catalina/session
StandardSession.java
Log:
We also need to call the listener when the session is invalidated because we can't
predict the interval between the time the session is marked invalid and the
StandardrMmanager expires the session.
Revision ChangesPath
1.24 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
Index: StandardSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- StandardSession.java 2 Oct 2003 17:10:54 - 1.23
+++ StandardSession.java 3 Oct 2003 01:53:17 - 1.24
@@ -587,7 +587,7 @@
long timeNow = System.currentTimeMillis();
int timeIdle = (int) ((timeNow - lastAccessedTime) / 1000L);
if (timeIdle = maxInactiveInterval) {
-this.isValid = false;
+expire(true);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Newsletter Draft] News as to Jakarta Tomcat Project from Aug. to Sep.
Dear Jakarta Tomcat Development Team, (http://jakarta.apache.org/tomcat/) Hello, Apache newsletter is in progress of preparing the second all-Apache newsletter, news from August to September 2003, which will be published in the middle of October 2003. === What is The Apache Newsletter? === http://www.apache.org/newsletter/ the 'Apache Newsletter Issue 2' will be appeared at http://www.apache.org/newsletter/200309.html and the editorial deadline will be 00:00 GMT-7000, 11th October. We lowered the barrier to entry - anyone will be able to easily contribute, as prepared the ApacheWiki (http://nagoya.apache.org/wiki/apachewiki.cgi). If you have anything to be added to the ApacheWiki, please go to http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue2 and fill up what you want to append. (A few editors per (sub)project would be highly appreciated, indeed) Of course, if you do have a hesitation on writing article via Wiki, please send e-mails to me [EMAIL PROTECTED] directly. Probably, the former newsletter (Apache Newsletter Issue #1) might be able to give you some hints in writing the articles. cf. http://www.apache.org/newsletter/200307.html I am waiting your contributions. Please e-mail to me [EMAIL PROTECTED] whensoever you have a question about this newsletter. Hope to hear from you Sincerely, -- Tetsuya Kitahata ([EMAIL PROTECTED]) - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ (The Apache Newsletter Issuer/Editor) http://www.apache.org/newsletter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
Jean-Francois Arcand wrote: I would be interested to: - implement jsr115 as an optional feature (based on a previous discussion with Costin on this thread (that may bring Costing back :-) ). - turn SecurityManager on by default ( already proposed by Costin sometime ago if I remember). Turning the security manager on by default would be a very good idea. As for Costin coming back - not in the next few months, I have far too much work ( and a bit of fun ). I do have some ideas and I learned _a_lot_ in the last months, but until the project gets in a stable state I won't be able to do more than read the list and post from time to time. Costin - improve xml parsing performance (may found that the problem is with my favorite parser ;-) ) -- Jeanfrancois Remy Maucherat wrote: Usually, when a Tomcat branch nears its release, a new branch is created. However, I only have a few feature ideas that make some sense, and the problem is that they are minor evolutions (hence, they could perfectly fit inside the 5.0 branch). This includes: - Updating JK2 to use the JMX events (the same ones the mapper uses) to get autoconfiguration, as an option. That seems useful, but it might well be a really stupid thing in the real world. - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat. - Use an in memory Java compiler to be able to automatically precompile webapps upon deployment. I heard such a compiler now exists, and this could be added fairly easily if it works well enough. I'm not a very big fan, but maybe it would make sense for some people. So to summarize, I have nothing to propose (sorry), and will focus on bugfixes and small additions in the 5.0 branch. If people want to see something more radical happen for the next major release, it's probably time to come up with proposals :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
billbarker2003/10/02 22:49:48
Modified:.build.xml
Log:
Commons-daemon lives in commons-daemon.home by definition.
Don't hack around with presumed locations for it.
Revision ChangesPath
1.162 +2 -2 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.161
retrieving revision 1.162
diff -u -r1.161 -r1.162
--- build.xml 29 Sep 2003 10:27:40 - 1.161
+++ build.xml 3 Oct 2003 05:49:48 - 1.162
@@ -119,7 +119,7 @@
uptodate property=commons-daemon.build.notrequired
targetfile=${commons-daemon.jar}
- srcfiles dir=${cvs.base}/jakarta-commons/daemon/src includes=** /
+ srcfiles dir=${commons-daemon.home}/src includes=** /
/uptodate
/target
@@ -479,7 +479,7 @@
target name=build-commons-daemon unless=commons-daemon.build.notrequired
description=build commons-daemon
echo== Building: commons-daemon /echo
-ant dir=${cvs.base}/jakarta-commons/daemon target=dist
+ant dir=${commons-daemon.home} target=dist
property name=compile.optimize value=false /
property name=dist.home value=${commons-daemon.home} /
/ant
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
billbarker2003/10/02 22:58:08
Modified:.build.xml
Log:
Missed one.
Revision ChangesPath
1.163 +1 -1 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.162
retrieving revision 1.163
diff -u -r1.162 -r1.163
--- build.xml 3 Oct 2003 05:49:48 - 1.162
+++ build.xml 3 Oct 2003 05:58:08 - 1.163
@@ -1698,7 +1698,7 @@
command=checkout -P ${cvstag} jakarta-servletapi-5
dest=${cvs.base}/
cvs cvsroot=${cvsroot} quiet=true
- command=checkout -P ${cvstag} ${commons-daemon.cvs.loc}
+ command=checkout -P ${cvstag} -d ${commons-daemon.home}
${commons-daemon.cvs.loc}
dest=${cvs.base}/
!--
cvs cvsroot=${cvsroot} quiet=true
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
