DO NOT REPLY [Bug 16326] - the number of background threads increases
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16326. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16326 the number of background threads increases [EMAIL PROTECTED] changed: What|Removed |Added Component|Connector:HTTP/1.1 |Catalina |(deprecated)| Summary|the number of background|the number of background |threads increases |threads increases -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [proposal] JK2 (WIN32) add dynamic load balancing
Mladen Turk wrote: Hi guys, It's been a long time :-). I would like to add the dynamic load balancing to the existing one. Since I know how to implement that only on WIN platform, I'll elaborate that a bit. The WIN32 has Performance Monitor that monitors server's activity. There is also and interface to that using Registry functions, although the data isn't really stored in the registry. We could use those information to select the least loaded server as a suitable worker. I plan to add the extra file in common that will launch the performance gatherer thread, that will loop through registered remote machines and query the performance data. Any suggestions or objections to that? +0 (entousiast but too busy). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16354] New: - doStartTag() - EVAL_BODY_INCLUDE
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16354.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16354
doStartTag() - EVAL_BODY_INCLUDE
Summary: doStartTag() - EVAL_BODY_INCLUDE
Product: Tomcat 4
Version: 4.1.18
Platform: All
OS/Version: All
Status: NEW
Severity: Critical
Priority: Other
Component: Servlet JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi!
This is a generated java servlet from a jsp by tomcat4.
int _jspx_eval_interbase_databaseElementLoop_0 =
_jspx_th_interbase_databaseElementLoop_0.doStartTag();
if (_jspx_eval_interbase_databaseElementLoop_0 !=
javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
hu.interbase.database.DatabaseElement kapcscegek_elem = null;
Integer counter = null;
if (_jspx_eval_interbase_databaseElementLoop_0 !=
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {
javax.servlet.jsp.tagext.BodyContent _bc = pageContext.pushBody();
_bc.clear();
out = _bc;
_jspx_th_interbase_databaseElementLoop_0.setBodyContent(_bc);
_jspx_th_interbase_databaseElementLoop_0.doInitBody();
kapcscegek_elem = (hu.interbase.database.DatabaseElement)
pageContext.findAttribute(kapcscegek_elem counter = (Integer)
pageContext.findAttribute(counter);
}
do { ...
The problem is that kapcscegek_elem and counter is assigned a value within an if
clause, therefore it enters the do-while loop with null value if doStartTag()
returns
EVAL_BODY_INCLUDE. Why don't fetch the above variables their values from the
page context outside this if clause?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: strange messages in tomcat 4.1.18
Hello Martin and Raiden, Subject: RE: strange messages in tomcat 4.1.18 Date: Wed, 22 Jan 2003 12:41:03 - From: Martin Algesten [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] I've asked myself this question. (I think) the messages are about a connection being left open (as in Keep-Alive and then being closed by the client. I'ts easy to find the where this output is made from in the source. It might be that INFO is a tad much for this kind of messages (perhaps DEBUG would be better?) ... However the logging system jk uses seems to be configurable, and in theory it should be possible to change the level of output for this component. However I can't find any documentation on how to do this, and 5 minutes of glancing at the source does not give any hints... Is there documentation for this? Perhaps a point in the JK FAQ about this message? Martin -Original Message- From: Raiden [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 18:40 To: [EMAIL PROTECTED] Subject: strange messages in tomcat 4.1.18 Hello, I apologize for posting this question to this group, but I have been unable to get an answer in the tomcat-user group. My catalina.out logs are full of the following messages: Jan 21, 2003 10:31:41 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Jan 21, 2003 10:31:42 AM org.apache.jk.common.ChannelSocket processConnection ... Assuming these are non-harmful messages (are they?), is there a way to turn them off, so that they're not flooding my logs? They appear to happen everytime an apache/mod_jk/mod_jk2 worker creates a connection to Tomcat. Thanks, Raiden This has been discussed briefly before, see http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg38339.html If you are using Apache (1.3.x, don't know about 2.0.x) as web server, this message simply means that an Apache child process was restarted. And yes, these are non-harmful messages. See http://httpd.apache.org/docs/mod/core.html#maxrequestsperchild if you'd like to change the restart frequency (there's probably no need to). To prevent messages from showing up in catalina.out you need to adjust logging level for org.apache.jk.common.ChannelSocket. AFAIK this cannot be done by altering log settings in server.xml. Instead, add line org.apache.jk.common.ChannelSocket.level = WARNING to the end of logging.properties in JRE 1.4.x's lib directory (by default /usr/java/jre/lib in Solaris, /usr/java/j2sdk1.4.x/jre/lib in Linux). If you don't want to mess around with default logging file, you can make a copy of it and add parameter -Djava.util.logging.config.file=somefile into Tomcat startup script. I'd vote for changing log level of these server has been restarted... messages from INFO to DEBUG in next Tomcat release. There's enough settings to do even without tampering JRE's property files. :) Hannu -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16357] New: - connection timeout reached in logs when using apache/jk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16357. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16357 connection timeout reached in logs when using apache/jk Summary: connection timeout reached in logs when using apache/jk Product: Tomcat 4 Version: 4.1.18 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In the tomcat log I find a lot of: 23-Jan-2003 11:08:43 org.apache.jk.common.ChannelSocket processConnection INFO: connection timeout reached Here's an email that explains it: -Original Message- From: Hannu Kivimäki [mailto:[EMAIL PROTECTED]] Sent: 23 January 2003 11:20 To: [EMAIL PROTECTED] Subject: Re: strange messages in tomcat 4.1.18 This has been discussed briefly before, see http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg38339.html If you are using Apache (1.3.x, don't know about 2.0.x) as web server, this message simply means that an Apache child process was restarted. And yes, these are non-harmful messages. See http://httpd.apache.org/docs/mod/core.html#maxrequestsperchild if you'd like to change the restart frequency (there's probably no need to). To prevent messages from showing up in catalina.out you need to adjust logging level for org.apache.jk.common.ChannelSocket. AFAIK this cannot be done by altering log settings in server.xml. Instead, add line org.apache.jk.common.ChannelSocket.level = WARNING to the end of logging.properties in JRE 1.4.x's lib directory (by default /usr/java/jre/lib in Solaris, /usr/java/j2sdk1.4.x/jre/lib in Linux). If you don't want to mess around with default logging file, you can make a copy of it and add parameter -Djava.util.logging.config.file=somefile into Tomcat startup script. I'd vote for changing log level of these server has been restarted... messages from INFO to DEBUG in next Tomcat release. There's enough settings to do even without tampering JRE's property files. :) Hannu -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: strange messages in tomcat 4.1.18
Thanks for explaining that. I've referenced your answer in an enhance request with the patch (16357). Martin -Original Message- From: Hannu Kivimäki [mailto:[EMAIL PROTECTED]] Sent: 23 January 2003 11:20 To: [EMAIL PROTECTED] Subject: Re: strange messages in tomcat 4.1.18 Hello Martin and Raiden, Subject: RE: strange messages in tomcat 4.1.18 Date: Wed, 22 Jan 2003 12:41:03 - From: Martin Algesten [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] I've asked myself this question. (I think) the messages are about a connection being left open (as in Keep-Alive and then being closed by the client. I'ts easy to find the where this output is made from in the source. It might be that INFO is a tad much for this kind of messages (perhaps DEBUG would be better?) ... However the logging system jk uses seems to be configurable, and in theory it should be possible to change the level of output for this component. However I can't find any documentation on how to do this, and 5 minutes of glancing at the source does not give any hints... Is there documentation for this? Perhaps a point in the JK FAQ about this message? Martin -Original Message- From: Raiden [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 18:40 To: [EMAIL PROTECTED] Subject: strange messages in tomcat 4.1.18 Hello, I apologize for posting this question to this group, but I have been unable to get an answer in the tomcat-user group. My catalina.out logs are full of the following messages: Jan 21, 2003 10:31:41 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Jan 21, 2003 10:31:42 AM org.apache.jk.common.ChannelSocket processConnection ... Assuming these are non-harmful messages (are they?), is there a way to turn them off, so that they're not flooding my logs? They appear to happen everytime an apache/mod_jk/mod_jk2 worker creates a connection to Tomcat. Thanks, Raiden This has been discussed briefly before, see http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg3 8339.html If you are using Apache (1.3.x, don't know about 2.0.x) as web server, this message simply means that an Apache child process was restarted. And yes, these are non-harmful messages. See http://httpd.apache.org/docs/mod/core.html#maxrequestsperchild if you'd like to change the restart frequency (there's probably no need to). To prevent messages from showing up in catalina.out you need to adjust logging level for org.apache.jk.common.ChannelSocket. AFAIK this cannot be done by altering log settings in server.xml. Instead, add line org.apache.jk.common.ChannelSocket.level = WARNING to the end of logging.properties in JRE 1.4.x's lib directory (by default /usr/java/jre/lib in Solaris, /usr/java/j2sdk1.4.x/jre/lib in Linux). If you don't want to mess around with default logging file, you can make a copy of it and add parameter -Djava.util.logging.config.file=somefile into Tomcat startup script. I'd vote for changing log level of these server has been restarted... messages from INFO to DEBUG in next Tomcat release. There's enough settings to do even without tampering JRE's property files. :) Hannu -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
mturk 2003/01/23 04:11:54
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
Report sucesfull scoreboard child id status as INFO instead of ERROR.
Revision ChangesPath
1.57 +10 -10jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -r1.56 -r1.57
--- mod_jk2.c 26 Oct 2002 14:47:33 - 1.56
+++ mod_jk2.c 23 Jan 2003 12:11:54 - 1.57
@@ -134,8 +134,8 @@
rc=workerEnv-config-setPropertyString( env, workerEnv-config, (char *)name,
value );
if (rc!=JK_OK) {
- ap_log_perror(APLOG_MARK, APLOG_NOTICE, 0, cmd-temp_pool,
- mod_jk2: Unrecognized option %s %s\n,
name, value);
+ap_log_perror(APLOG_MARK, APLOG_NOTICE, 0, cmd-temp_pool,
+ mod_jk2: Unrecognized option %s %s\n, name, value);
}
return NULL;
@@ -525,13 +525,13 @@
if (max_daemons_limit == 0) {
workerEnv-childId = 0;
env-l-jkLog(env, env-l, JK_LOG_INFO,
-jk2_init() Found child %d in scoreboard slot %d\n,
-proc.pid, workerEnv-childId);
+jk2_init() Setting scoreboard slot 0 for child %d\n,
+proc.pid);
}
else {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
-jk2_init() Can't find child %d in scoreboard\n,
-proc.pid);
+jk2_init() Can't find child %d in none of the %d scoreboard
slots\n,
+proc.pid, max_daemons_limit);
workerEnv-childId = -2;
}
} else {
@@ -553,9 +553,9 @@
jk2_init( env, pconf, workerEnv, s );
-if( workerEnv-childId = 0 )
-env-l-jkLog(env, env-l, JK_LOG_ERROR, mod_jk child init %d %d\n,
- workerEnv-was_initialized, workerEnv-childId );
+if (workerEnv-childId = 0)
+env-l-jkLog(env, env-l, JK_LOG_INFO, mod_jk child %d initialized\n,
+ workerEnv-childId);
}
if (workerEnv-childGeneration)
env-l-jkLog(env, env-l, JK_LOG_ERROR, mod_jk child workerEnv in error
state %d\n,
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_jni.c
mturk 2003/01/23 04:13:03
Modified:jk/native2/common jk_channel_jni.c
Log:
Use the macro instead of strdup. We don't need to dupe the
strings on non EBCID machines.
Revision ChangesPath
1.39 +13 -14jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c
Index: jk_channel_jni.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- jk_channel_jni.c 21 Nov 2002 09:03:17 - 1.38
+++ jk_channel_jni.c 23 Jan 2003 12:13:03 - 1.39
@@ -112,16 +112,15 @@
/*
Duplicate string and convert it to ASCII on EBDIC based systems
Needed for at least AS/400 and BS2000 but what about other EBDIC systems ?
+ Implement as macro cause:
+ we don't need to duplicate the strings if they are const on non EBDIS systems
*/
-static void *strdup_ascii(jk_env_t *env,
- char *s)
-{
+
#if defined(AS400) || defined(_OSD_POSIX)
- return (env-tmpPool-pstrdup2ascii(env, env-tmpPool, s));
+#define SSTRDUP_ASCII(e, s) ((e)-tmpPool-pstrdup2ascii(env, env-tmpPool, s))
#else
- return (env-tmpPool-pstrdup(env, env-tmpPool, s));
+#define SSTRDUP_ASCII(e, s) (s)
#endif
-}
static int JK_METHOD jk2_channel_jni_init(jk_env_t *env,
jk_bean_t *jniWB)
@@ -207,7 +206,7 @@
endpoint-channelData=epData;
/* AS400/BS2000 need EBCDIC to ASCII conversion for JNI */
-jniCh-jniBridge = (*jniEnv)-FindClass(jniEnv, strdup_ascii(env,
jniCh-className) );
+jniCh-jniBridge = (*jniEnv)-FindClass(jniEnv, SSTRDUP_ASCII(env,
jniCh-className) );
if( jniCh-jniBridge == NULL ) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
@@ -235,8 +234,8 @@
/* AS400/BS2000 need EBCDIC to ASCII conversion for JNI */
jmethod=(*jniEnv)-GetStaticMethodID(jniEnv, jniCh-jniBridge,
- strdup_ascii(env, createJavaContext),
- strdup_ascii(env, (Ljava/lang/String;J)Ljava/lang/Object;));
+ SSTRDUP_ASCII(env, createJavaContext),
+ SSTRDUP_ASCII(env, (Ljava/lang/String;J)Ljava/lang/Object;));
if( jmethod == NULL ) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
@@ -250,7 +249,7 @@
}
/* AS400/BS2000 need EBCDIC to ASCII conversion for JNI */
-jstr=(*jniEnv)-NewStringUTF(jniEnv, strdup_ascii(env, channelJni ));
+jstr=(*jniEnv)-NewStringUTF(jniEnv, SSTRDUP_ASCII(env, channelJni ));
jobj=(*jniEnv)-CallStaticObjectMethod( jniEnv, jniCh-jniBridge,
jmethod,
@@ -276,8 +275,8 @@
/* AS400/BS2000 need EBCDIC to ASCII conversion for JNI */
jmethod=(*jniEnv)-GetStaticMethodID(jniEnv, jniCh-jniBridge,
- strdup_ascii(env, getBuffer),
- strdup_ascii(env,
(Ljava/lang/Object;I)[B));
+ SSTRDUP_ASCII(env, getBuffer),
+ SSTRDUP_ASCII(env,
(Ljava/lang/Object;I)[B));
if( jmethod == NULL ) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
channel_jni.open() can't find getBuffer\n);
@@ -301,8 +300,8 @@
/* AS400/BS2000 need EBCDIC to ASCII conversion for JNI */
jniCh-writeMethod =
(*jniEnv)-GetStaticMethodID(jniEnv, jniCh-jniBridge,
- strdup_ascii(env, jniInvoke),
- strdup_ascii(env, (JLjava/lang/Object;)I));
+ SSTRDUP_ASCII(env, jniInvoke),
+ SSTRDUP_ASCII(env, (JLjava/lang/Object;)I));
if( jniCh-writeMethod == NULL ) {
env-l-jkLog(env, env-l, JK_LOG_EMERG,
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_shm.c
mturk 2003/01/23 04:15:42
Modified:jk/native2/common jk_shm.c
Log:
Report the missing shm file as INFO not ERROR, cause it is
obvious that the user didn't specify the [shm] in the config.
Revision ChangesPath
1.31 +9 -7 jakarta-tomcat-connectors/jk/native2/common/jk_shm.c
Index: jk_shm.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_shm.c,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- jk_shm.c 27 Sep 2002 13:07:28 - 1.30
+++ jk_shm.c 23 Jan 2003 12:15:42 - 1.31
@@ -262,7 +262,7 @@
int toWrite=shm-size - filestat.st_size;
memset( bytes, 0, 1024 );
- lseek(fd, 0, SEEK_END);
+lseek(fd, 0, SEEK_END);
while( toWrite 0 ) {
int written;
@@ -282,7 +282,7 @@
shm.create(): Can't stat2 %s %d %s\n,
shm-fname, errno, strerror( errno ));
return JK_ERR;
- }
+}
}
shm-privateData = mmap(NULL, filestat.st_size, PROT_READ | PROT_WRITE,
MAP_SHARED, fd, 0);
@@ -293,7 +293,7 @@
shm.create(): Can't mmap %s %d %s\n,
shm-fname, errno, strerror( errno ));
- close(fd);
+close(fd);
return JK_ERR;
}
@@ -330,7 +330,7 @@
shm-privateData=NULL;
if( shm-fname==NULL ) {
-env-l-jkLog(env, env-l, JK_LOG_ERROR, shm.init(): No file\n);
+env-l-jkLog(env, env-l, JK_LOG_INFO, shm.init(): shm file not
specified\n);
return JK_ERR;
}
@@ -471,6 +471,8 @@
/* XXX interprocess sync */
slotId=shm-head-lastSlot++;
}
+else
+return NULL;
slot=shm-getSlot( env, shm, slotId );
if( slot==NULL ) return NULL;
@@ -497,11 +499,11 @@
char *value=(char *)valueP;
if( strcmp( file, name ) == 0 ) {
- shm-fname=value;
+shm-fname=value;
} else if( strcmp( size, name ) == 0 ) {
- shm-size=atoi(value);
+shm-size=atoi(value);
} else {
- return JK_ERR;
+return JK_ERR;
}
return JK_OK;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_workerEnv.c
mturk 2003/01/23 04:18:13
Modified:jk/native2/common jk_workerEnv.c
Log:
Fix the core dumps if the shm wasn't specified or was disabled.
Currently we only checked if it was disabled, not if it failed to initialize.
Revision ChangesPath
1.60 +18 -9 jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c
Index: jk_workerEnv.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- jk_workerEnv.c21 Nov 2002 07:46:40 - 1.59
+++ jk_workerEnv.c23 Jan 2003 12:18:13 - 1.60
@@ -316,11 +316,14 @@
configFile=wEnv-config-file;
}
-if( wEnv-shm-mbean-disabled )
-wEnv-shm=NULL;
-
-if( wEnv-shm != NULL ! wEnv-shm-mbean-disabled ) {
-wEnv-shm-init( env, wEnv-shm );
+if (wEnv-shm != NULL wEnv-shm-mbean-disabled)
+wEnv-shm = NULL;
+
+if (wEnv-shm != NULL) {
+/* Disable the shm if the initialization fails
+*/
+if (wEnv-shm-init(env, wEnv-shm) == JK_ERR)
+wEnv-shm = NULL;
}
if( wEnv-shm != NULL wEnv-shm-head != NULL ) {
@@ -328,7 +331,7 @@
if( wEnv-mbean-debug 0 )
env-l-jkLog(env, env-l, JK_LOG_DEBUG, workerEnv.init() Reset shm\n
);
}
- return JK_OK;
+return JK_OK;
}
/** Normal child init
@@ -391,9 +394,15 @@
jk2_workerEnv_initWorkers( env, wEnv );
jk2_workerEnv_initHandlers( env, wEnv );
+
+if (wEnv-shm != NULL wEnv-shm-mbean-disabled)
+wEnv-shm = NULL;
-if( wEnv-shm != NULL ! wEnv-shm-mbean-disabled ) {
-wEnv-shm-init( env, wEnv-shm );
+if (wEnv-shm != NULL) {
+/* Disable the shm if the initialization fails
+*/
+if (wEnv-shm-init(env, wEnv-shm) == JK_ERR)
+wEnv-shm = NULL;
}
wEnv-epStat=NULL;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_jni.c
mturk 2003/01/23 04:27:45 Modified:jk/native2/common jk_channel_jni.c Log: Fix the SSTRDUP_ASCII macro for EBDIC systems. Revision ChangesPath 1.40 +2 -2 jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c Index: jk_channel_jni.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c,v retrieving revision 1.39 retrieving revision 1.40 diff -u -r1.39 -r1.40 --- jk_channel_jni.c 23 Jan 2003 12:13:03 - 1.39 +++ jk_channel_jni.c 23 Jan 2003 12:27:45 - 1.40 @@ -113,11 +113,11 @@ Duplicate string and convert it to ASCII on EBDIC based systems Needed for at least AS/400 and BS2000 but what about other EBDIC systems ? Implement as macro cause: - we don't need to duplicate the strings if they are const on non EBDIS systems + we don't need to duplicate the strings if they are const on non EBDIC systems */ #if defined(AS400) || defined(_OSD_POSIX) -#define SSTRDUP_ASCII(e, s) ((e)-tmpPool-pstrdup2ascii(env, env-tmpPool, s)) +#define SSTRDUP_ASCII(e, s) ((e)-tmpPool-pstrdup2ascii(e, (e)-tmpPool, s)) #else #define SSTRDUP_ASCII(e, s) (s) #endif -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16357] - connection timeout reached in logs when using apache/jk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16357. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16357 connection timeout reached in logs when using apache/jk --- Additional Comments From [EMAIL PROTECTED] 2003-01-23 12:40 --- Two (a little bit) different cases here. My email was about INFO: server has been restarted or reset this connection while Martin (and patch 4520) addresses INFO: connection timeout reached. Ignore the part about MaxRequestPerChild in httpd.conf if you only care about connection timeout and not server has been restarted, as these messages appear in catalina.out for different reasons. However, changing log level in logging.properties effectively takes care of both. Hannu -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15845. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15845 4.1.19 Memory Leak when creating compilier for JSP pages --- Additional Comments From [EMAIL PROTECTED] 2003-01-23 12:43 --- Created an attachment (id=4522) patch for o.a.j.compiler.Compiler.java -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15845. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15845 4.1.19 Memory Leak when creating compilier for JSP pages --- Additional Comments From [EMAIL PROTECTED] 2003-01-23 12:43 --- Created an attachment (id=4523) patch for o.a.j.JspCompilationContext.java -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Prosal to create TyrexTransactionManagerFactory
Based on the example of TyrexTransactionFactory. I would like to create TyrexTransactionManagerFactory to enable the TransactionManager via JNDI. This would be usefull to cor CASTOR JDO as well as other things that would want to join into a running transaction. Are there any known problems with this idea? To prototype I can probably use server.xml with ObjectFactory, but to fully integrate(so I do not have to use server.xml) What do I have to do? How do I make it a default factory that is called much like the TyrexTransactionFactory? Aron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15845. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15845 4.1.19 Memory Leak when creating compilier for JSP pages --- Additional Comments From [EMAIL PROTECTED] 2003-01-23 14:31 --- Thanks for the patches, but they won't work. The ErrDispatcher is created in the constructor for the Compiler. Your patch would break all compiles after the first one. Please be patient. Fixing this is on my todo list. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16316] - DataSourceRealm can not find JNDI name in context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16316. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16316 DataSourceRealm can not find JNDI name in context --- Additional Comments From [EMAIL PROTECTED] 2003-01-23 14:33 --- You are welcome to submit a patch to the documentation if you feel it could be improved. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16363] New: - Stack Overflow accessing compiled JSP - Tomcat 3.2.4 and JDK 1.4.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16363. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16363 Stack Overflow accessing compiled JSP - Tomcat 3.2.4 and JDK 1.4.1 Summary: Stack Overflow accessing compiled JSP - Tomcat 3.2.4 and JDK 1.4.1 Product: Tomcat 3 Version: 3.2.3 Final Platform: All OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We're running a standalone Tomcat 3.2.4 installation (yes, I know I marked this as 3.2.3 Final, but there's no option for 3.2.4 Final) under Sun JDK 1.4.1 (Win2K or Solaris 2.8), with the jar files containing our code having been compiled under Sun JDK 1.3.1. Hitting a certain page will invariably cause a Stack Overflow. I was able to capture one in-progress: Thread-28 prio=5 tid=0x24C65070 nid=0x698 runnable [2bb4c000..2bb4fd8c] at java.lang.Class.getName(Native Method) at org.apache.tomcat.core.ContextManager.handleError (ContextManager.java:1146) at org.apache.tomcat.core.Handler.service(Handler.java:312) at org.apache.tomcat.core.ServletWrapper.service (ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleError (ContextManager.java:1177) ... at org.apache.tomcat.core.Handler.service(Handler.java:312) at org.apache.tomcat.core.ServletWrapper.service (ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleError (ContextManager.java:1177) at org.apache.tomcat.core.Handler.service(Handler.java:312) at org.apache.tomcat.core.ServletWrapper.service (ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleError (ContextManager.java:1177) at org.apache.tomcat.core.ContextManager.service (ContextManager.java:759) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection (HttpConnectionHandler.java:213) at org.apache.tomcat.service.TcpWorkerThread.runIt (PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run (ThreadPool.java:501) at java.lang.Thread.run(Thread.java:536) The ... is mine - the trace was 250 lines long when I nabbed it. The page that seems to trigger it has the following general structure: = %@ page language=java contentType=text/html% %@ page import blah blah blah% %@ include file=newToolbarSetup.jsp% % java code % HTML HEAD blah blah blah /HEAD %@ include file=newToolbar.jsp% /HTML = newToolbarSetup.jsp is as follows: %@ page errorPage=badstate.jsp?debug=log % % various Java code setting attrs on request and response and doing some calculation and variable definition % = newToolbar.jsp is as follows: % java code % BODY stuff /BODY = badstate.jsp is as follows: %@ page language=java contentType=text/html % %@ page import blah blah blah% %@ page isErrorPage=true % % java code % HTML HEAD stuff /HEAD BODY stuff /BODY /HTML = This worked fine under Tomcat 3.2.4 and JDK 1.3.1, and broke immediately when we switched to JDK 1.4.1. As an experiment, I subbed JDK 1.3.1 back in, deleted all of the files in my work directory, and verified that it still works under 1.3.1. Then, if I delete the work files again and sub 1.4.1 back in, it breaks again. So it looks like a Tomcat 3.2.4/JDK 1.4.1 incompatibility. But I've been unable to find anything documented. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Proposal to give a web front end to the manager app.
I have a proposal wrt to the manager app. Can we make it a bit more user friendly. Wouldn't a web interface help? It wont be too much work since servlets are pretty much there to do the work.One just needs to put the results into a few htmls. I also feel it would be nice if one could do a bit of configuration from the interface. Adding resources like a database pool etc from the interface would be great. If you feel it will be useful I can try to reuse some things I have already done one the same lines. Comments. . - Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Re: Proposal to give a web front end to the manager app.
Sounds nice I personally like web interfaces quite a lot ... but that is only me White Knight wrote: I have a proposal wrt to the manager app. Can we make it a bit more user friendly. Wouldn't a web interface help? It wont be too much work since servlets are pretty much there to do the work.One just needs to put the results into a few htmls. I also feel it would be nice if one could do a bit of configuration from the interface. Adding resources like a database pool etc from the interface would be great. If you feel it will be useful I can try to reuse some things I have already done one the same lines. Comments. . - Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now -- _ /_/\ Rui Pereira / \\ \ Systems Engineer /_\ \\ /Sun Microsystems Portugal /_/ \/ / / Phone: +351 21 413 40 00 /_/ / \//\ Fax: +351 21 413 40 99 \_\//\ / / Email: [EMAIL PROTECTED] \_/ / /\ / \_/ \\ \http://www.sun.pt \_\ \\ \_\/ We make the net work. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal to give a web front end to the manager app.
Have you tried /manager/html/ ??? I also was unaware of its existence until recently, though it is what you get to if you click on the Tomcat Manager link on the main Tomcat index.jsp page. I'm not sure of what version of Tomcat this appeared in. I think it is in at least 4.1.12. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 1/23/03 7:40:57 AM I have a proposal wrt to the manager app. Can we make it a bit more user friendly. Wouldn't a web interface help? It wont be too much work since servlets are pretty much there to do the work.One just needs to put the results into a few htmls. I also feel it would be nice if one could do a bit of configuration from the interface. Adding resources like a database pool etc from the interface would be great. If you feel it will be useful I can try to reuse some things I have already done one the same lines. Comments. . - Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16369] New: - jasper4 does wrong su call
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16369. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16369 jasper4 does wrong su call Summary: jasper4 does wrong su call Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The call of su in /usr/bin/jasper4 does not work on Linux. root@titan root# /usr/bin/jasper4 jspc -webapp /var/tomcat4/webapps/tiles-documentation su: invalid option -- w Try `su --help' for more information. Solution: 1. You have to change the order of switches from su - user -c cmd to su -c cmd - user 2. Additionally cmd has to be protected so that it's not interpreted by su. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal to give a web front end to the manager app.
Tomcat 4.1 has a web interface to the manager web application /manager/html/ This interface was improved a great deal in the Tomcat 4.1.19 release. As far as adding resources check out the admin application which comes with Tomcat 4.1. Regards, Glenn White Knight wrote: I have a proposal wrt to the manager app. Can we make it a bit more user friendly. Wouldn't a web interface help? It wont be too much work since servlets are pretty much there to do the work.One just needs to put the results into a few htmls. I also feel it would be nice if one could do a bit of configuration from the interface. Adding resources like a database pool etc from the interface would be great. If you feel it will be useful I can try to reuse some things I have already done one the same lines. Comments. . - Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16373] New: - context param from server.xml not read when application stopped and started from tomcat webmanager.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16373 context param from server.xml not read when application stopped and started from tomcat webmanager. Summary: context param from server.xml not read when application stopped and started from tomcat webmanager. Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] getServletContext().getInitParameter(helloworld) is getting the param value from web.xml when done like this context-param param-namehelloworld/param-name param-valueHello World! How are you?/param-value /context-param but when given in server.xml as Context path=/test docBase=.. debug=0 crossContext=true privileged=true reloadable=true Parameter name=helloworld value=Hello World! How are you override=true/ /Context it returns null when app is stopped and started again from Tomcat manager. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16374] New: - Make access log filename date format configurable in AccessLogValve
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16374. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16374 Make access log filename date format configurable in AccessLogValve Summary: Make access log filename date format configurable in AccessLogValve Product: Tomcat 4 Version: 4.1.20 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The access log filename date format is currently hardcoded in org.apache.catalina.valves.AccessLogValve. I would like to be able to provide my own date format in the valve descriptor in server.xml. e.g., Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=access_log. dateFormat=.MM.dd suffix= pattern=common resolveHosts=false/ I am willing to provide the patch for this functionality, but I have a couple of points on which I would like feedback. 1. In the current AccessLogValve implementation, the hardcoded date format is used in the filename, and it is also used to detect whether the log should be rotated (i.e., if the string produced by the date format changes, the log should rotate). If I simply make that date format configurable, the filename will change, but the rotation interval could also change, depending on how often the resulting date string changes. Responses on the tomcat-dev list suggest that these two concerns should be separate. Is there any disagreement? 2. If the provided date format is invalid, the creation of the SimpleDateFormat throws IllegalArgumentException, which is a RuntimeException. If the exception is uncaught, Tomcat startup fails, and the exception is not logged. IllegalArgumentException should be caught, and a new DateFormatException thrown. This new Exception class will also have to be created. 3. If the provided date format does not result in a string which changes on a daily basis, when the log rotates (daily), the new filename will be the same as the old filename, simply over-writing the previous day's log. In this case, this is probably the correct behavior. Note that if the provided date format controls both the filename and the rotation (see point 1), this problem goes away. Comments? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Misspelled item in tomcat 3.3.x
Has anybody ever pointed out that the EmbededTomcat.java of Tomcat 3.3.x is mispelled? Is this something that should be fixed? I can submit a patch, if so. :) Maybe at least the debug messages, since those are visible to the users. Actually, it looks like this misspelling has been carried forward to Tomcat 4.x with EmbededServletOptions.java, though there are no messages logged with the misspelling. Just doing some due-diligence for a tester who spotted this and logged a defect. :) Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net business solutions http://www.novell.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15938] - regex not matching uri's with isapi_redirector2.dll 2.0.2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15938 regex not matching uri's with isapi_redirector2.dll 2.0.2 [EMAIL PROTECTED] changed: What|Removed |Added Component|Connector:Coyote JK 2 |Connector:Other -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16378] New: - org.apache.catalina.authenticator.SingleSignOn.toString() throws NullPointer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16378.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16378
org.apache.catalina.authenticator.SingleSignOn.toString() throws NullPointer
Summary: org.apache.catalina.authenticator.SingleSignOn.toString(
) throws NullPointer
Product: Tomcat 4
Version: 4.1.12
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
org.apache.catalina.authenticator.SingleSignOn.toString() assumes member
container has been set, but this class has only a default constructor, so this
may not be true when the method is first called.
See http://www.jboss.org/forums/thread.jsp?forum=49thread=8141 for an example
of how this has caused a bug with the JBoss3.0.4/Tomcat4.1.12 integration.
A possible fix would be:
public String toString()
{
StringBuffer sb = new StringBuffer();
if (getContainer() != null)
{
sb.append(SingleSignOn[);
sb.append(getContainer().getName());
sb.append(]);
}
else
{
sb.append(getClass().getName());
sb.append('@');
sb.append(Integer.toHexString(hashCode()));
}
return (sb.toString());
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs ssl-howto.xml
luehe 2003/01/23 15:45:12 Modified:webapps/docs ssl-howto.xml Log: Updated SSL configuration info with appropriate connector and socket factory class names, so that it matches the info in server.xml Revision ChangesPath 1.4 +5 -5 jakarta-tomcat-catalina/webapps/docs/ssl-howto.xml Index: ssl-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/ssl-howto.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ssl-howto.xml 15 Jan 2003 03:40:43 - 1.3 +++ ssl-howto.xml 23 Jan 2003 23:45:12 - 1.4 @@ -270,13 +270,13 @@ for an SSL connector is included in the default codeserver.xml/code file installed with Tomcat. It will look something like this:/p source -lt;-- Define an SSL HTTP/1.1 Connector on port 8443 --gt; +lt;-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 --gt; lt;!-- -lt;Connector className=org.apache.catalina.connector.http.HttpConnector +lt;Connector className=org.apache.coyote.tomcat5.CoyoteConnector port=8443 minProcessors=5 maxProcessors=75 - enableLookups=true - acceptCount=10 debug=0 scheme=https secure=truegt; - lt;Factory className=org.apache.catalina.net.SSLServerSocketFactory + enableLookups=true disableUploadTimeout=true + acceptCount=100 debug=0 scheme=https secure=truegt; + lt;Factory className=org.apache.coyote.tomcat5.CoyoteServerSocketFactory clientAuth=false protocol=TLS/gt; lt;/Connectorgt; --gt; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16354] - doStartTag() - EVAL_BODY_INCLUDE
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16354. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16354 doStartTag() - EVAL_BODY_INCLUDE [EMAIL PROTECTED] changed: What|Removed |Added Component|Servlet JSP API |Jasper 2 --- Additional Comments From [EMAIL PROTECTED] 2003-01-23 23:57 --- This bug is fixed in Tomcat 4.1.19 See http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg38931.html for detais. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16354] - doStartTag() - EVAL_BODY_INCLUDE
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16354. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16354 doStartTag() - EVAL_BODY_INCLUDE [EMAIL PROTECTED] changed: What|Removed |Added Severity|Critical|Normal --- Additional Comments From [EMAIL PROTECTED] 2003-01-24 00:29 --- There is workaround for Tomcat 4.1.x (where x19) Make your iteration tag extend TagSupport instead of BodyTagSupport. Therefor you return EVAL_BODY_INCLUDE from doStartTag() you don't need to extend BodyTagSupport. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
