mod_jk.so on Solaris
Hi, How can I make mod_jk.so (or mod_jserv.so) on Solaris 7 ? Thanks in advance, Kim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Servlet ClassLoader
Am I just screwed or is there some cool trick that I am missing? As far as I know, this is not possible. I have another question, which has been nagging me for a while: Why does the class loader for a web-app "see" the classes in the lib folder of the servlet engine (or the classpath of the java engine). For example if a servlet engine is using an XML parser (say Xerces, some old version like 1.0.x) and includes the SAX and DOM interfaces, but only version/level 1. Now my cool web-app wants to use Xerces 1.3.0 and take advantage of the new version/level 2 of the interfaces, I have to fiddle with the lib folder of the servlet engine (something I don't want to do), and even in this example I'm doomed, because interface changes in Xerces between these two versions make them incompatible! (I know Tomcat does not use Xerces, this was just a fictious example) Now I pose the same question as Arthur Ash: Am I just screwed or is there some cool trick that I am missing? If I'm right about the problem I suggest separating the classloaders for the servlet engine on one hand, and the web-apps on the other hand, using a common classloader for the servlet interface and other common servlet stuff. Is this possible? Regards, Gummi Haf
RE: Servlet ClassLoader
I hope you don't mind me answering your e-mail to the list, I think this deserves some discussion. This is exactly what we've been doing, but it requires fiddling with the libs of the servlet engine, something I don't want to do! I want to be able to separate the libs of the servlet engine from the libs of my web-app, is it possible? The whole idea behind web-apps collapses if the deployer needs to do some exercises with the jars of the servlet engine! Gummi Haf From: Jim Rudnicki [mailto:[EMAIL PROTECTED]] You can do it, but it requires great care. The answer is to separate out the XML jars. Notably, open tomcats jar's and remove the old org.w3c interfaces. Place the newer org.w3c stuff in a separate jar in the tomcat lib folder. The above will do what you asked because the new interfaces are backwards compatible (almost beware Xerces 1.3.2). Similar problems exist and are solved the same way. For example, the Xerces distribution from Enhydra contains their copy of the sun.jaxp classes. I had to open their jar, strip out sun.jaxp, and org.w3c and rejar the seperate parts. Now with three jars: EnXerces.jar, EnW3c.jar, and EnJaxp.jar you can mix and match. good luck, you'll need it Jim
[REPOST] Using Xerces in my Application
I posted this about a week ago with no luck. Anybody care to comment? I'm trying to use Xerces in my web application. To do this I put the jar file into WEB-INF/lib. However whenever I try and parse any XML I get a 'sealing' exception. I've just read the recent thread on this and it implies that I can only have one XML parser within Tomcat, or at least that if the class names clash (which they will) things may not work as expected. Can I use Xerces either alongside Crimson? If so, where do I put it. It doesn't work in WEB-INF/lib and only works in tomcat/lib as a replacement for crimson. Reading the sealing discussion I get the impression that using Xerces should be OK as long as the class loader doesn't try and use two classes with the same name from different jars, (or am I way off the mark here?). So shouldn't xerces become the 'default' XML parser for my application? What if I want to use a different parser (such as Oracle's) will it work (I haven't tried this BTW)? Kevin Jones DevelopMentor www.develop.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #723 - Escaped URL's are not recognized by Tomcat
Report #723 Details Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2 JVM Release: Java 2 SDK 1.3 Operating System: NT 4 OS Release: service pack 5 Platform: Windows NT Synopsis: Escaped URL's are not recognized by Tomcat Description: Spaces in URL's and URI's should use an escaped encoding. See http://www.ietf.org/rfc/rfc2396.txt For example, "%20" is the escaped encoding for the US-ASCII space character. When a URL is escaped correcty, It is recognized by MS IIS server. But Tomcat is unable to load the page. Example: http://localhost/uniface/copy%20of%20grapha.gif Loaded by IIS but The url http://localhost:8080/uniface/copy%20of%20grapha.gif Gives an error with Tomcat. Title: BugRat Report # 723 BugRat Report # 723 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: jasper de keijzer ([EMAIL PROTECTED]) Date Submitted: Jan 9 2001, 06:39:21 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Escaped URL's are not recognized by Tomcat Environment: (jvm, os, osrel, platform) Java 2 SDK 1.3, NT 4, service pack 5, Windows NT Additional Environment Description: Report Description: Spaces in URL's and URI's should use an escaped encoding. See http://www.ietf.org/rfc/rfc2396.txt For example, "%20" is the escaped encoding for the US-ASCII space character. When a URL is escaped correcty, It is recognized by MS IIS server. But Tomcat is unable to load the page. Example: http://localhost/uniface/copy%20of%20grapha.gif Loaded by IIS but The url http://localhost:8080/uniface/copy%20of%20grapha.gif Gives an error with Tomcat. How To Reproduce: Workaround: View this Report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] for NetWare
Mike, I just tried to apply your fixes, and I'm totally failing -- the local diff command isn't recognizing the files as being at all similar (despite the fact that they look similar on visual inspection). I have a *very* strong suspicion that this has to do with line-ending characters. It looks like you are using a non-Unix system, which I am going to guess has a different convention for line-endings. The cvs client will magically fix this when you check files out and check them in (i.e. it translates non-Unix to Unix conventions transparently). So a 'cvs diff -u' should probably work, but, when you email me your checked out copy, it's got non-Unix line endings, so when I try to diff it against the copy I've checked out on my Linux box, diff thinks that every line is different. Short version: can you email me patches generated from 'cvs diff -u'? I'm fairly certain I can get those to work. Thanks, -Dan -- Dan Milstein // [EMAIL PROTECTED] Mike Anderson wrote: Attached are some patched files and a diff file for NetWare. These have been diffed against the latest version in the jakarta-tomcat tree. The jk_util.c and jk_nsapi_plugin.c are the same fixes that have been put into the tomcat-32 branch and I will submit the ApacheConf.java to the tomcat-32 branch as well. diff.txt - diffs of the files jk_util.c - Fixes a problem when shutting down the webserver on NetWare. The exit thread only has a 16k stack so we dynamically allocate the log buffer so that we don't blow the stack. jk_nsapi_plugin.c - Fixes a problem with the netbuf_getbytes function not being available on NetWare 5.x. ApacheConfig.java - Updated to write a correct mod_jk.conf-auto for NetWare. Thanks Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com diff.txtName: diff.txt Type: Plain Text (text/plain) Name: jk_util.c jk_util.cType: unspecified type (application/octet-stream) Encoding: base64 Name: jk_nsapi_plugin.c jk_nsapi_plugin.cType: unspecified type (application/octet-stream) Encoding: base64 Name: ApacheConfig.java ApacheConfig.javaType: unspecified type (application/octet-stream) Encoding: base64 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/admin/WEB-INF/classes/tadm AntTag.java
costin 01/02/02 08:07:53
Modified:src/admin/WEB-INF/classes/tadm AntTag.java
Log:
JDK1.1, again. Thanks to nightly :-)
Revision ChangesPath
1.3 +1 -1 jakarta-tomcat/src/admin/WEB-INF/classes/tadm/AntTag.java
Index: AntTag.java
===
RCS file: /home/cvs/jakarta-tomcat/src/admin/WEB-INF/classes/tadm/AntTag.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AntTag.java 2001/02/01 04:43:48 1.2
+++ AntTag.java 2001/02/02 16:07:52 1.3
@@ -68,7 +68,7 @@
}
public void setDebug( String s ) {
- args.setProperty( "debug", s);
+ args.put( "debug", s);
}
// Implementation methods
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] for NetWare
You can use : cat patch | tr -d '\015' patch.nodos will remove the dreaded CR On ne peut rsoudre les problmes les plus graves avec le mme esprit qui les a cres. -- Albert Einstein -Original Message- From: Dan Milstein [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 5:01 PM To: [EMAIL PROTECTED]; Mike Anderson Subject: Re: [PATCH] for NetWare Mike, I just tried to apply your fixes, and I'm totally failing -- the local diff command isn't recognizing the files as being at all similar (despite the fact that they look similar on visual inspection). I have a *very* strong suspicion that this has to do with line-ending characters. It looks like you are using a non-Unix system, which I am going to guess has a different convention for line-endings. The cvs client will magically fix this when you check files out and check them in (i.e. it translates non-Unix to Unix conventions transparently). So a 'cvs diff -u' should probably work, but, when you email me your checked out copy, it's got non-Unix line endings, so when I try to diff it against the copy I've checked out on my Linux box, diff thinks that every line is different. Short version: can you email me patches generated from 'cvs diff -u'? I'm fairly certain I can get those to work. Thanks, -Dan -- Dan Milstein // [EMAIL PROTECTED] Mike Anderson wrote: Attached are some patched files and a diff file for NetWare. These have been diffed against the latest version in the jakarta-tomcat tree. The jk_util.c and jk_nsapi_plugin.c are the same fixes that have been put into the tomcat-32 branch and I will submit the ApacheConf.java to the tomcat-32 branch as well. diff.txt - diffs of the files jk_util.c - Fixes a problem when shutting down the webserver on NetWare. The exit thread only has a 16k stack so we dynamically allocate the log buffer so that we don't blow the stack. jk_nsapi_plugin.c - Fixes a problem with the netbuf_getbytes function not being available on NetWare 5.x. ApacheConfig.java - Updated to write a correct mod_jk.conf-auto for NetWare. Thanks Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com --- - diff.txtName: diff.txt Type: Plain Text (text/plain) Name: jk_util.c jk_util.cType: unspecified type (application/octet-stream) Encoding: base64 Name: jk_nsapi_plugin.c jk_nsapi_plugin.cType: unspecified type (application/octet-stream) Encoding: base64 Name: ApacheConfig.java ApacheConfig.javaType: unspecified type (application/octet-stream) Encoding: base64 --- - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Problems with mod_jk.so, RH7.0, binary/compiled
It seems that Jyve didn't update the Q/A allready. You could see here the text: What's are the message about EAPI or garbled modules ? The message 'mod_jk.so (or mod_jserv.so) is garbled - perhaps this is not an Apache module DSO ?' arrive when you're trying to install a mod_jk.so DSO module that was compiled on an Apache using EAPI, like apache-mod_ssl or apache from Redhat distro 6.2/7.0 and your system use the standard apache API. EAPI are extensions to standard Apache API (and used at least by mod_ssl). On the contrary, if you received the message '[warn] Loaded DSO /usr/lib/apache/mod_jk.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)', you're just in the reverse situation. The mod_jk.so (or mod_jserv.so) was compiled under normal Apache with standard API and you try to install the module on an Apache using EAPI. It's wise to avoid using EAPI modules on STD API Apache or to use standard API modules on EAPI Apache. Allways be sure to have the mod_jk.so / mod_jserv.so for your version of Apache On ne peut rsoudre les problmes les plus graves avec le mme esprit qui les a cres. -- Albert Einstein -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 4:30 PM To: [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Cc: [EMAIL PROTECTED] Subject: RE: Problems with mod_jk.so, RH7.0, binary/compiled Added to FAQOMATIC, finalement :-) http://jakarta.apache.org/jyve-faq/Turbine/screen/DisplayQuesti onAnswer/acti on/SetAll/project_id/2/faq_id/12/topic_id/42/question_id/762 All the RPMs present on jakarta.apache.org are compiled under Linux Redhat 6.2 and the Apache is so a apache with EAPI (since using mod_ssl). I'll try to release the next days, mod_jk.so and mod_jserv.so for use on standard Apache under Linux i386. The naming will be : mod_jk.so.eapi mod_jserv_tomcat.so.eapi mod_jk.so.stdapi mod_jserv_tomcat.so.stdapi Ok ? On ne peut rsoudre les problmes les plus graves avec le mme esprit qui les a cres. -- Albert Einstein -Original Message- From: Wise, Bowden (CRD) [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 3:58 PM To: '[EMAIL PROTECTED]' Cc: 'tomcat-user' Subject: RE: Problems with mod_jk.so, RH7.0, binary/compiled Hey J I am stuck where you are. I was trying to use the mod_jserv_tomcat.so that you can download. My configuration is RedHat 6.2 on a Dell PC. And I get that same /usr/local/apache/libexec/mod_jserv_tomcat.so is garbled - perhaps this is not an Apache module DSO? So are those binaries for RedHat 7? I also tried compiling but apxs gives me fits: apxs:Error: @sbindir@/httpd not found or not executable Any ideas? Thanks Bowden -Original Message- From: Juan Julian Merelo Guervos [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 5:57 AM To: [EMAIL PROTECTED] Subject: Problems with mod_jk.so, RH7.0, binary/compiled Hi, I haven't been able to install mod_jk.so with Apache 1.3.17. I have downloaded the mod_jk.so binary from the jakarta site, and I get this error: Syntax error on line 8 of /usr/local/jakarta-tomcat-3.2.1/conf/mod_jk.conf-auto: API module structure `jk_module' in file /usr/local/apache/libexec/mod_jk.so is garbled - perhaps this is not an Apache module DSO? OK, good, I thought, that must be the weird RH7.0 file format or whatever. Let's compile it natively. I downloaded source, and compiled it. Guess what I got? Syntax error on line 8 of /usr/local/jakarta-tomcat-3.2.1/conf/mod_jk.conf-auto: API module structure `jk_module' in file /usr/local/apache/libexec/mod_jk.so is garbled - perhaps this is not an Apache module DSO? What's the problem here? Any help? J -- [EMAIL PROTECTED] | [EMAIL PROTECTED] JJ Merelo | http://geneura.ugr.es/~jmerelo Grupo Geneura Univ. Granada | http://www.geneura.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Tomcat 3.3 Release Plan
Tomcat 3.3 Release Plan Ballot: [ ] +1 I am in favor of this plan and will help [X] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1 I am against this plan being executed, and my reason is: I would be +1 but work deadlines may prevent me from devoting much time on this right now. I'll do what I can. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/native/jk jk_sockbuf.c
danmil 01/02/02 08:55:36
Modified:src/native/jk Tag: tomcat_32 jk_sockbuf.c
Log:
Fixed bug which was sending mod_jk into infinite loop if the tomcat
connector closed its ajp connection to mod_jk before sending the
header. Bugzilla Report #510.
Contributed by Brian Vetter ([EMAIL PROTECTED]).
Revision ChangesPath
No revision
No revision
1.1.2.2 +43 -21jakarta-tomcat/src/native/jk/Attic/jk_sockbuf.c
Index: jk_sockbuf.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/jk/Attic/jk_sockbuf.c,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- jk_sockbuf.c 2000/09/13 23:06:27 1.1.2.1
+++ jk_sockbuf.c 2001/02/02 16:55:34 1.1.2.2
@@ -56,7 +56,7 @@
/***
* Description: Simple buffer object to handle buffered socket IO *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.1.2.1 $ *
+ * Version: $Revision: 1.1.2.2 $ *
***/
#include "jk_global.h"
@@ -90,7 +90,7 @@
return JK_FALSE;
}
if(sz SOCKBUF_SIZE) {
-return (send(sb-sd, (char *)buf, sz, 0) == (int)sz);
+return (send(sb-sd, buf, sz, 0) == (int)sz);
}
memcpy(sb-buf + sb-end, buf, sz);
@@ -131,7 +131,7 @@
if(sb-end == sb-start) {
sb-end = sb-start = 0;
-if(!fill_buffer(sb)) {
+if(fill_buffer(sb) 0) {
return JK_FALSE;
}
}
@@ -154,6 +154,7 @@
int jk_sb_gets(jk_sockbuf_t *sb,
char **ps)
{
+int ret;
if(sb) {
while(1) {
unsigned i;
@@ -169,8 +170,16 @@
return JK_TRUE;
}
}
-if(!fill_buffer(sb)) {
+if((ret = fill_buffer(sb)) 0) {
return JK_FALSE;
+} else if (ret == 0) {
+*ps = sb-buf + sb-start;
+ if ((SOCKBUF_SIZE - sb-end) 0) {
+sb-buf[sb-end] = '\0';
+} else {
+sb-buf[sb-end-1] = '\0';
+}
+return JK_TRUE;
}
}
}
@@ -178,13 +187,19 @@
return JK_FALSE;
}
+/*
+ * Read data from the socket into the associated buffer, and update the
+ * start and end indices. May move the data currently in the buffer. If
+ * new data is read into the buffer (or if it is already full), returns 1.
+ * If EOF is received on the socket, returns 0. In case of error returns
+ * -1.
+ */
static int fill_buffer(jk_sockbuf_t *sb)
{
int ret;
-
+
/*
- * First move the current data to the beginning of the
- * buffer
+ * First move the current data to the beginning of the buffer
*/
if(sb-start sb-end) {
if(sb-start 0) {
@@ -196,19 +211,26 @@
} else {
sb-start = sb-end = 0;
}
-
+
/*
- * Now, read more data
+ * In the unlikely case where the buffer is already full, we won't be
+ * reading anything and we'd be calling recv with a 0 count.
*/
-ret = recv(sb-sd,
- sb-buf + sb-end,
- SOCKBUF_SIZE - sb-end, 0);
-
-if(ret 0) {
-return JK_FALSE;
-}
-
-sb-end += ret;
-
-return JK_TRUE;
-}
\ No newline at end of file
+if ((SOCKBUF_SIZE - sb-end) 0) {
+ /*
+ * Now, read more data
+ */
+ ret = recv(sb-sd,
+sb-buf + sb-end,
+SOCKBUF_SIZE - sb-end, 0);
+
+ // 0 is EOF/SHUTDOWN, -1 is SOCK_ERROR
+ if (ret = 0) {
+ return ret;
+ }
+
+ sb-end += ret;
+}
+
+return 1;
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_sockbuf.c
danmil 01/02/02 08:59:07
Modified:src/native/mod_jk/common jk_sockbuf.c
Log:
Fixed bug which was sending mod_jk into infinite loop if the tomcat
connector closed its ajp connection to mod_jk before sending the
header. Bugzilla Report #510.
Contributed by Brian Vetter ([EMAIL PROTECTED]).
Revision ChangesPath
1.3 +43 -21jakarta-tomcat/src/native/mod_jk/common/jk_sockbuf.c
Index: jk_sockbuf.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_sockbuf.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- jk_sockbuf.c 2000/11/10 18:48:50 1.2
+++ jk_sockbuf.c 2001/02/02 16:59:06 1.3
@@ -56,7 +56,7 @@
/***
* Description: Simple buffer object to handle buffered socket IO *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.2 $ *
+ * Version: $Revision: 1.3 $ *
***/
#include "jk_global.h"
@@ -90,7 +90,7 @@
return JK_FALSE;
}
if(sz SOCKBUF_SIZE) {
-return (send(sb-sd, (char *)buf, sz, 0) == (int)sz);
+return (send(sb-sd, buf, sz, 0) == (int)sz);
}
memcpy(sb-buf + sb-end, buf, sz);
@@ -131,7 +131,7 @@
if(sb-end == sb-start) {
sb-end = sb-start = 0;
-if(!fill_buffer(sb)) {
+if(fill_buffer(sb) 0) {
return JK_FALSE;
}
}
@@ -154,6 +154,7 @@
int jk_sb_gets(jk_sockbuf_t *sb,
char **ps)
{
+int ret;
if(sb) {
while(1) {
unsigned i;
@@ -169,8 +170,16 @@
return JK_TRUE;
}
}
-if(!fill_buffer(sb)) {
+if((ret = fill_buffer(sb)) 0) {
return JK_FALSE;
+} else if (ret == 0) {
+*ps = sb-buf + sb-start;
+ if ((SOCKBUF_SIZE - sb-end) 0) {
+sb-buf[sb-end] = '\0';
+} else {
+sb-buf[sb-end-1] = '\0';
+}
+return JK_TRUE;
}
}
}
@@ -178,13 +187,19 @@
return JK_FALSE;
}
+/*
+ * Read data from the socket into the associated buffer, and update the
+ * start and end indices. May move the data currently in the buffer. If
+ * new data is read into the buffer (or if it is already full), returns 1.
+ * If EOF is received on the socket, returns 0. In case of error returns
+ * -1.
+ */
static int fill_buffer(jk_sockbuf_t *sb)
{
int ret;
-
+
/*
- * First move the current data to the beginning of the
- * buffer
+ * First move the current data to the beginning of the buffer
*/
if(sb-start sb-end) {
if(sb-start 0) {
@@ -196,19 +211,26 @@
} else {
sb-start = sb-end = 0;
}
-
+
/*
- * Now, read more data
+ * In the unlikely case where the buffer is already full, we won't be
+ * reading anything and we'd be calling recv with a 0 count.
*/
-ret = recv(sb-sd,
- sb-buf + sb-end,
- SOCKBUF_SIZE - sb-end, 0);
-
-if(ret 0) {
-return JK_FALSE;
-}
-
-sb-end += ret;
-
-return JK_TRUE;
-}
\ No newline at end of file
+if ((SOCKBUF_SIZE - sb-end) 0) {
+ /*
+ * Now, read more data
+ */
+ ret = recv(sb-sd,
+sb-buf + sb-end,
+SOCKBUF_SIZE - sb-end, 0);
+
+ // 0 is EOF/SHUTDOWN, -1 is SOCK_ERROR
+ if (ret = 0) {
+ return ret;
+ }
+
+ sb-end += ret;
+}
+
+return 1;
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Cutoff for Tomcat 3.3 Vote
Hi All, I plan to use (as suggested by Sam Ruby) Monday 8:00 AM EST as the deadline for the Tomcat 3.3 Release Plan vote. That should be enough time for any remaining interested parties to cast a vote. I'll post the final results Monday morning. Cheers, Larry __ Larry Isaacs [EMAIL PROTECTED] SAS Institute Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
3.2.2 Release?
There was some discussion about producing a 3.2.2 release at some point soonish. Where is that now? People have contributed some excellent fixes in the connector area, and I would love to see those available to the general public. I'm not in a position to function as the Release Manager, but I can help collect info about what fixes have been made in the mod_jk/connector area. -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: 3.2.2 Release?
I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way too busy right now to manage a release. -Original Message- From: danmil [mailto:danmil]On Behalf Of Dan Milstein Sent: Friday, February 02, 2001 11:24 AM To: [EMAIL PROTECTED] Subject: 3.2.2 Release? There was some discussion about producing a 3.2.2 release at some point soonish. Where is that now? People have contributed some excellent fixes in the connector area, and I would love to see those available to the general public. I'm not in a position to function as the Release Manager, but I can help collect info about what fixes have been made in the mod_jk/connector area. -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
keith 01/02/02 08:41:53
Modified:src/share/org/apache/tomcat/modules/server Ajp13.java
Log:
It may take multiple read() calls to read an entire packet,
especially w.r.t. uploaded files.
Revision ChangesPath
1.11 +12 -9
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java
Index: Ajp13.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Ajp13.java2001/01/30 04:13:14 1.10
+++ Ajp13.java2001/02/02 16:41:52 1.11
@@ -632,16 +632,19 @@
int len = msg.checkIn();
// XXX check if enough space - it's assert()-ed !!!
- // Can we have only one read ( with unblocking, it can read all at once - but
maybe more ) ?
-
- rd = in.read( b, 4, len );
- if( rd != len ) {
- System.out.println( "Incomplete read, deal with it " + len + " " + rd);
- // XXX log
- // XXX Return an error code?
+
+ int total_read = 0;
+ while (total_read len) {
+ rd = in.read( b, 4 + total_read, len - total_read);
+if (rd == -1) {
+ System.out.println( "Incomplete read, deal with it " + len + " " + rd);
+break;
+ // XXX log
+ // XXX Return an error code?
+ }
+ total_read += rd;
}
- // msg.dump( "Incoming");
- return rd;
+ return total_read;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_ajp13_worker.c jk_service.h jk_util.c
keith 01/02/02 09:29:09
Modified:src/native/mod_jk/apache1.3 mod_jk.c
src/native/mod_jk/common jk_ajp13_worker.c jk_service.h
jk_util.c
Log:
Unread body bits need to be discarded or Apache will consider
them a new request. (cf jserv_ajpv12.c:689) Fix by adding a
field to track how much of the body was actually sent.
This may need to be added to the Apache 2.0 connector.
Revision ChangesPath
1.4 +10 -0 jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- mod_jk.c 2001/01/28 21:46:00 1.3
+++ mod_jk.c 2001/02/02 17:28:47 1.4
@@ -718,6 +718,16 @@
l,
is_recoverable_error);
+if (s.content_read s.content_length) {
+ /* Toss all further characters left to read fm client */
+ char *buff = ap_palloc(r-pool, 2048);
+ if (buff != NULL) {
+ int rd;
+ while ((rd = ap_get_client_block(r, buff, 2048)) 0) {
+ s.content_read += rd;
+ }
+ }
+ }
end-done(end, l);
}
}
1.4 +3 -1 jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c
Index: jk_ajp13_worker.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jk_ajp13_worker.c 2001/01/11 02:36:14 1.3
+++ jk_ajp13_worker.c 2001/02/02 17:29:03 1.4
@@ -57,7 +57,7 @@
* Description: Experimental bi-directionl protocol. *
* Author: Costin [EMAIL PROTECTED] *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.3 $ *
+ * Version: $Revision: 1.4 $ *
***/
#include "jk_pool.h"
@@ -344,6 +344,7 @@
}
if(read_into_msg_buff(ep, r, msg, l, len)) {
+ r-content_read += len;
return JK_AJP13_HAS_RESPONSE;
}
@@ -604,6 +605,7 @@
if(!read_into_msg_buff(p, s, msg, l, len)) {
return JK_FALSE;
}
+s-content_read = len;
if(!connection_tcp_send_message(p, msg, l)) {
jk_log(l, JK_LOG_ERROR,
"Error sending request body\n");
1.3 +1 -0 jakarta-tomcat/src/native/mod_jk/common/jk_service.h
Index: jk_service.h
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_service.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- jk_service.h 2000/11/10 18:48:50 1.2
+++ jk_service.h 2001/02/02 17:29:04 1.3
@@ -58,7 +58,7 @@
* These are the web server (ws) the worker and the connection*
* JVM connection point *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.2 $ *
+ * Version: $Revision: 1.3 $ *
***/
#ifndef JK_SERVICE_H
@@ -104,6 +104,7 @@
char*server_software;
unsigned content_length;/* integer that represents the content */
/* length should be 0 if unknown.*/
+unsigned content_read;
/*
* SSL information
1.3 +2 -1 jakarta-tomcat/src/native/mod_jk/common/jk_util.c
Index: jk_util.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_util.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- jk_util.c 2000/11/10 18:48:50 1.2
+++ jk_util.c 2001/02/02 17:29:05 1.3
@@ -56,7 +56,7 @@
/***
* Description: Utility functions (mainly configuration)
Posting 3.3 native binaries snapshot
With all the changes to mod_jk, I'd like to post these binaries to the jakarta site: builds/jakarta-tomcat/native-3.3/linux/i386/mod_jk.so and ... /win32/i386/mod_jk.dll Any objections? These connectors won't be build nightly, but they will allow people to use the changes we've made so far. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Servlet ClassLoader
Arthur Ash wrote:
Hi Folks,
I'm having a general issue with the app-specific classpath (WEB-INF/classes
and WEB-INF/lib/*.jar).
Here is the scenario as I understand it:
I have an MVC servlet/bean framework that is installed in the primordial
classpath. It contains a single dispatcher servlet which instantiates
handler classes (which function like servlets) using Class.forName(). My
intention is to to put these app-specific handler classes in
WEB-INF/classes or WEB-INF/lib in order to be a good J2EE citizen.
The Struts framework http://jakarta.apache.org/struts follows essentially the
same model. However, due to classloader issues (more discussion below) the
controller servlet class itself must also be in WEB-INF/classes or WEB-INF/lib
for this to work correctly.
However, since the dispatch servlet has been loaded with the primordial
class loader (ie, the Tomcat code first tried and succeeded to load it
using the default class loader), when it itslef calls Class.forName(), it
gets this same (primordial) ClassLoader. It cannot see anything that is in
WEB-INF, since this is visible to only to the servlet class loader (ie,
com.apache.tomcat.loader.AdaptiveClassLoader).
Class loaders are arranged in a hierarchy. For Tomcat 4.0, the details are
discussed in a developer document ("catalina/docs/dev/classloaders.html) in the
source tree. I will use that to illustrate what's going on because I'm more
familiar with it - Tomcat 3.2 currently follows a simplified version of the
same basic idea.
Bootstrap
|
System
|
Common
/ \
Catalina Shared
/ \
Webapp1 Webapp2 ...
Each class loader has a reference to its parent, but not to its children. So,
when your controller servlet is initially loaded (from a shared library
directory), what actually happened is:
* Java asked the webapp class loader to find the
controller servlet class
* The webapp class loader did not find the class
so it delegated to the shared class loader
* The shared class loader (which reads from $CATALINA_HOME/lib
in Tomcat 4.0 -- the corresponding loader in Tomcat 3.2 reads
from the system classpath) and finds your class
Now, when your controller servlet calls Class.forName(), it starts from its
*own* class loader, and looks either there, or upwards. Of course, if your
components are under WEB-INF/classes or WEB-INF/lib, they are not visible ...
Am I just screwed or is there some cool trick that I am missing? Of course
I could change the deployment scheme to put a copy of the dispatcher
servlet into each apps WE-INF/classes, but this seems a bit clunky.
It's not clunky -- its required by virtue of the fact that classloaders know
how to delegate upwards but not downwards. For lots of security related
reasons, that is actually a Good Thing.
thanks
Arthur
Craig McClanahan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: 3.2.2 Release?
I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way too busy right now to manage a release. What about a "milestone" ? It doesn't have all the requirements of a release. I can add a nightly build of 3.2.x to my scripts too ? ( it'll not be a "blessed" release, but people who need the patches can use it ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
mod_jk static build
Just wondering if there would be any drawbacks to installin mod_jk as a static module instead of a DSO? I'd like to use it as a static module, but I thought that maybe there was a reason that a makefile was not included to build it in this manner. Before I start making my own Makefile for a static build I figured I ask the experts. thanks, -Avery S/MIME Cryptographic Signature
HTTPS Redirect/encodeURL problems (Bugzilla #269)
Within Tomcat Head / 3.3 there are a host of problems with https pages and
various url related methods (redirect, encodeURL, etc.) As Andreas
Stubenrauch notes in the above bug report, this is a very serious, show
stopper problem. What's more, he has found the source of the problem. In
org.apache.tomcat.facade.HttpServletResponseFacade.toAbsolute(String url)
There is a call to:
new URL(new URL(requrl), location)
Where requrl is a string representation of the current request, and location
is the page being encoded or redirected to. The inner URL() constructor is
going to try to obtain a URLStreamHandler for whatever scheme is associated
with the request url. However, with JDK 1.1 (and 1.2?), there is no https
URLStreamHandler included, so this throws a MalformedURLException, which
causes all the problems.
I've just done some looking around, and, unfortunately, an HTTPS
URLStreamHandler is a pretty complicated thing to come up with, and I'm not
seeing one which is available under a license by which we could include it.
We could require JSSE, but, that seems unacceptable to me, because of the
following (common) setup:
- User has SSL-enabled Apache (proprietary, open, whatever). It listens on
SSL 443, and forwards requests to TC.
- TC doesn't need to know anything about SSL, it only needs to be able to
generate https url's when it encodes or redirects.
To require users in that situation to obtain JSSE, with whatever
complexities encryption laws places on that process, seems ridiculous.
So, I'm thinking about writing a hack which handles https as a special case:
try {
url = new URL(new URL(requrl), location);
} catch (MalformedURLException e2) {
try {
if(requrl.startsWith("https://")) {
requrl = "http" + requrl.substring(5);
url = new URL(new URL(requrl), location);
return "https" + url.toString().substring(4);
}
}
catch(MalformedURLException e3) {}
return (location); // Give up
}
Other than the fact that this has the flavor of a disgusting hack, it seems
like a workable, pragmatic solution. But before I commit it, I wanted to
check with people who maybe have a deeper understanding of the way of the
URLStreamHandler and its friends. (I am trying the basic URL(requrl)
constructor first, so if the user does have an https URLStreamHandler
installed, it should find it). I think the above should respect
non-standard ports (another issue).
Can anyone tell me why the above is a bad idea? Or does it sound like a
reasonable way to go?
-Dan
--
Dan Milstein // [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: 3.2.2 Release?
Can someone who has functioned as a release manager for a dot release give me a quick overview of what's involved? I may be able to find the time, but I'm not totally clear on the scope of what needs to happen. I don't think Milestone releases would make sense -- from what it says on http://jakarta.apache.org/site/binindex.html, those sound like they should really be steps towards a major release of new functionality, not snapshots of bug fixes in a released product. Nightly builds I would be fine with, however. -Dan [EMAIL PROTECTED] wrote: I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way too busy right now to manage a release. What about a "milestone" ? It doesn't have all the requirements of a release. I can add a nightly build of 3.2.x to my scripts too ? ( it'll not be a "blessed" release, but people who need the patches can use it ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
do filters work ...
I'm sending this to the dev group since I'm dealing w/ tomcat4.0 (catalina)
issues and not sure how far along filters are. I can't seem to get my
filters to work so I have a basic HelloWorld that I'm using. The output of
the jsp is what my problem is.
Everything seems to come up fine (running in stand-alone)
~/logs/catalina.out shows:
catalina.out ---
Starting service Tomcat-Apache
Apache Tomcat/4.0-b1
A shutdown would show:
Stopping service Tomcat-Standalone
Stopping service Tomcat-Apache
Starting service Tomcat-Standalone
Apache Tomcat/4.0-b1
In my ~logs/localhost_access*, the first GET (of my ~/demo/hello.jsp)
returns a 200 (after that it's a 302, anyway to force a non-cached GET?).
The output of the hello.jsp:
_ this is supposed to be an hr
null
Check console output!
_ this is supposed to be an hr
- my hello.jsp -
html
head
titleTesting Filters/title
/head
body
hr
p%=request.getAttribute("hello")%/p
pCheck console output!/p
hr
/body
/html
my filter HelloWorld.java --
package filters;
import javax.servlet.*;
public class HelloWorld extends GenericFilter
{
private FilterConfig FilterConfig;
public void doFilter(final ServletRequest request,
final ServletResponse response,
FilterChain chain) throws java.io.IOException,
javax.servlet.ServletException {
System.out.println("Entering HelloWorld Filter");
request.setAttribute("hello", "Hello World!");
chain.doFilter(request, response);
System.out.println("Entering HelloWorld Filter");
}
}
my generic filter GenericFilter.java -
package filters;
import javax.servlet.*;
public class GenericFilter implements javax.servlet.Filter
{
private FilterConfig filterConfig;
public void doFilter(final ServletRequest request,
final ServletResponse response,
FilterChain chain)
throws java.io.IOException, javax.servlet.ServletException {
chain.doFilter(request, response);
}
public void setFilterConfig(final FilterConfig filterConfig) {
this.filterConfig = filterConfig;
}
public FilterConfig getFilterConfig() {
return filterConfig;
}
}
my web.xml
?xml version="1.0" encoding="ISO-8859-1"?
!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_3.dtd"
web-app
filter
filter-nameprePost/filter-name
filter-classfilters.PrePostFilter/filter-class
/filter
filter
filter-namehelloWorld/filter-name
filter-classfilters.HelloWorld/filter-class
/filter
filter-mapping
filter-nameprePost/filter-name
url-pattern/demo/*/url-pattern
/filter-mapping
filter-mapping
filter-namehelloWorld/filter-name
url-pattern/demo/hello.jsp/url-pattern
/filter-mapping
!--servlet
servlet-nameInsertApp/servlet-name
servlet-classservlets.insertapp.InsertApp/servlet-class
init-param
param-namedebug/param-name
param-value2/param-value
/init-param
/servlet
servlet-mapping
servlet-nameInsertApp/servlet-name
url-pattern/InsertApp/url-pattern
/servlet-mapping--
/web-app
On a side note: any docs on configuring catalinas, like, how to get it out
of stand-alone mode, and the configuration differences is has of previous
tomcat's (i.e. httpd.conf, etc...)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Posting 3.3 native binaries snapshot
With all the changes to mod_jk, I'd like to post these binaries to the jakarta site: builds/jakarta-tomcat/native-3.3/linux/i386/mod_jk.so and ... /win32/i386/mod_jk.dll Any objections? These connectors won't be build nightly, but they will allow people to use the changes we've made so far. +1 -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Servlet ClassLoader
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] * Java asked the webapp class loader to find the controller servlet class * The webapp class loader did not find the class so it delegated to the shared class loader * The shared class loader (which reads from $CATALINA_HOME/lib in Tomcat 4.0 -- the corresponding loader in Tomcat 3.2 reads from the system classpath) and finds your class Now, when your controller servlet calls Class.forName(), it starts from its *own* class loader, and looks either there, or upwards. Of course, if your components are under WEB-INF/classes or WEB-INF/lib, they are not visible ... The Java2 class loading model is for a loader to "delegate first" to it's parent loader. Only if the parent loader (that also delegates first to it's parent) can't find the class will the original loader try to load it. The description above shows the webapp loader attempting to load the class first and only delegating if that fails. Is this really the case? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: 3.2.2 Release?
Dan Milstein wrote:
Can someone who has functioned as a release manager for a dot release give
me a quick overview of what's involved? I may be able to find the time, but
I'm not totally clear on the scope of what needs to happen.
What's involved is essentially:
* Propose the release plan ("I propose to mark the 'tomcat_32"
branch on date x/y/ and release it as version 3.2.2")
for a vote on TOMCAT-DEV.
* Normally, such a plan also includes a temporary freeze on
commits to that branch, unless you do them (to pick up last
minute patches) or delegate the commits for those issues.
* If the number of changes is large enough, you might want
to do a "release candidate" ahead of the actual release for
people to bang against. 3.2.2 has had enough patches that
this might be a good idea. (Nightly builds would also serve
this role -- it would be *great* if Costin had time to set this
up as part of his nightly run).
* On the day of reckoning, do a CVS tag of the correct
code (probably with a tag like "tomcat_322_final").
* Build binary and source distributions in all the usual formats,
and publish them to the Jakarta web site.
* Build native code binaries for as many platforms as you can
gather, and publish them too.
* Announce the release on the Jakarta web site, plus to the
following Jakarta mailing lists: ANNOUNCEMENTS, GENERAL,
TOMCAT-DEV, and TOMCAT-USER.
I can assist with questions on the mechanics, but don't have time to do the
entire job.
I don't think Milestone releases would make sense -- from what it says on
http://jakarta.apache.org/site/binindex.html, those sound like they should
really be steps towards a major release of new functionality, not snapshots
of bug fixes in a released product. Nightly builds I would be fine with,
however.
-Dan
Craig
[EMAIL PROTECTED] wrote:
I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way
too busy right now to manage a release.
What about a "milestone" ? It doesn't have all the requirements of a
release. I can add a nightly build of 3.2.x to my scripts too ? ( it'll
not be a "blessed" release, but people who need the patches can use it ).
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Posting 3.3 native binaries snapshot
Don't forget that ftp://ftp.falsehope.com/home/gomez/tomcat/ host RPM for TC 3.2.x and 3.3 On ne peut rsoudre les problmes les plus graves avec le mme esprit qui les a cres. -- Albert Einstein -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 7:43 PM To: [EMAIL PROTECTED] Subject: Re: Posting 3.3 native binaries snapshot With all the changes to mod_jk, I'd like to post these binaries to the jakarta site: builds/jakarta-tomcat/native-3.3/linux/i386/mod_jk.so and ... /win32/i386/mod_jk.dll Any objections? These connectors won't be build nightly, but they will allow people to use the changes we've made so far. +1 -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: 3.2.2 Release?
[EMAIL PROTECTED] wrote: I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way too busy right now to manage a release. What about a "milestone" ? It doesn't have all the requirements of a release. I can add a nightly build of 3.2.x to my scripts too ? ( it'll not be a "blessed" release, but people who need the patches can use it ). It would be great if you had time to add a nightly build of the "tomcat_32" branch as well. Costin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HTTPS Redirect/encodeURL problems (Bugzilla #269)
Within Tomcat Head / 3.3 there are a host of problems with https pages and
Are those fixed in 3.2.x ? We can just use the same fix.
new URL(new URL(requrl), location)
So the problem is to combine requrl and location and get the encoded
redirect url.
Why not just droping new URL(...) and using some custom code ?
if(requrl.startsWith("https://")) {
requrl = "http" + requrl.substring(5);
url = new URL(new URL(requrl), location);
return "https" + url.toString().substring(4);
}
else if( requrl.stastWith("http://")) }
...
}
Other than the fact that this has the flavor of a disgusting hack, it seems
This wouldn't be a hack at all, but a useful utility.
Can anyone tell me why the above is a bad idea? Or does it sound like a
reasonable way to go?
Sounds reasonable any way, but if we can drop the URL part completely
it'll be great. We are talking about a clear and simple thing here - a
http request and a redirect.
--
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Posting 3.3 native binaries snapshot
Keith, Could I send you 3.3 binaries for NetWare to put out there as well? Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com [EMAIL PROTECTED] 02/02/01 10:56AM With all the changes to mod_jk, I'd like to post these binaries to the jakarta site: builds/jakarta-tomcat/native-3.3/linux/i386/mod_jk.so and ... /win32/i386/mod_jk.dll Any objections? These connectors won't be build nightly, but they will allow people to use the changes we've made so far. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: 3.2.2 Release?
One thing I don't see listed here, and is the biggest reason I don't think I
have the time to manage the release, is determining what bugs still exist in
the tomcat_32 branch and which of those, if any, should be fixed before
releasing 3.2.2. This was an issue that Jon raised regarding the 3.3
release plan. What is the feeling of the Tomcat development community? Can
we get away with just releasing the tip of tomcat_32 as-is or would such a
release *require* a complete review of open bugs and should the release be
held until these bugs are all addressed.
I've been trying to make just such a review but it has been very time
consuming. Maybe, since this is just a minor point release to an existing
product, we can go with what we have.
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 12:44 PM
To: [EMAIL PROTECTED]
Subject: Re: 3.2.2 Release?
Dan Milstein wrote:
Can someone who has functioned as a release manager for a dot
release give
me a quick overview of what's involved? I may be able to find
the time, but
I'm not totally clear on the scope of what needs to happen.
What's involved is essentially:
* Propose the release plan ("I propose to mark the 'tomcat_32"
branch on date x/y/ and release it as version 3.2.2")
for a vote on TOMCAT-DEV.
* Normally, such a plan also includes a temporary freeze on
commits to that branch, unless you do them (to pick up last
minute patches) or delegate the commits for those issues.
* If the number of changes is large enough, you might want
to do a "release candidate" ahead of the actual release for
people to bang against. 3.2.2 has had enough patches that
this might be a good idea. (Nightly builds would also serve
this role -- it would be *great* if Costin had time to set this
up as part of his nightly run).
* On the day of reckoning, do a CVS tag of the correct
code (probably with a tag like "tomcat_322_final").
* Build binary and source distributions in all the usual formats,
and publish them to the Jakarta web site.
* Build native code binaries for as many platforms as you can
gather, and publish them too.
* Announce the release on the Jakarta web site, plus to the
following Jakarta mailing lists: ANNOUNCEMENTS, GENERAL,
TOMCAT-DEV, and TOMCAT-USER.
I can assist with questions on the mechanics, but don't have time
to do the
entire job.
I don't think Milestone releases would make sense -- from what
it says on
http://jakarta.apache.org/site/binindex.html, those sound like
they should
really be steps towards a major release of new functionality,
not snapshots
of bug fixes in a released product. Nightly builds I would be
fine with,
however.
-Dan
Craig
[EMAIL PROTECTED] wrote:
I'm in the same boat right now. I'd love to a 3.2.2
released but I'm way
too busy right now to manage a release.
What about a "milestone" ? It doesn't have all the requirements of a
release. I can add a nightly build of 3.2.x to my scripts too
? ( it'll
not be a "blessed" release, but people who need the patches
can use it ).
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: 3.2.2 Release?
I don't have commit access so can't help there, but I would like to get the 3.2 versions of the NetWare binaries updated in the builds area (builds/jakarta-tomcat/release/) If we do get nightly builds or do a milestone, or whatever, who should the lucky :-) recipient be? Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com [EMAIL PROTECTED] 02/02/01 11:24AM Can someone who has functioned as a release manager for a dot release give me a quick overview of what's involved? I may be able to find the time, but I'm not totally clear on the scope of what needs to happen. I don't think Milestone releases would make sense -- from what it says on http://jakarta.apache.org/site/binindex.html, those sound like they should really be steps towards a major release of new functionality, not snapshots of bug fixes in a released product. Nightly builds I would be fine with, however. -Dan [EMAIL PROTECTED] wrote: I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way too busy right now to manage a release. What about a "milestone" ? It doesn't have all the requirements of a release. I can add a nightly build of 3.2.x to my scripts too ? ( it'll not be a "blessed" release, but people who need the patches can use it ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Servlet ClassLoader
The Java2 class loading model is for a loader to "delegate first" to it's parent loader. Only if the parent loader (that also delegates first to it's parent) can't find the class will the original loader try to load it. The code in the main branch is doing exactly that - the class loader for "core" and the class loader for "webapps" are siblings, with the embeding application class loader as parent ( and of course, we delegate to parent first ). ( For "trusted" applications the webapp loader is a child of the core, that's a special exception. ) The code is not 'enabled' - it requires switching from Tomcat.java to Main.java to start tomcat ( the LoaderInterceptor has all the code in it, but Nacho mentioned few fixes that are also needed ). It'll happen, but right now sorting the bugs and fixing few urgent ones ( like self-test and watchdog failures in sandboxed mode ) is more important. The fact that we don't have regression tests for most bugs that are reported and fixed is really bad, and it's important to fix this in the first place - the nightly run of watchdog and sanity and passing all tests in all supported modes is the most important thing for me. I'll repeat that a lot in the next weeks: if you have a bug and want to have it fixed fast - write and send a regression test for that ( a serlvet/jsp/whatever and a gtest fragment ), we'll include it in the sanity and it'll have a fix ( that will hold and be tested nightly ). -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: mod_jk.so on Solaris
Here's a simple Solaris makefile that I've used to build both an SSL and non-SSL enabled version of mod_jk. I'm not much of an expert on building C apps but this seems to do the trick. If it doesn't work for you then my disclaimer is that I probably have little or no idea what to try next:( Good luck with it though! -Jamey -Original Message- From: Pilho Kim [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 12:30 AM To: [EMAIL PROTECTED] Subject: mod_jk.so on Solaris Hi, How can I make mod_jk.so (or mod_jserv.so) on Solaris 7 ? Thanks in advance, Kim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] makefile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Posting 3.3 native binaries snapshot
Sure, just fetch cvs head before you build to pick up all the fixes. Send them to me or let me know where I can get them. Keith -Original Message- From: Mike Anderson [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 2:02 PM To: [EMAIL PROTECTED] Subject: Re: Posting 3.3 native binaries snapshot Keith, Could I send you 3.3 binaries for NetWare to put out there as well? Mike Anderson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Problems with mod_jk.so, RH7.0, binary/compiled
Well, I didnt even recompile apache, I just took the binaries. It seems that if binaries are provided at www.apache.org they should all work together. Does this mean the binary distribution of apache is standard and not EAPI but the binaries for mod_jk and mod_jserv are EAPI? -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 10:30 AM To: [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Cc: [EMAIL PROTECTED] Subject: RE: Problems with mod_jk.so, RH7.0, binary/compiled Added to FAQOMATIC, finalement :-) http://jakarta.apache.org/jyve-faq/Turbine/screen/DisplayQuestionAnswer/acti on/SetAll/project_id/2/faq_id/12/topic_id/42/question_id/762 All the RPMs present on jakarta.apache.org are compiled under Linux Redhat 6.2 and the Apache is so a apache with EAPI (since using mod_ssl). I'll try to release the next days, mod_jk.so and mod_jserv.so for use on standard Apache under Linux i386. The naming will be : mod_jk.so.eapi mod_jserv_tomcat.so.eapi mod_jk.so.stdapi mod_jserv_tomcat.so.stdapi Ok ? On ne peut resoudre les problemes les plus graves avec le meme esprit qui les a crees. -- Albert Einstein -Original Message- From: Wise, Bowden (CRD) [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 3:58 PM To: '[EMAIL PROTECTED]' Cc: 'tomcat-user' Subject: RE: Problems with mod_jk.so, RH7.0, binary/compiled Hey J I am stuck where you are. I was trying to use the mod_jserv_tomcat.so that you can download. My configuration is RedHat 6.2 on a Dell PC. And I get that same /usr/local/apache/libexec/mod_jserv_tomcat.so is garbled - perhaps this is not an Apache module DSO? So are those binaries for RedHat 7? I also tried compiling but apxs gives me fits: apxs:Error: @sbindir@/httpd not found or not executable Any ideas? Thanks Bowden -Original Message- From: Juan Julian Merelo Guervos [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 5:57 AM To: [EMAIL PROTECTED] Subject: Problems with mod_jk.so, RH7.0, binary/compiled Hi, I haven't been able to install mod_jk.so with Apache 1.3.17. I have downloaded the mod_jk.so binary from the jakarta site, and I get this error: Syntax error on line 8 of /usr/local/jakarta-tomcat-3.2.1/conf/mod_jk.conf-auto: API module structure `jk_module' in file /usr/local/apache/libexec/mod_jk.so is garbled - perhaps this is not an Apache module DSO? OK, good, I thought, that must be the weird RH7.0 file format or whatever. Let's compile it natively. I downloaded source, and compiled it. Guess what I got? Syntax error on line 8 of /usr/local/jakarta-tomcat-3.2.1/conf/mod_jk.conf-auto: API module structure `jk_module' in file /usr/local/apache/libexec/mod_jk.so is garbled - perhaps this is not an Apache module DSO? What's the problem here? Any help? J -- [EMAIL PROTECTED] | [EMAIL PROTECTED] JJ Merelo | http://geneura.ugr.es/~jmerelo Grupo Geneura Univ. Granada | http://www.geneura.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: 3.2.2 Release?
On a somewhat unrelated note... I noticed a bugrat report this morning on an urlencoding that I had submitted a patch for a little while back ( which was flawed/incomplete ). In the process of redoing the patch and grabbing the source from cvs I came up against this issue: what the heck tag is appropriate to use to submit bugfixes against for the 3.2.x version of Tomcat? I am assuming that tomcat_32 is the appropriate place but... - Original Message - From: "Marc Saegesser" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 02, 2001 11:04 Subject: RE: 3.2.2 Release? One thing I don't see listed here, and is the biggest reason I don't think I have the time to manage the release, is determining what bugs still exist in the tomcat_32 branch and which of those, if any, should be fixed before releasing 3.2.2. This was an issue that Jon raised regarding the 3.3 release plan. What is the feeling of the Tomcat development community? Can we get away with just releasing the tip of tomcat_32 as-is or would such a release *require* a complete review of open bugs and should the release be held until these bugs are all addressed. I've been trying to make just such a review but it has been very time consuming. Maybe, since this is just a minor point release to an existing product, we can go with what we have. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: do filters work ...
I have filters working fine on TC 4.0b1
Is demo the name of your web application?
If so your web.xml file should look like this
filter-mapping
filter-nameprePost/filter-name
url-pattern/*/url-pattern
/filter-mapping
filter-mapping
filter-namehelloWorld/filter-name
url-pattern/hello.jsp/url-pattern
/filter-mapping
Even if demo is asubdirectory I would try the first filter mapping here
(i.e. filter everything) and see if that works,
Kevin Jones
DevelopMentor
www.develop.com
-Original Message-
From: Grobe, Gary [mailto:[EMAIL PROTECTED]]
Sent: 02 February 2001 18:27
To: '[EMAIL PROTECTED]'
Subject: do filters work ...
I'm sending this to the dev group since I'm dealing w/ tomcat4.0
(catalina)
issues and not sure how far along filters are. I can't seem to get my
filters to work so I have a basic HelloWorld that I'm using. The output of
the jsp is what my problem is.
Everything seems to come up fine (running in stand-alone)
~/logs/catalina.out shows:
catalina.out ---
Starting service Tomcat-Apache
Apache Tomcat/4.0-b1
A shutdown would show:
Stopping service Tomcat-Standalone
Stopping service Tomcat-Apache
Starting service Tomcat-Standalone
Apache Tomcat/4.0-b1
In my ~logs/localhost_access*, the first GET (of my ~/demo/hello.jsp)
returns a 200 (after that it's a 302, anyway to force a non-cached GET?).
The output of the hello.jsp:
_ this is supposed to be an hr
null
Check console output!
_ this is supposed to be an hr
- my hello.jsp -
html
head
titleTesting Filters/title
/head
body
hr
p%=request.getAttribute("hello")%/p
pCheck console output!/p
hr
/body
/html
my filter HelloWorld.java --
package filters;
import javax.servlet.*;
public class HelloWorld extends GenericFilter
{
private FilterConfig FilterConfig;
public void doFilter(final ServletRequest request,
final ServletResponse response,
FilterChain chain) throws java.io.IOException,
javax.servlet.ServletException {
System.out.println("Entering HelloWorld Filter");
request.setAttribute("hello", "Hello World!");
chain.doFilter(request, response);
System.out.println("Entering HelloWorld Filter");
}
}
my generic filter GenericFilter.java -
package filters;
import javax.servlet.*;
public class GenericFilter implements javax.servlet.Filter
{
private FilterConfig filterConfig;
public void doFilter(final ServletRequest request,
final ServletResponse response,
FilterChain chain)
throws java.io.IOException, javax.servlet.ServletException {
chain.doFilter(request, response);
}
public void setFilterConfig(final FilterConfig filterConfig) {
this.filterConfig = filterConfig;
}
public FilterConfig getFilterConfig() {
return filterConfig;
}
}
my web.xml
?xml version="1.0" encoding="ISO-8859-1"?
!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_3.dtd"
web-app
filter
filter-nameprePost/filter-name
filter-classfilters.PrePostFilter/filter-class
/filter
filter
filter-namehelloWorld/filter-name
filter-classfilters.HelloWorld/filter-class
/filter
filter-mapping
filter-nameprePost/filter-name
url-pattern/demo/*/url-pattern
/filter-mapping
filter-mapping
filter-namehelloWorld/filter-name
url-pattern/demo/hello.jsp/url-pattern
/filter-mapping
!--servlet
servlet-nameInsertApp/servlet-name
servlet-classservlets.insertapp.InsertApp/servlet-class
init-param
param-namedebug/param-name
param-value2/param-value
/init-param
/servlet
servlet-mapping
servlet-nameInsertApp/servlet-name
url-pattern/InsertApp/url-pattern
/servlet-mapping--
/web-app
On a side note: any docs on configuring catalinas, like, how to get it out
of stand-alone mode, and the configuration differences is has of previous
tomcat's (i.e. httpd.conf, etc...)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
3.2/3.x nightly builds
Will be available starting tonight. Because I don't want to load daedalus and it's much easier for me, I'll make them available from: http://nagoya.apache.org/~costin/ws32/ ( 3.x builds are in: http://nagoya.apache.org/~costin/ws/ ) Few notes: - the build is done with JDK1.2( with no extensions in classpath and with JSSE ) and JDK1.1 - tomcat is started and watchdog is run 3 times ( I'm interested in how long it takes - it's a good indicator of how performance is moving - the third time is "warm" and no jsp compilation takes place ) - sanity is also run - all logs are in ws/logs/ ( including summary in nightly.log, detailed build logs, detailed watchdog output, output of run ). - all bundles are in ws/zip/ ( including src, etc ) - For 3.2.x, JDK1.1 build fails :-( ( it failed in 3.2.1, so it's not a regression ). ( it works fine on 3.3 ) - tests for JDK1.1 are not done yet ( the VM has a problem, it's a multiprocessor machine and I didn't had time to install the right patches and VM ). I have another machine that does JDK1.1 and testing ( where I have the right stuff ). And most importantly: - I have a lot of work on my TODO list, don't expect the build/test scripts to do magic or look nice. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 235] New - Apache, mod_jk + APJ13 problems with RequestDispatcher.forward() BugRat Report#373
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=235 *** shadow/235 Fri Feb 2 13:54:02 2001 --- shadow/235.tmp.14788Fri Feb 2 13:54:03 2001 *** *** 0 --- 1,19 + ++ + | Apache, mod_jk + APJ13 problems with RequestDispatcher.forward() BugRat Re | + ++ + |Bug #: 235 Product: Tomcat 3| + | Status: UNCONFIRMED Version: Nightly Build | + | Resolution:Platform: All | + | Severity: Normal OS/Version: All | + | Priority: High Component: Connectors | + ++ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + Using mod_jk + APJ13, RequestDispatcher.forward() returns intermittent results - +sometimes returning the correct page, sometimes throwing a socket write error, +sometimes returning (cached?) results from a previous request. The query string seems +to be frequently ignored. No predictable pattern. + + Additional note: Henri Gomez has reported this on 6/9/00, under the subject "RE: +mod_jk/ajp13 probs with sockets reuse ?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 212] New - Apache + Tomcat bad link handling BugRat Report#325
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=212 *** shadow/212 Fri Feb 2 13:51:57 2001 --- shadow/212.tmp.14752Fri Feb 2 13:51:57 2001 *** *** 0 --- 1,25 + ++ + | Apache + Tomcat bad link handling BugRat Report#325| + ++ + |Bug #: 212 Product: Tomcat 3| + | Status: RESOLVEDVersion: Nightly Build | + | Resolution: INVALIDPlatform: All | + | Severity: Normal OS/Version: All | + | Priority: High Component: Unknown | + ++ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + I ran Tomcat standalone and it works fine. + On the other hand, Tomcat configured as an add-on to Apache (who serves the static +files), with the .dll module loaded has this behaviour: + + When I access /testj/hello it works fine with a test servlet. + When I acces /testj/index.html which has a link in it to /testj/hello I receive a +404 HTTP error. + + The same servlet works fine if I put it in the /examples context. + + So, if it would have been me, I think it shouldn't work at all, therefor I report it +as a bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 SecurityManager and Jasper ClassLoader changes
--- Glenn Nielsen [EMAIL PROTECTED] wrote: I have completed the changes necessary to implement the Java SecurityManager in Tomcat 4. I have also completed switching Jasper over to using the URLClassLoader. Glenn, Could you describe (briefly) the nature of the change in terms of the API? I.E. Did you just reimplement JasperLoader to extend URLClassLoader or did you create a new loader class entirely? I am currently using the tc3.x jasper API by extending it (to add a variety of needed features) and am going to have to make the plunge to tc4.x eventually. Up till now I am pretty sure I've avoided any dependency that would preclude using the tc4.x version. Just staying on my toes here. Thanks, Mel __ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugZilla Tomcat 3 components
Hola a todos: I'm about to add a new component for bugs related to JDBCRealm , and i want to gather opinions about the correct name of the bugzilla-component that makes sense to JDBCRealm, I'm thinking in "Realms" or "Interceptors" or "Modules" or something alike .. FYI. Actual Tomcat 3 Component names are: Connectors: The modules that attach Tomcat to a web server Jasper: The JSP page compiler and runtime engine Servlet: The servlet container Unknown: Unknown Webapps: The example web applications Config: Configuration and start-up Any comment will be highly appreciated .. TIA Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: BugZilla Tomcat 3 components
Hola a todos: I'm about to add a new component for bugs related to JDBCRealm , and i want to gather opinions about the correct name of the bugzilla-component that makes sense to JDBCRealm, I'm thinking in "Realms" or "Interceptors" or "Modules" or something alike .. What about "Auth" ? ( that will include all problems related with authentication and authorization ). ( I don't think it's a good idea to have too specialized categories ). -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: BugZilla Tomcat 3 components
This was prior to find that the Config component, perhaps fits this problem ? Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: sbado 3 de febrero de 2001 1:15 Para: 'tomcat-dev' Asunto: Re: BugZilla Tomcat 3 components Hola a todos: I'm about to add a new component for bugs related to JDBCRealm , and i want to gather opinions about the correct name of the bugzilla-component that makes sense to JDBCRealm, I'm thinking in "Realms" or "Interceptors" or "Modules" or something alike .. What about "Auth" ? ( that will include all problems related with authentication and authorization ). ( I don't think it's a good idea to have too specialized categories ). -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 337] Changed - Tomcat JDBCRealm authentication BugRat Report#606
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=337 *** shadow/337 Fri Feb 2 16:29:02 2001 --- shadow/337.tmp.18052Fri Feb 2 17:09:06 2001 *** *** 2,8 | Tomcat JDBCRealm authentication BugRat Report#606 | ++ |Bug #: 337 Product: Tomcat 3| ! | Status: UNCONFIRMED Version: 3.1 Final | | Resolution:Platform: All | | Severity: Normal OS/Version: All | | Priority: High Component: Config | --- 2,8 | Tomcat JDBCRealm authentication BugRat Report#606 | ++ |Bug #: 337 Product: Tomcat 3| ! | Status: NEW Version: 3.1 Final | | Resolution:Platform: All | | Severity: Normal OS/Version: All | | Priority: High Component: Config | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[BUG 235] ajp13 and RequestDispatcher.forward() gotcha !
It's late but I found it.
After some ethereal dumps I noticed that the finish method in
org.apache.tomcat.modules.server.Ajp13Interceptor is called 2 times
when using forward and so we sent 2 time the END_OF_RESPONSE to
the Apache Web Server.
So Apache (depending on reqs rate and load) will get the 2nd
END_OF_RESPONSE just after sending the next request to tomcat.
And it will return a NO RESPONSE to browser
I think Costin will find quickly where the problem come from
(two calls to finish() but a quick hack could be to add
finished = true in finish() :
=
public void finish() throws IOException
{
if(!finished) {
super.finish();
ajp13.finish();
finished = true;
}
}
=
Just think that recycle() reset finished to false ;-(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [BUG 235] ajp13 and RequestDispatcher.forward() gotcha !
GOMEZ Henri wrote:
It's late but I found it.
After some ethereal dumps I noticed that the finish method in
org.apache.tomcat.modules.server.Ajp13Interceptor is called 2 times
when using forward and so we sent 2 time the END_OF_RESPONSE to
the Apache Web Server.
So Apache (depending on reqs rate and load) will get the 2nd
END_OF_RESPONSE just after sending the next request to tomcat.
And it will return a NO RESPONSE to browser
I recall a similar bug report (and associated fix for 3.2) some time
after 3.2b6. You might want to browse back through the CVS commits for
November if you want to forward port the fix.
Craig
I think Costin will find quickly where the problem come from
(two calls to finish() but a quick hack could be to add
finished = true in finish() :
=
public void finish() throws IOException
{
if(!finished) {
super.finish();
ajp13.finish();
finished = true;
}
}
=
Just think that recycle() reset finished to false ;-(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [BUG 235] ajp13 and RequestDispatcher.forward() gotcha !
TC 3.2.1 seems fixed.
I just take a look at code and saw that the finished = true;
is present in org.apache.tomcat.service.connector.Ajp13ConnectorResponse !-)
public void finish() throws IOException
{
if (!finished) {
super.finish();
finished = true;
MsgBuffer msg = con.getMsgBuffer();
msg.reset();
msg.appendByte(JK_AJP13_END_RESPONSE);
msg.appendByte((byte)1);
msg.end();
con.send(msg);
}
}
And before the send which may safer, so my code come to =
public void finish() throws IOException
{
if(!finished) {
finished = true;
super.finish();
ajp13.finish();
}
}
On ne peut rsoudre les problmes les plus graves avec le mme esprit qui
les a cres.
-- Albert Einstein
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 03, 2001 3:28 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Dan Milstein
Subject: Re: [BUG 235] ajp13 and RequestDispatcher.forward() gotcha !
GOMEZ Henri wrote:
It's late but I found it.
After some ethereal dumps I noticed that the finish method in
org.apache.tomcat.modules.server.Ajp13Interceptor is called 2 times
when using forward and so we sent 2 time the END_OF_RESPONSE to
the Apache Web Server.
So Apache (depending on reqs rate and load) will get the 2nd
END_OF_RESPONSE just after sending the next request to tomcat.
And it will return a NO RESPONSE to browser
I recall a similar bug report (and associated fix for 3.2) some time
after 3.2b6. You might want to browse back through the CVS commits for
November if you want to forward port the fix.
Craig
I think Costin will find quickly where the problem come from
(two calls to finish() but a quick hack could be to add
finished = true in finish() :
=
public void finish() throws IOException
{
if(!finished) {
super.finish();
ajp13.finish();
finished = true;
}
}
=
Just think that recycle() reset finished to false ;-(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [BUG 235] ajp13 and RequestDispatcher.forward() gotcha !
You could easily reproduce the bugs playing with :
This one works
http://yourhost:8080/examples/servlet/servletToJsp
with mod_jk this one fail (reload X times)
http://yourhost/examples/servlet/servletToJsp
On ne peut rsoudre les problmes les plus graves avec le mme esprit qui
les a cres.
-- Albert Einstein
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 03, 2001 3:35 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Dan Milstein; Craig R. McClanahan
Subject: RE: [BUG 235] ajp13 and RequestDispatcher.forward() gotcha !
TC 3.2.1 seems fixed.
I just take a look at code and saw that the finished = true;
is present in
org.apache.tomcat.service.connector.Ajp13ConnectorResponse !-)
public void finish() throws IOException
{
if (!finished) {
super.finish();
finished = true;
MsgBuffer msg = con.getMsgBuffer();
msg.reset();
msg.appendByte(JK_AJP13_END_RESPONSE);
msg.appendByte((byte)1);
msg.end();
con.send(msg);
}
}
And before the send which may safer, so my code come to =
public void finish() throws IOException
{
if(!finished) {
finished = true;
super.finish();
ajp13.finish();
}
}
On ne peut rsoudre les problmes les plus graves avec le mme
esprit qui
les a cres.
-- Albert Einstein
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 03, 2001 3:28 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Dan Milstein
Subject: Re: [BUG 235] ajp13 and RequestDispatcher.forward() gotcha !
GOMEZ Henri wrote:
It's late but I found it.
After some ethereal dumps I noticed that the finish method in
org.apache.tomcat.modules.server.Ajp13Interceptor is called 2 times
when using forward and so we sent 2 time the END_OF_RESPONSE to
the Apache Web Server.
So Apache (depending on reqs rate and load) will get the 2nd
END_OF_RESPONSE just after sending the next request to tomcat.
And it will return a NO RESPONSE to browser
I recall a similar bug report (and associated fix for 3.2) some time
after 3.2b6. You might want to browse back through the CVS
commits for
November if you want to forward port the fix.
Craig
I think Costin will find quickly where the problem come from
(two calls to finish() but a quick hack could be to add
finished = true in finish() :
=
public void finish() throws IOException
{
if(!finished) {
super.finish();
ajp13.finish();
finished = true;
}
}
=
Just think that recycle() reset finished to false ;-(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: bugzilla
Warner Onstine [EMAIL PROTECTED] wrote: Is it possible to set the from or the to address on the bugs to reflect where they are actually coming from? ie - tomcat, ant, etc.? Unfortunately my email client cannot filter on the reply-to or any of those other w addresses (and I'm sure others are the same way, hope, hope ;-). The import of the ANT and TOMCAT-3.3 bugs from BugRat is linked to an alias of [EMAIL PROTECTED], so, until those bugs don't get assigned to a "proper" owner... When they are reassigned it'll go away (shouldn't take long as far as I can see). Pier -- Pier Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: bugzilla
Thanks for the info! -warner - Original Message - From: "Pier Fumagalli" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 02, 2001 8:15 PM Subject: Re: bugzilla Warner Onstine [EMAIL PROTECTED] wrote: Is it possible to set the from or the to address on the bugs to reflect where they are actually coming from? ie - tomcat, ant, etc.? Unfortunately my email client cannot filter on the reply-to or any of those other w addresses (and I'm sure others are the same way, hope, hope ;-). The import of the ANT and TOMCAT-3.3 bugs from BugRat is linked to an alias of [EMAIL PROTECTED], so, until those bugs don't get assigned to a "proper" owner... When they are reassigned it'll go away (shouldn't take long as far as I can see). Pier -- Pier Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/log Log.java
costin 01/02/02 21:29:50
Modified:src/share/org/apache/tomcat/util/log Log.java
Log:
Small change in Log, to allow future improvements ( if needed ) without
chaging the core.
Log has the methods used by tomcat.core and modules - QueueLogger and
DefaultLogger are simple implementations that are hidden behind Log.
This allows to use Log.getLog() instead of new Log and moves the
constants in Log, so only one class is used from core.
Revision ChangesPath
1.2 +29 -17jakarta-tomcat/src/share/org/apache/tomcat/util/log/Log.java
Index: Log.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/log/Log.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Log.java 2000/09/29 14:33:37 1.1
+++ Log.java 2001/02/03 05:29:50 1.2
@@ -81,12 +81,12 @@
* p
* Usage: pre
* class Foo {
- * Log log = new Log("tc_log", "Foo"); // or...
- * Log log = new Log("tc_log", this); // fills in "Foo" for you
+ * Log log = Log.getLog("tc_log", "Foo"); // or...
+ * Log log = Log.getLog("tc_log", this); // fills in "Foo" for you
* ...
* log.log("Something happened");
* ...
- * log.log("Starting something", Logger.DEBUG);
+ * log.log("Starting something", Log.DEBUG);
* ...
* catch (IOException e) {
* log.log("While doing something", e);
@@ -94,23 +94,27 @@
* /pre
*
* @author Alex Chaffee [[EMAIL PROTECTED]]
+ * @author Costin Manolache
**/
public class Log {
-
+/**
+ * Verbosity level codes.
+ */
+public static final int FATAL = Integer.MIN_VALUE;
+public static final int ERROR = 1;
+public static final int WARNING = 2;
+public static final int INFORMATION = 3;
+public static final int DEBUG = 4;
+
+
// name of the logger ( each logger has a unique name,
// used as a key internally )
private String logname;
+
// string displayed at the beginning of each log line,
// to identify the source
private String prefix;
-// The real logger object ( that knows to write to
-// files, optimizations, etc)
-private Logger logger;
-
-// Do we need that?
-//private Log proxy;
-
// Various constructors
public Log() {
@@ -147,6 +151,17 @@
this.prefix = prefix;
}
+public static Log getLog( String channel, String prefix ) {
+ Log log=new Log( channel, prefix );
+ return log;
+}
+
+public static Log getLog( String channel, Object owner ) {
+ // XXX return singleton
+ Log log=new Log( channel, owner );
+ return log;
+}
+
// Log messages.
// That all a client needs to know about logging !
//
@@ -188,9 +203,6 @@
msg = prefix + ": " + msg;
}
- // // activate proxy if present
- // if (proxy != null)
- // logger = proxy.getLogger();
// activate logname fetch if necessary
if (logger == null) {
@@ -208,11 +220,11 @@
// Extra configuration stuff
+// The real logger object ( that knows to write to
+// files, optimizations, etc)
+private Logger logger;
-
public Logger getLogger() {
- // if (proxy != null)
- // logger = proxy.getLogger();
return logger;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core BaseInterceptor.java Context.java ContextManager.java
costin 01/02/02 21:43:20
Modified:src/share/org/apache/tomcat/core BaseInterceptor.java
Context.java ContextManager.java
Log:
Few changes needed to finish the LogSetter.
- ContextManager is no longer a "Log" manager - LogSetter is just setting
the Log tomcat will use ( instead of storing the logs in CM and then
processing them, etc )
- use better names for the log channel ( org/apache/tomcat/core ,
org/apache/tomcat/facade )
- no LogAware - LogSetter is doing the job of plugging the log in the
context and CM.
Revision ChangesPath
1.40 +1 -3
jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java
Index: BaseInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- BaseInterceptor.java 2001/02/01 04:47:12 1.39
+++ BaseInterceptor.java 2001/02/03 05:43:18 1.40
@@ -102,7 +102,7 @@
protected int debug=0;
// loghelper will use name of actual impl subclass
-protected Log loghelper = new Log("tc_log", this);
+protected Log loghelper = Log.getLog("org/apache/tomcat/core", this);
public BaseInterceptor() {
}
@@ -537,7 +537,6 @@
public final void setContextManager( ContextManager cm ) {
this.cm=cm;
this.ct=cm.getContainer();
- loghelper.setLogger(cm.getLogger());
}
public final ContextManager getContextManager() {
@@ -551,7 +550,6 @@
this.ctx=ctx;
this.cm=ctx.getContextManager();
this.ct=ctx.getContainer();
- loghelper.setLogger(ctx.getLog().getLogger());
}
public Context getContext() {
1.135 +8 -16 jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java
Index: Context.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java,v
retrieving revision 1.134
retrieving revision 1.135
diff -u -r1.134 -r1.135
--- Context.java 2001/02/01 05:06:04 1.134
+++ Context.java 2001/02/03 05:43:18 1.135
@@ -98,7 +98,7 @@
* @author [EMAIL PROTECTED]
* @author Gal Shachor [EMAIL PROTECTED]
*/
-public final class Context implements LogAware {
+public final class Context {
// Constants
// Proprietary attribute names for contexts - defined
@@ -236,7 +236,7 @@
private boolean trusted=false;
// log channels for context and servlets
-private Log loghelper = new Log("tc_log", this);
+private Log loghelper = Log.getLog("org/apache/tomcat/core", this);
private Log loghelperServlet;
// servlet API implemented by this Context
@@ -420,7 +420,7 @@
// check if we can access this attribute.
if( isTrusted() ) return true;
log( "Attempt to access internal attribute in untrusted app",
- null, Logger.ERROR);
+ null, Log.ERROR);
return false;
}
@@ -1070,7 +1070,7 @@
public final void logServlet( String msg , Throwable t ) {
if (loghelperServlet == null) {
String pr= getId();
- loghelperServlet = new Log("servlet_log", pr );
+ loghelperServlet = Log.getLog("org/apache/tomcat/facade", pr );
}
if (t == null)
loghelperServlet.log(msg); // uses level INFORMATION
@@ -1078,20 +1078,12 @@
loghelperServlet.log(msg, t); // uses level ERROR
}
-public final void setLogger(Logger logger) {
- if (loghelper == null) {
- String pr=getId();
- loghelper = new Log("tc_log", pr );
- }
- loghelper.setLogger(logger);
+public final void setLog(Log logger) {
+ loghelper=logger;
}
-public final void setServletLogger(Logger logger) {
- if (loghelperServlet == null) {
- String pr=getId();
- loghelperServlet = new Log("servlet_log",pr);
- }
- loghelperServlet.setLogger(logger);
+public final void setServletLog(Logger logger) {
+ loghelperServlet=logger;
}
public final Log getLog() {
1.165 +9 -31
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.164
retrieving revision 1.165
diff -u -r1.164 -r1.165
--- ContextManager.java 2001/02/01 05:06:04 1.164
+++ ContextManager.java 2001/02/03 05:43:18 1.165
@@ -145,7 +145,7 @@
@author
Bugzilla categories
Hi, What about another category - "Encoding" for all encoding-related bugs ? ( that would include all "special chars", charsets, etc). It's a big issue and I want to have all the related bugs grouped togheter. ( I'll work on them - but it's not easy and will take few weeks to sort it out ) -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bugzilla categories
Sounds good to me. Tim - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 02, 2001 11:58 PM Subject: Bugzilla categories Hi, What about another category - "Encoding" for all encoding-related bugs ? ( that would include all "special chars", charsets, etc). It's a big issue and I want to have all the related bugs grouped togheter. ( I'll work on them - but it's not easy and will take few weeks to sort it out ) -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Context.java
costin 01/02/02 23:08:01
Modified:src/share/org/apache/tomcat/core Context.java
Log:
Few changes in Context to make sure the state and rules defined in
ContextManager are respected. ( i.e. no add/initContext before
all modules are initialized, etc ).
Note that per-Context modules have less power than global modules,
i.e. engineInit is called only when the Context is added, contextMap
is never called, etc.
That means that "configuration" modules and "context mappers" need to
be "global". It would be a good idea to make all modules that can be
context-local part of a "profile" to simplify the configuration
( for example a set of contexts that may share common authentication
style, logging, etc - right now you have to set it on each module )
Global modules are bad because it's hard to tune them for individual
contexts.
Revision ChangesPath
1.136 +46 -43jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java
Index: Context.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java,v
retrieving revision 1.135
retrieving revision 1.136
diff -u -r1.135 -r1.136
--- Context.java 2001/02/03 05:43:18 1.135
+++ Context.java 2001/02/03 07:08:00 1.136
@@ -478,7 +478,18 @@
Can be called only from tomcat.core.ContextManager.
( package access )
*/
-void setState( int state ) {
+void setState( int state )
+ throws TomcatException
+{
+ if(this.state==STATE_NEW state==STATE_ADDED ) {
+ BaseInterceptor cI[]=getContainer().getInterceptors();
+ for( int i=0; i cI.length; i++ ) {
+ // set all local interceptors
+ cI[i].setContextManager( contextM );
+ cI[i].engineInit( contextM );
+ cI[i].addContext( contextM, this );
+ }
+ }
this.state=state;
}
@@ -503,40 +514,18 @@
log( "Already initialized " );
return;
}
+
// make sure we see all interceptors added so far
getContainer().resetInterceptorCache(Container.H_engineInit);
- // initialize all local-interceptors
- BaseInterceptor cI[]=getContainer().getInterceptors();
- for( int i=0; icI.length ; i++ ) {
- if( this !=cI[i].getContext()) continue;
- cI[i].setContextManager( contextM );
- try {
- for( int j=0; jcI.length ; j++ ) {
- cI[j].addInterceptor( contextM, this, cI[i] );
- }
-
- cI[i].engineInit( contextM );
- } catch( TomcatException ex ) {
- log( "Error initializing " + cI[i] + " for " + this );
- }
- }
-
-
// no action if ContextManager is not initialized
if( contextM==null ||
contextM.getState() == ContextManager.STATE_NEW ) {
- log( "ContextManager is not yet initialized ");
+ log( "ERROR: ContextManager is not yet initialized ");
return;
}
- if( state==STATE_NEW ) {
- // this context was not added yet
- // throw new TomcatException("Context not added yet " + this );
- contextM.addContext( this );
- }
-
- cI=getContainer().getInterceptors();
+ BaseInterceptor cI[]=getContainer().getInterceptors();
for( int i=0; i cI.length; i++ ) {
cI[i].contextInit( this );
}
@@ -587,7 +576,7 @@
if( "/".equals(path) )
path="";
this.path = path;
- loghelper.setLogPrefix("Ctx("+ path +") ");
+ loghelper.setLogPrefix("Ctx("+ getId() +") ");
}
/**
@@ -1069,8 +1058,7 @@
*/
public final void logServlet( String msg , Throwable t ) {
if (loghelperServlet == null) {
- String pr= getId();
- loghelperServlet = Log.getLog("org/apache/tomcat/facade", pr );
+ loghelperServlet = loghelper;
}
if (t == null)
loghelperServlet.log(msg); // uses level INFORMATION
@@ -1082,7 +1070,7 @@
loghelper=logger;
}
-public final void setServletLog(Logger logger) {
+public final void setServletLog(Log logger) {
loghelperServlet=logger;
}
@@ -1164,28 +1152,43 @@
/** Add a per-context interceptor. The hooks defined will
* be used only for requests that are matched in this context.
* contextMap hook is not called ( since the context is not
- * known at that time
+ * known at that time.
+ *
+ * This method will only store the interceptor. No action
+ * takes place before the context is added ( since contextM
+ * may be unknown ).
*/
public final void addInterceptor( BaseInterceptor ri )
throws
