Re: [5] Authentication for Overlapping Constraints
Bill Barker wrote: Tomcat doesn't adhere to the (new) requirements in the 2.4 Servlet-Spec for handling the case of Overlapping Constraints: spec-quote version=2.4 pfd3 section=12.8.1 When a url-pattern and http-method pair occurs in multiple security constraints, the applicable constraints (on the pattern and method) are defined by combining the individual constraints. /spec-quote I see two ways to address this, but can't pick a clear favorite (hence asking for comments :). 1) Add a method 'List getSecurityConstraints(HttpRequest req, Context ctx)' to Realm, and have AuthenticatorBase loop through them. 2) Have RealmBase create it's own special SecurityConstraint that is the intersection of all of the overlapping constraints, and leave AuthenticatorBase alone. Case 1 has the advantage of being relatively clean from a coding standpoint. Case 2 would probably require adding a 'void intersect(SecurityContraint sc)' method to the SecurityConstraint class to enable it to construct the correct permissions (and this looks like it would be a non-trivial method to implement). Comments/Opinions/Flames? 1) seems better from your description. It could be a good idea to confirm that the spec change will still be in the final version. I'd like to add that a lot of this code is unoptimized (it abuses substring, whereas it could likely use region matching), so maybe it could be a good opportunity to improve it (along with BASIC auth handling). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native configure.in
hgomez 2003/07/24 01:15:22 Modified:jk/native configure.in Log: When Apache 2.0 is found, add define HAVE_APR Revision ChangesPath 1.25 +2 -2 jakarta-tomcat-connectors/jk/native/configure.in Index: configure.in === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- configure.in 5 Jun 2003 09:15:37 - 1.24 +++ configure.in 24 Jul 2003 08:15:22 - 1.25 @@ -100,7 +100,7 @@ APXS_CPPFLAGS= else WEBSERVER=apache-2.0 - APXSCFLAGS=`${APXS} -q CFLAGS` `${APXS} -q EXTRA_CFLAGS` + APXSCFLAGS=`${APXS} -q CFLAGS` `${APXS} -q EXTRA_CFLAGS` -DHAVE_APR APXSCPPFLAGS=`${APXS} -q EXTRA_CPPFLAGS` APACHE_CONFIG_VARS=${apache_dir}/build/config_vars.mk LIBTOOL=`$APXS -q LIBTOOL` - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_connect.h jk_ajp12_worker.c jk_ajp_common.c jk_connect.c
hgomez 2003/07/24 01:17:10 Modified:jk/native/common jk_connect.h jk_ajp12_worker.c jk_ajp_common.c jk_connect.c Log: Make use of APR gethostbyname equivalent when APR is available. Remove AS/400 specific code and fix some short to int in port. We'll use integer everywhere and cast to short only in jk_resolve Revision ChangesPath 1.4 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_connect.h Index: jk_connect.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.h,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- jk_connect.h 25 Jun 2002 07:06:59 - 1.3 +++ jk_connect.h 24 Jul 2003 08:17:10 - 1.4 @@ -76,7 +76,7 @@ #endif /* __cplusplus */ int jk_resolve(char *host, - short port, + int port, struct sockaddr_in *rc); int jk_open_socket(struct sockaddr_in *addr, 1.11 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_ajp12_worker.c Index: jk_ajp12_worker.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp12_worker.c,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- jk_ajp12_worker.c 16 May 2003 00:36:18 - 1.10 +++ jk_ajp12_worker.c 24 Jul 2003 08:17:10 - 1.11 @@ -213,7 +213,7 @@ p-name, host, port); if(port 1024 host) { -if(jk_resolve(host, (short)port, p-worker_inet_addr)) { +if(jk_resolve(host, port, p-worker_inet_addr)) { return JK_TRUE; } jk_log(l, JK_LOG_ERROR, In jk_worker_t::validate, resolve failed\n); 1.38 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c Index: jk_ajp_common.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- jk_ajp_common.c 15 Jul 2003 12:15:17 - 1.37 +++ jk_ajp_common.c 24 Jul 2003 08:17:10 - 1.38 @@ -1366,7 +1366,7 @@ p-name, host, port); if(port 1024 host) { -if(jk_resolve(host, (short)port, p-worker_inet_addr)) { +if(jk_resolve(host, port, p-worker_inet_addr)) { return JK_TRUE; } jk_log(l, JK_LOG_ERROR, 1.9 +39 -19jakarta-tomcat-connectors/jk/native/common/jk_connect.c Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- jk_connect.c 17 Feb 2003 16:59:47 - 1.8 +++ jk_connect.c 24 Jul 2003 08:17:10 - 1.9 @@ -95,18 +95,24 @@ #include novsock2.h #endif +#ifdef HAVE_APR +#include apr_network_io.h +#include apr_errno.h +#include apr_general.h +#endif + /** resolve the host IP */ int jk_resolve(char *host, - short port, + int port, struct sockaddr_in *rc) { int x; -u_long laddr; -#ifdef AS400 -memset(rc, 0, sizeof(struct sockaddr_in)); -#endif +/* TODO: Should be updated for IPV6 support. */ +/* for now use the correct type, in_addr_t */ +in_addr_t laddr; + rc-sin_port = htons((short)port); rc-sin_family = AF_INET; @@ -117,26 +123,40 @@ } } +/* If we found also characters we shoud make name to IP resolution */ if(host[x] != '\0') { -#ifdef AS400 - /* If we found also characters we use gethostbyname_r()*/ - struct hostent hostentry; - struct hostent *hoste = hostentry; - struct hostent_data hd; - memset( hd, 0, sizeof(struct hostent_data) ); - if ( (gethostbyname_r( host, hoste, hd )) != 0 ) { -return JK_FALSE; - } -#else /* If we found also characters we use gethostbyname()*/ - /* XXX : WARNING : We should really use gethostbyname_r in multi-threaded env */ - /* take a look at APR which handle gethostbyname in apr/network_io/unix/sa_common.c */ + +#ifdef HAVE_APR +apr_pool_t *context; +apr_sockaddr_t *remote_sa; +char *remote_ipaddr; + +/* May be we could avoid to recreate it each time ? */ +if (apr_pool_create(context, NULL) != APR_SUCCESS) +return JK_FALSE; + +if (apr_sockaddr_info_get(remote_sa, host, APR_UNSPEC,
cvs commit: jakarta-tomcat-connectors/jk/native/nt_service jk_nt_service.c
hgomez 2003/07/24 01:17:26 Modified:jk/native/nt_service jk_nt_service.c Log: port is now integer Revision ChangesPath 1.8 +18 -18jakarta-tomcat-connectors/jk/native/nt_service/jk_nt_service.c Index: jk_nt_service.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/nt_service/jk_nt_service.c,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- jk_nt_service.c 8 Aug 2002 18:15:44 - 1.7 +++ jk_nt_service.c 24 Jul 2003 08:17:24 - 1.8 @@ -86,8 +86,8 @@ static HANDLE hServerStopEvent = NULL; static int shutdown_port; static char*shutdown_protocol = AJP12_TAG; -static char*shutdown_secret = NULL; -static char*shutdown_cmd=NULL; +static char*shutdown_secret = NULL; +static char*shutdown_cmd=NULL; typedef enum ActionEnum { acNoAction = 0, @@ -156,11 +156,11 @@ char *b, DWORD sz); static int start_tomcat(const char *name, HANDLE *hTomcat); -static void stop_tomcat(char *name, -short port, -const char *protocol, -char *secret, -HANDLE hTomcat); +static void stop_tomcat(char *name, +int port, +const char *protocol, +char *secret, +HANDLE hTomcat); static int read_startup_data(jk_map_t *init_map, jk_tomcat_startup_data_t *data, jk_pool_t *p); @@ -756,8 +756,8 @@ char szNameBuff[256]; DWORD lenNameBuff = 256; char *szTrueName = name; -SC_HANDLE schSCManager; -int rc; +SC_HANDLE schSCManager; +int rc; schSCManager = OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS ); if(schSCManager) { @@ -781,7 +781,7 @@ * Stop order arrived */ ResetEvent(hServerStopEvent); -stop_tomcat(name, (short)shutdown_port, shutdown_protocol, +stop_tomcat(name, shutdown_port, shutdown_protocol, shutdown_secret, hTomcat); break; case (WAIT_OBJECT_0 + 1): @@ -799,7 +799,7 @@ * some error... * close the servlet container and exit */ -stop_tomcat(name, (short)shutdown_port, shutdown_protocol, +stop_tomcat(name, shutdown_port, shutdown_protocol, shutdown_secret, hTomcat); } CloseHandle(hServerStopEvent); @@ -897,7 +897,7 @@ } static void stop_tomcat(char *name, -short port, +int port, const char *protocol, char *secret, HANDLE hTomcat) @@ -1040,9 +1040,9 @@ FILE_END); memset(processInformation, 0, sizeof(processInformation)); - - if( cmdLine==NULL ) - cmdLine=data.cmd_line; + + if( cmdLine==NULL ) + cmdLine=data.cmd_line; printf(cmdLine); if(CreateProcess(data.java_bin, @@ -1063,8 +1063,8 @@ shutdown_port = data.shutdown_port; shutdown_secret = data.shutdown_secret; -shutdown_protocol = strdup(data.shutdown_protocol); - shutdown_cmd = strdup(data.stop_cmd); +shutdown_protocol = strdup(data.shutdown_protocol); + shutdown_cmd = strdup(data.stop_cmd); return JK_TRUE; } else { - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 bldjk.qclsrc
hgomez 2003/07/24 01:17:45 Modified:jk/native/apache-2.0 bldjk.qclsrc Log: Add HAVE_APR in iSeries (AS/400) build script source Revision ChangesPath 1.7 +19 -19jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qclsrc Index: bldjk.qclsrc === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qclsrc,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- bldjk.qclsrc 17 Dec 2002 09:44:35 - 1.6 +++ bldjk.qclsrc 24 Jul 2003 08:17:44 - 1.7 @@ -1,7 +1,7 @@ PGM CRTCMOD MODULE(MOD_JK/MOD_JK) + SRCSTMF('/home/apache/jk/native/apache-2.0/mod_jk.c') + - DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5' '_REENTRANT') + + DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('mod_jk.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -13,7 +13,7 @@ CRTCMOD MODULE(MOD_JK/JK_AJP_COM) + SRCSTMF('/home/apache/jk/native/common/jk_ajp_common.c') + -DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5' '_REENTRANT') + +DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('jk_ajp_common.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -26,7 +26,7 @@ CRTCMOD MODULE(MOD_JK/JK_AJP12_W) + SRCSTMF('/home/apache/jk/native/common/jk_ajp12_worker.c') + -DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5' '_REENTRANT') + +DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('jk_ajp12_worker.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -39,7 +39,7 @@ CRTCMOD MODULE(MOD_JK/JK_AJP13) + SRCSTMF('/home/apache/jk/native/common/jk_ajp13.c') + -DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5' '_REENTRANT') + +DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('jk_ajp13.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -52,7 +52,7 @@ CRTCMOD MODULE(MOD_JK/JK_AJP13_W) + SRCSTMF('/home/apache/jk/native/common/jk_ajp13_worker.c') + -DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5' '_REENTRANT') + +DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('jk_ajp13_worker.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -65,7 +65,7 @@ CRTCMOD MODULE(MOD_JK/JK_AJP14) + SRCSTMF('/home/apache/jk/native/common/jk_ajp14.c') + -DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5' '_REENTRANT') + +DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('jk_ajp14.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -78,7 +78,7 @@ CRTCMOD MODULE(MOD_JK/JK_AJP14_W) + SRCSTMF('/home/apache/jk/native/common/jk_ajp14_worker.c') + -DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5' '_REENTRANT') + +DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('jk_ajp14_worker.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -91,7 +91,7 @@ CRTCMOD MODULE(MOD_JK/JK_CONNECT) + SRCSTMF('/home/apache/jk/native/common/jk_connect.c') + -DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5' '_REENTRANT') + +DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('jk_connect.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -104,7 +104,7 @@ CRTCMOD MODULE(MOD_JK/JK_CONTEXT) + SRCSTMF('/home/apache/jk/native/common/jk_context.c') + -DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5' '_REENTRANT') + +DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('jk_context.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -117,7 +117,7 @@ CRTCMOD MODULE(MOD_JK/JK_JNI_WOR) + SRCSTMF('/home/apache/jk/native/common/jk_jni_worker.c') + -DEFINE('AS400' 'HAVE_JNI' 'OS400_JVM_12' 'USE_APACHE_MD5' '_REENTRANT') + +DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'OS400_JVM_12' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('jk_jni_worker.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -130,7 +130,7 @@ CRTCMOD MODULE(MOD_JK/JK_LB_WORK) + SRCSTMF('/home/apache/jk/native/common/jk_lb_worker.c') + -DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5' '_REENTRANT') + +DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('jk_lb_worker.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -143,7 +143,7 @@ CRTCMOD MODULE(MOD_JK/JK_MAP) + SRCSTMF('/home/apache/jk/native/common/jk_map.c') + -DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5' '_REENTRANT') + +DEFINE('AS400' 'HAVE_JNI' 'HAVE_APR' 'USE_APACHE_MD5' '_REENTRANT') + TEXT('jk_map.c') + OPTIMIZE(40) + SYSIFCOPT(*IFSIO) + @@ -156,7 +156,7 @@ CRTCMOD MODULE(MOD_JK/JK_MD5) + SRCSTMF('/home/apache/jk/native/common/jk_md5.c') + -
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c
hgomez 2003/07/24 01:18:05 Modified:jk/native2/common jk_channel_socket.c Log: Back port use of APR gethostbyname alternative from JK 1.2.x Revision ChangesPath 1.53 +42 -17jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c Index: jk_channel_socket.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c,v retrieving revision 1.52 retrieving revision 1.53 diff -u -r1.52 -r1.53 --- jk_channel_socket.c 11 Apr 2003 01:37:01 - 1.52 +++ jk_channel_socket.c 24 Jul 2003 08:18:05 - 1.53 @@ -83,6 +83,12 @@ #define closesocket close #endif +#ifdef HAS_APR +#include apr_network_io.h +#include apr_errno.h +#include apr_general.h +#endif + #define DEFAULT_HOST 127.0.0.1 /** Information specific for the socket channel @@ -238,12 +244,11 @@ struct sockaddr_in *rc) { int x; -u_long laddr; - -#ifdef AS400 -memset(rc, 0, sizeof(struct sockaddr_in)); -#endif +/* TODO: Should be updated for IPV6 support. */ +/* for now use the correct type, in_addr_t */ +in_addr_t laddr; + rc-sin_port = htons((short)port); rc-sin_family = AF_INET; @@ -254,26 +259,46 @@ } } +/* If we found also characters we use gethostbyname() */ if(host[x] != '\0') { -#ifdef AS400 - /* If we found also characters we use gethostbyname_r()*/ - struct hostent hostentry; - struct hostent *hoste = hostentry; - struct hostent_data hd; - memset( hd, 0, sizeof(struct hostent_data) ); - if ( (gethostbyname_r( host, hoste, hd )) != 0 ) { -return JK_ERR; + +/* if we're using APR and APR is using THREADS, we should use */ +/* APR function to avoid thread problems with gethostbyname */ + +#ifdef HAS_APR +apr_pool_t *context; +apr_sockaddr_t *remote_sa; +char *remote_ipaddr; + + /* May be we could avoid to recreate it each time ? */ + if (apr_pool_create(context, NULL) != APR_SUCCESS) + return JK_FALSE; + +if (apr_sockaddr_info_get(remote_sa, host, APR_UNSPEC, (apr_port_t)port, 0, context) +!= APR_SUCCESS) +return JK_FALSE; + +apr_sockaddr_ip_get(remote_ipaddr, remote_sa); +laddr = inet_addr(remote_ipaddr); + +/* May be we could avoid to delete it each time ? */ +apr_pool_destroy(context); + } -#else /* If we found also characters we use gethostbyname()*/ - /* XXX : WARNING : We should really use gethostbyname_r in multi-threaded env */ - /* take a look at APR which handle gethostbyname in apr/network_io/unix/sa_common.c */ + +#else /* HAS_APR */ + + /* XXX : WARNING : We should really use gethostbyname_r in multi-threaded env */ + /* When APR is available, ie under Apache 2.0, we use it */ struct hostent *hoste = gethostbyname(host); if(!hoste) { return JK_ERR; } -#endif laddr = ((struct in_addr *)hoste-h_addr_list[0])-s_addr; + +#endif /* HAS_APR */ + } else { /* If we found only digits we use inet_addr() */ laddr = inet_addr(host); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test source distribution
Henri Gomez a écrit : So the idea will be to use APR implementation when we detect that APR is available (configure should be updated accordingly). And under Apache 2.0, APR is allways available ! Apache 1.3 use fork mode under Unix, so no thread problem. For Windows I wonder what happen, may be the implementation is safe ? BTW, using APR will remove the #idef AS400 ;) Ahh, yeah, that should work. Your idea, do you want to implement it? I'll do it this night :) I can test it once you have made your commits. No problem, stay tuned Some works should be conducted since apr use many apr_ types. The candidate is of course apr_sockaddr_info_get... Code commited, thanks to test it but I've got no problem with it under my Linux box - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moderation
Hola a todos: I'm actually de moderator of tomcat-dev and tomcat-user, i will go on vacation from 5/08 to 25/08, and i need to recruit someone to take that role, anyone interested, please send me private mail, and we will solve the bloody details.. Thanks in advance.. Saludos, Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Memory Leak: classLoader never released
All, I've seen a problem with a Tomcat Memory Leak which seems to be similar with the bug 20758 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20758 but I would like to be sure about that... I have several J2EE applications hosted by my Tomcat 4.1.24 and the problem is when I deploy 3 or 4 applications, I have an OutOfMemory error (until now, it seems to be a known problem from Tomcat). Moreover, the same thing occurs if I only start, stop and restart an application several times using the Tomcat Manager. To resume, if I play too much time with my applications, the OutOfMemory error occurs... Using OptimizeIt, I tried to understand the problem and I found that my application ClassLoader was never totally released when I stop my application. There are always some strange references on it and especially the classLoader of java.security.ProtectionDomain, which comes from the org.apache.catalina.core.StandardContext.start() method. (I tried the same thing with a very simple application (servlet which bind a RMI service), with the same result) Do you think it could be the same problem than described in the bug report described above? Or maybe a side-effect? Do someone have any ideas? Is there a workaround to avoid to wait for the Tomcat 5.0? Thanks, Vanessa. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DB2 connection problem with Tomcat-4.0.3
Hi I have found your email id in tomcat forums Well .. When I trying to open connection to my DB2 database in tomcat -4.0.3, I am getting below expections.. here is the stacktrace from Tomcat logs(/usr/local/jakartha-tomcat-4.0.3/logs/catilina.out) javax.naming.NameNotFoundException: Name SmsDBDS is not bound in this Context at org.apache.naming.NamingContext.lookup(NamingContext.java:811) at org.apache.naming.NamingContext.lookup(NamingContext.java:181) at org.apache.naming.NamingContext.lookup(NamingContext.java:822) at org.apache.naming.NamingContext.lookup(NamingContext.java:181) at org.apache.naming.NamingContext.lookup(NamingContext.java:822) at org.apache.naming.NamingContext.lookup(NamingContext.java:194) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:183) at javax.naming.InitialContext.lookup(InitialContext.java:354) at com.ebizon.util.jdbc.DBUtil.getEbizDBConnection(DBUtil.java:32) at com.ebizon.board.service.BoardServiceForDB2.getCategoriesByGroup(BoardServiceForDB2.java:1010) at com.ebizon.board.servlet.command.ListBoardCommand.doAction(ListBoardCommand.java:125) at com.ebizon.util.command.ActionCommand.execute(ActionCommand.java:54) at com.ebizon.util.servlet.BaseServlet.service(BaseServlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at com.wizit.acs.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:105) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.warp.WarpRequestHandler.handle(WarpRequestHandler.java:217) at org.apache.catalina.connector.warp.WarpConnection.run(WarpConnection.java:194) at java.lang.Thread.run(Thread.java:536) And my resource definition in server.xml (/usr/local/jakartha-tomcat-4.0.3/conf/server.xml) Context path=/DBTest docBase=DBTest debug=5 reloadable=true crossContext=true Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_DBTest_log. suffix=.txt timestamp=true/ Resource name=jdbc/SmsDBDS auth=Container type=javax.sql.DataSource/
cvs commit: jakarta-tomcat-5/resources/mbeans tomcat5-ant.xml
remm2003/07/24 02:55:16 Modified:resources/mbeans tomcat5-ant.xml Log: - Fix obscure JAXP related CL problem. The issue is likely the lack of decoupling with the main Ant CL. Revision ChangesPath 1.12 +1 -0 jakarta-tomcat-5/resources/mbeans/tomcat5-ant.xml Index: tomcat5-ant.xml === RCS file: /home/cvs/jakarta-tomcat-5/resources/mbeans/tomcat5-ant.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- tomcat5-ant.xml 26 Jun 2003 00:08:41 - 1.11 +++ tomcat5-ant.xml 24 Jul 2003 09:55:16 - 1.12 @@ -147,6 +147,7 @@ description=Start tomcat as an mbean, no server.xml modelerRegistry resource=org/apache/catalina/mbeans/mbeans-descriptors.xml / +modelerRegistry resource=org/apache/catalina/loader/mbeans-descriptors.xml / mkdir dir=${tomcat.home}/work/${domain}/ / jmx-service - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0.5] New tag tomorrow ?
To be able to reach beta quality around the end of this month, a new milestone will need to be released at the end of this week (and more generally, I think a one milestone per week schedule can't hurt when trying to go to beta - even if we end up missing the deadline ;-) ). As usual, I'll populate the changelog. I'll also try to add some docs content. Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21847] New: - Integer like attributes make Tomcat search a (I)V settter
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=21847. 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=21847 Integer like attributes make Tomcat search a (I)V settter Summary: Integer like attributes make Tomcat search a (I)V settter Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've written a customized Tag with a non regular attribute (rtexprvalue=false) called item. The class extends TagSupport and have the following setter : public void setItem(String ch) The tag works fine when using myLib:myTag item=foo / but when using myLib:myTag item=-1 / I get the following error : javax.servlet.ServletException: com.increg.serveur.tag.TagMenu.setItem(I)V at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:536) at org.apache.jsp.index_jsp._jspService(index_jsp.java:214) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:210) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619) at java.lang.Thread.run(Thread.java:536) As I've read in another bug repport that setter can't be overloaded, I think this is a bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.5] New tag tomorrow ?
Sounds good to me. I have some small docs fixes I'll push soon. -Tim Remy Maucherat wrote: To be able to reach beta quality around the end of this month, a new milestone will need to be released at the end of this week (and more generally, I think a one milestone per week schedule can't hurt when trying to go to beta - even if we end up missing the deadline ;-) ). As usual, I'll populate the changelog. I'll also try to add some docs content. Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Expose pre-compiled JSPs without servlet mapping
Remy Maucherat wrote: Jan Luehe wrote: Currently, if webapp developers do not want to expose the source of their JSP files, they have to precompile them and add a servlet mapping for each JSP to their web.xml (e.g., with the help of jspc). If the webapp contains a large number of JSPs, the web.xml is going to grow pretty big. Would it make sense to have Jasper try to load a class file corresponding to a JSP, even if the webapp does not have the JSP source file and does not specify any servlet mapping for that JSP? I think it would, I agree it would be a nice feature. Or even if the JSP does exist, but the developer prefers to precompile JSPs in order to eliminate the initial compilation lag. So if someone accesses a JSP for which there is no servlet mapping, the JspServlet will first determine if the JSP exists, and if it doesn't, it will try to load the corresponding class file. If the class file does not exist, a 404 is returned. Would it look in WEB-INF/classes for the servlet class files, or in tempdir ? Currently JspServlet looks in tempdir, but the precompiled classes are stored in WEB-INF/classes (by appendix A of the JSP spec). Loading the servlet from WEB-INF/classes may have the problem that classes from this place are loaded by the WebApp's classloaders, so they will not bubble up to JasperLoader, which may result in problems with reloading JSPs (without redeploying the whole app). Won't this be a problem? In SunONE Studio, we provide our own JspServlet, which has a somewhat modified reloading logic for JSPs. In addition to checking whether the JSP is newer than the class (in which case it recompiles and reloads the page), it also checks whether the class was modified since the page was last loaded (even if class timestamp JSP timestamp), and if it is, it reloads the page without recompiling it. This will eliminate the need for adding servlet mappings for precompiled JSPs to the web.xml. I think this is a good goal. One advantage of having the servlet mappings is that precompiled JSPs may be selectively exposed, whereas with the proposed scheme, *any* precompiled JSP would be exposed. We could define a config option in JspServlet that would disable the proposed behaviour and require a servlet mapping in order for a precompiled JSP to be exposed. Another advantage is that it would allow having a more lightweitght classloading mechanism for precompiled pages, which would also support lightweight JSP reloading. Comments? -0. A compiled JSP is a servlet, and tools exist to automate the inclusion in web.xml (please have a look at the tomcat-deployer package; I belive it can't get much easier). Its size is irrelevant IMO (if you want it to be smaller, you should look into improving the specification instead). Remy, I agree that it would be useful to have this in the spec. In fact, Ana (in cc:) has already brought this up with Mark Roth. For doing the same thing with regular servlet, we had the InvokerServlet, and look at how much security issues we did run into because of it. If you'd really like to implement your feature, you could add a JSP mode to the InvokerServlet, as there's much functionality in common (and the InvokerServlet creates real Catalina wrappers, with complete stats, etc, like if it had a web.xml mapping). I think that JspServlet is a better place to implement this. The only thing you'd need to change is the reloading logic, and possibly address any classloading issues. Petr Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Expose pre-compiled JSPs without servlet mapping
Petr Jiricka wrote: Remy Maucherat wrote: Jan Luehe wrote: Currently, if webapp developers do not want to expose the source of their JSP files, they have to precompile them and add a servlet mapping for each JSP to their web.xml (e.g., with the help of jspc). If the webapp contains a large number of JSPs, the web.xml is going to grow pretty big. Would it make sense to have Jasper try to load a class file corresponding to a JSP, even if the webapp does not have the JSP source file and does not specify any servlet mapping for that JSP? I think it would, I agree it would be a nice feature. Or even if the JSP does exist, but the developer prefers to precompile JSPs in order to eliminate the initial compilation lag. So if someone accesses a JSP for which there is no servlet mapping, the JspServlet will first determine if the JSP exists, and if it doesn't, it will try to load the corresponding class file. If the class file does not exist, a 404 is returned. Would it look in WEB-INF/classes for the servlet class files, or in tempdir ? Currently JspServlet looks in tempdir, but the precompiled classes are stored in WEB-INF/classes (by appendix A of the JSP spec). Loading the servlet from WEB-INF/classes may have the problem that classes from this place are loaded by the WebApp's classloaders, so they will not bubble up to JasperLoader, which may result in problems with reloading JSPs (without redeploying the whole app). Won't this be a problem? In SunONE Studio, we provide our own JspServlet, which has a somewhat modified reloading logic for JSPs. In addition to checking whether the JSP is newer than the class (in which case it recompiles and reloads the page), it also checks whether the class was modified since the page was last loaded (even if class timestamp JSP timestamp), and if it is, it reloads the page without recompiling it. This will eliminate the need for adding servlet mappings for precompiled JSPs to the web.xml. I think this is a good goal. One advantage of having the servlet mappings is that precompiled JSPs may be selectively exposed, whereas with the proposed scheme, *any* precompiled JSP would be exposed. We could define a config option in JspServlet that would disable the proposed behaviour and require a servlet mapping in order for a precompiled JSP to be exposed. Another advantage is that it would allow having a more lightweitght classloading mechanism for precompiled pages, which would also support lightweight JSP reloading. Comments? -0. A compiled JSP is a servlet, and tools exist to automate the inclusion in web.xml (please have a look at the tomcat-deployer package; I belive it can't get much easier). Its size is irrelevant IMO (if you want it to be smaller, you should look into improving the specification instead). Remy, I agree that it would be useful to have this in the spec. In fact, Ana (in cc:) has already brought this up with Mark Roth. For doing the same thing with regular servlet, we had the InvokerServlet, and look at how much security issues we did run into because of it. If you'd really like to implement your feature, you could add a JSP mode to the InvokerServlet, as there's much functionality in common (and the InvokerServlet creates real Catalina wrappers, with complete stats, etc, like if it had a web.xml mapping). I think that JspServlet is a better place to implement this. The only thing you'd need to change is the reloading logic, and possibly address any classloading issues. -1, I completely disagree with this. You're simply adding a hack to provide a useless feature. Either the JSP in compiled and it is a servlet (and handled as a servlet, with the same constraints and benefits), or it is a JSP page which is loaded in its custom classloader. Adding more complexity in the lame duck warpper (aka JspServlet) is *bad*. You're trying to use precompilation in a way it is not designed for. Note: Unless the feature is mandated in the spec (optional isn't enough), I will veto it. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19799] - Tomcat dies after being up for a while (complains about maxThreads)
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=19799. 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=19799 Tomcat dies after being up for a while (complains about maxThreads) --- Additional Comments From [EMAIL PROTECTED] 2003-07-24 11:50 --- We are seeing this same issue as well with 4.1.24 and 5.0.4alpha. We have a load test program that sends a high volume of concurrent requests to Tomcat and it consistenly refuses connections at around the 75th connection attempt. After a bit, it begins accepting connections again. We have verified that both minProcessors and maxProcessors really seem to have no effect. If you set minProcessors to say 50 or 100 and then perform a thread dump, you will see that there are not 50 pre-allocated threads. If you set maxProcessors to say 1000, you will still see failures around the 75 connection. It's also unclear why the acceptCount is limited to 128 pending connections. We have generated thread dumps and there are no deadlocks. All available threads are currently processing valid requests. The pool is simply out of threads and. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19799] - Tomcat dies after being up for a while (complains about maxThreads)
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=19799. 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=19799 Tomcat dies after being up for a while (complains about maxThreads) --- Additional Comments From [EMAIL PROTECTED] 2003-07-24 12:01 --- Your test program is sending HTTP/1.1 requests, and not closing the connection, so your load tester program is bad. So until the connection timeout occurs, the processors will wait for subsequent requests. You can either: - increase the processor count to a higher value - decrease the connection timeout - set the maxKeepAliveRequests attribute to 1 on the connector, which will disable connection keepalive (that hurts performance a lot) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 RELEASE-NOTES
funkman 2003/07/24 05:01:15 Modified:.RELEASE-NOTES Log: Removed javac leak reference Added FAQ reference SSI-CGI web.xml line #'s were wrong Revision ChangesPath 1.4 +30 -20jakarta-tomcat-5/RELEASE-NOTES Index: RELEASE-NOTES === RCS file: /home/cvs/jakarta-tomcat-5/RELEASE-NOTES,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- RELEASE-NOTES 26 Jun 2003 00:03:49 - 1.3 +++ RELEASE-NOTES 24 Jul 2003 12:01:14 - 1.4 @@ -49,15 +49,18 @@ Tomcat 5.0 Standard APIs Available: -- -A standard installation of Tomcat 4 makes all of the following APIs available +A standard installation of Tomcat 5 makes all of the following APIs available for use by web applications (by placing them in common/lib or shared/lib): * ant.jar (Apache Ant) * commons-collections.jar (Commons Collections) * commons-dbcp.jar (Commons DBCP 1.0) +* commons-el.jar (Commons Expression Language 1.0) * commons-logging-api.jar (Commons Logging) * commons-pool.jar (Commons Pool) * jasper-compiler.jar (Jasper 2 Compiler) * jasper-runtime.jar (Jasper 2 Runtime) +* jmx.jar (From mx4j-1.1.1) +* jmx-tools.jar (From mx4j-1.1.1) * jsp-api.jar (JSP 2.0 API) * commons-el.jar (JSP 2.0 Expression Language) * naming-common.jar (JNDI Context implementation) @@ -79,7 +82,7 @@ As described above, Tomcat 5.0 makes an XML parser (and many other standard APIs) available to web applications. This parser is also used internally to parse web.xml files and the server.xml configuration file. If you wish, -you may replace the xercesImpl.jar file in common/endorsed with another +you may replace the xercesImpl.jar file in common/endorsed with another XML parser, as long as it is compatible with the JAXP 1.1 APIs. @@ -89,12 +92,12 @@ Some shared libraries (many are part of the JDK) keep references to objects instantiated by the web application. To avoid class loading related problems -(ClassCastExceptions, messages indicating that the classloader +(ClassCastExceptions, messages indicating that the classloader is stopped, etc.), the shared libraries state should be reinitialized. -Something which might help is to avoid putting classes which would be -referenced by a shared static field in the web application classloader, -and putting them in the shared classloader instead (JARs should be put in the +Something which might help is to avoid putting classes which would be +referenced by a shared static field in the web application classloader, +and putting them in the shared classloader instead (JARs should be put in the lib folder, and classes should be put in the classes folder). @@ -103,8 +106,8 @@ The Java compiler leaks memory each time a class is compiled. Web applications -containing hundreds of JSP files may as a result trigger out of memory errors -once a significant number of pages have been accessed. The memory can only be +containing hundreds of JSP files may as a result trigger out of memory errors +once a significant number of pages have been accessed. The memory can only be freed by stopping Tomcat and then restarting it. The JSP command line compiler (JSPC) can also be used to precompile the JSPs. @@ -115,11 +118,11 @@ --- Virtual machine crashes may be experienced when using certain combinations of -kernel / glibc under Linux with Sun Hotspot 1.2 to 1.3. The crashes were +kernel / glibc under Linux with Sun Hotspot 1.2 to 1.3. The crashes were reported to occur mostly on startup. Sun JDK 1.4 does not exhibit the problems, and neither does IBM JDK for Linux. -The problems can be fixed by reducing the default stack size. From a bash shell, +The problems can be fixed by reducing the default stack size. From a bash shell, use ulimit -s 2048; use limit stacksize 2048 for tcsh. GLIBC 2.2 / Linux 2.4 users should also define an environment variable: @@ -131,9 +134,9 @@ Having CGI and SSI available to web applications created security problems when -using a security manager (as a malicious web application could use them to +using a security manager (as a malicious web application could use them to sidestep the security manager access control). In Tomcat 5.0, they have been -disabled by default, as our goal is to provide a fully secure default +disabled by default, as our goal is to provide a fully secure default configuration. However, CGI and SSI remain available. To enable CGI and SSI on Windows: @@ -142,8 +145,8 @@ * rename the file %CATALINA_HOME%\server\lib\servlets-ssi.renametojar to %CATALINA_HOME%\server\lib\servlets-ssi.jar. *
cvs commit: jakarta-tomcat-catalina/webapps/docs introduction.xml
funkman 2003/07/24 05:03:57 Modified:webapps/docs introduction.xml Log: Added link to FAQ and Wiki Revision ChangesPath 1.4 +2 -0 jakarta-tomcat-catalina/webapps/docs/introduction.xml Index: introduction.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/introduction.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- introduction.xml 15 Jan 2003 03:40:43 - 1.3 +++ introduction.xml 24 Jul 2003 12:03:57 - 1.4 @@ -101,6 +101,8 @@ to fully read the relevant documentation as it will save you much time and effort. There's nothing like scouring the web only to find out that the answer was right in front of you all along!/li +lia href=http://jakarta.apache.org/tomcat/faq/;Tomcat FAQ/a as maintained by the developers./li +lia href=http://nagoya.apache.org/wiki/apachewiki.cgi?Tomcat;Tomcat WIKI/a/li liJakarta a href=http://jakarta.apache.org:8080/jyve-faq/Turbine/screen/MainMenu/action/SetAll/screen/DisplayTopics/faq_id/12/project_id/2;jsessionid=36lqy9k9x1;FAQ-o-matic/a - a repository of FAQs for the various Jakarta subprojects, including Tomcat of course./li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config valve.xml
funkman 2003/07/24 05:52:55 Modified:webapps/docs/config valve.xml Log: Update for AccessLogValve Revision ChangesPath 1.4 +41 -0 jakarta-tomcat-catalina/webapps/docs/config/valve.xml Index: valve.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/valve.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- valve.xml 15 Jan 2003 03:40:44 - 1.3 +++ valve.xml 24 Jul 2003 12:52:55 - 1.4 @@ -99,6 +99,32 @@ use a zero-length string./p /attribute + attribute name=rotatable required=false +pDeafult true. Flag to determine if log rotation should occur. + If set to false, then this file is never rotated and + ttfileDateFormat/tt is ignored. Use with caution! +/p + /attribute + + attribute name=condition required=false +pTurns on conditional logging. If set, requests will be + logged only if ttServletRequest.getAttribute()/tt is + null. For example, if this value is set to + ttjunk/tt, then a particular request will only be logged + if ttServletRequest.getAttribute(junk) == null/tt. + The use of Filters is an easy way to set/unset the attribute + in the ServletRequest on many different requests. +/p + /attribute + + attribute name=fileDateFormat required=false +pAllows a customized date format in the access log file name. + The date format also decides how often the file is rotated. + If you wish to rotate every hour, then set this value + to: tt-MM-dd.HH/tt +/p + /attribute + /attributes pValues for the codepattern/code attribute are made up of literal @@ -126,7 +152,22 @@ lib%u/b - Remote user that was authenticated (if any), else '-'/li lib%U/b - Requested URL path/li lib%v/b - Local server name/li +lib%D/b - Time taken to process the request, in millis/li +lib%T/b - Time taken to process the request, in seconds/li /ul + +p +There is also support to write information from the cookie, incoming +header, the Session or something else in the ServletRequest. +It is modeled after the apache syntax: +ul +libcode%{xxx}i/code/b for incoming headers/li +libcode%{xxx}c/code/b for a specific cookie/li +libcode%{xxx}r/code/b xxx is an attribute in the ServletRequest/li +libcode%{xxx}s/code/b xxx is an attribute in the HttpSession/li +/ul +/p + pThe shorthand pattern name codecommon/code (which is also the default) corresponds to strong%h %l %u %t %r %s %b/strong./p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] Authentication for Overlapping Constraints
Bill Barker wrote: Tomcat doesn't adhere to the (new) requirements in the 2.4 Servlet-Spec for handling the case of Overlapping Constraints: spec-quote version=2.4 pfd3 section=12.8.1 When a url-pattern and http-method pair occurs in multiple security constraints, the applicable constraints (on the pattern and method) are defined by combining the individual constraints. /spec-quote I see two ways to address this, but can't pick a clear favorite (hence asking for comments :). 1) Add a method 'List getSecurityConstraints(HttpRequest req, Context ctx)' to Realm, and have AuthenticatorBase loop through them. 2) Have RealmBase create it's own special SecurityConstraint that is the intersection of all of the overlapping constraints, and leave AuthenticatorBase alone. Case 1 has the advantage of being relatively clean from a coding standpoint. Case 2 would probably require adding a 'void intersect(SecurityContraint sc)' method to the SecurityConstraint class to enable it to construct the correct permissions (and this looks like it would be a non-trivial method to implement). Comments/Opinions/Flames? In Realm, we already have: /** * Return the SecurityConstraint configured to guard the request URI for * this request, or codenull/code if there is no such constraint. * * @param request Request we are processing */ public SecurityConstraint findSecurityConstraint(HttpRequest request, Context context); Can we modify that method to properly handle the spec? -- Jeanfrancois This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.5] New tag tomorrow ?
+1 Remy Maucherat wrote: To be able to reach beta quality around the end of this month, a new milestone will need to be released at the end of this week (and more generally, I think a one milestone per week schedule can't hurt when trying to go to beta - even if we end up missing the deadline ;-) ). As usual, I'll populate the changelog. I'll also try to add some docs content. Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20663] - Cannot shutdown Tomcat gracefully
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=20663. 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=20663 Cannot shutdown Tomcat gracefully --- Additional Comments From [EMAIL PROTECTED] 2003-07-24 13:58 --- we are getting the same here with SuSe 8.1 Minor difference in line numbers: ... at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) at java.net.Socket.connect(Socket.java:426) at java.net.Socket.connect(Socket.java:376) at java.net.Socket.init(Socket.java:291) ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test source distribution
Henri Gomez wrote: Henri Gomez a écrit : So the idea will be to use APR implementation when we detect that APR is available (configure should be updated accordingly). And under Apache 2.0, APR is allways available ! Apache 1.3 use fork mode under Unix, so no thread problem. For Windows I wonder what happen, may be the implementation is safe ? BTW, using APR will remove the #idef AS400 ;) Ahh, yeah, that should work. Your idea, do you want to implement it? I'll do it this night :) I can test it once you have made your commits. No problem, stay tuned Some works should be conducted since apr use many apr_ types. The candidate is of course apr_sockaddr_info_get... Code commited, thanks to test it but I've got no problem with it under my Linux box I have tested this on both Solaris 7 8 with apache 2. The 4 CPU box on which it had failed now works. Thanks Henri. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21314] - Admin app edit overwrites roles in tomcat-users
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=21314. 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=21314 Admin app edit overwrites roles in tomcat-users [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-07-24 14:41 --- This happens regardless of whether the fullname is changed, so long as the Save button is pressed. Looking at the user.jsp for the webapp, evidently someone removed three lines (two includes and a break) which completely remove the capability to manage the users' roles. I would like to know the reasoning behind this (another bug, etc?). Until it is clarified, here is a quick fix: Insert the following piece of code (between the dashes) in the spot shown in %TOMCAT_HOME%\server\webapps\admin\users\user.jsp: /table bean:define id=checkboxes scope=page value=true/ br !-- --- Begin Insert --- -- %@ include file=groups.jspf % br %@ include file=roles.jspf % !-- --- End Insert - -- %@ include file=../buttons.jsp % /html:form -=[Kevin]=- Kevin L Keathley Computer Sciences Corporation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk 1.2.5 test source distribution
The thread safe bug found in jk_resolve.c has been fixed. I have generated another mod_jk 1.2.5 test source distribution, it can be found at: http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz Please build and test binaries for different OS and web servers. I will call for a release vote for mod_jk 1.2.5 one week from today. Then do the release Monday August 4th if the vote to release succeeds. Does that schedule work for everyone? Thanks, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20663] - Cannot shutdown Tomcat gracefully
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=20663. 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=20663 Cannot shutdown Tomcat gracefully [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] URL||http://marc.theaimsgroup.com ||/?l=tomcat- ||userm=105576731325042w=2 --- Additional Comments From [EMAIL PROTECTED] 2003-07-24 15:13 --- looking at the mailing list, others seem to have the problem too as per the above url and: http://marc.theaimsgroup.com/?l=tomcat-userm=105004880709374w=2 == we use SSL too, but on Suse, it even happens with clientAuth=false Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory clientAuth=false protocol=TLS keystoreFile=/root/.keystore/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs index.xml
remm2003/07/24 08:26:13 Modified:webapps/docs index.xml Log: - Update docs index according to the page changes. Revision ChangesPath 1.9 +17 -11jakarta-tomcat-catalina/webapps/docs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/index.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- index.xml 19 Jun 2003 21:41:48 - 1.8 +++ index.xml 24 Jul 2003 15:26:13 - 1.9 @@ -100,11 +100,14 @@ are responsible for installing, configuring, and operating a Tomcat 5 server. /p ul -lia href=config/index.htmlstrongServer Configuration Reference/strong/a +lia href=RELEASE-NOTES.txtstrongRelease notes/strong/a +- Known issues in this Tomcat release. +/li +lia href=config/index.htmlstrongTomcat Server Configuration Reference/strong/a - Reference manual that documents all available elements and attributes that may be placed into a Tomcat 5 codeconf/server.xml/code file. /li -lia href=jk2/index.htmlstrongJK Documenation/strong/a +lia href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/doc/;strongJK Documenation/strong/a - Complete documentation and HOWTOs on the JK native webserver connector, used to interface Tomcat with servers like Apache HTTPd, IIS and others./li @@ -126,19 +129,22 @@ steps necessary to download Tomcat 5 source code (and the other packages that it depends on), and build a binary distribution from those sources. /li +lia href=changelog.htmlstrongChangelog/strong/a - Details the +changes made to Tomcat. +/li +lia href=status.htmlstrongStatus/strong/a - Tomcat development +status. +/li +lia href=developers.htmlstrongDevelopers/strong/a - List of active +Tomcat contributors. +/li lia href=catalina/funcspecs/index.htmlstrongFunctional Specifications/strong/a - Requirements specifications for features of the emCatalina/em servlet container portion of Tomcat 5./li lia href=catalina/docs/api/index.htmlstrongCatalina Javadocs/strong/a -- Javadoc API documentation for the emCatalina/em servlet container -portion of Tomcat 5./li -lia href=coyote/api/org/apache/coyote/package-summary.htmlstrongCoyote API Javadocs/strong/a -- Javadoc API documentation for the emCoyote/em API./li -lia href=coyote/http11/api/index.htmlstrongCoyote HTTP/1.1 Javadocs/strong/a -- Javadoc API documentation for the emCoyote HTTP/1.1/em connector./li -lia href=coyote/util/index.htmlstrongUtil API Javadocs/strong/a -- Javadoc API documentation for the emCoyote Utilties/em API./li -lia href=jasper/docs/api/index.htmlstrongJavadocs/strong/a +- Javadoc API documentation for the emCatalina/em servlet +container and its dependencies./li +lia href=jasper/docs/api/index.htmlstrongJasper Javadocs/strong/a - Javadoc API documentation for the emJasper/em JSP container portion of Tomcat 5./li /ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21717] - BodyContent backing stream
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=21717. 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=21717 BodyContent backing stream [EMAIL PROTECTED] changed: What|Removed |Added Summary|Can't insert page '...':|BodyContent backing stream |Illegal to flush within a | |custom tag | --- Additional Comments From [EMAIL PROTECTED] 2003-07-24 15:41 --- my actual problem: (pseudo) | write ; | start custom tag (BodyTagSupport) | write ; | pageContext.getOut().flush(); | include other jsp; | write ; | stop custom tag; This gives me the illegal to flush exception. If i leave the flush out. i get the following: | | content of included jsp | | a messed up page. BodyContent.flush() javadoc: It is not valid to flush a BodyContent because there is no backing stream behind it. I took a look at Weblogic since i know on that platform the thing i described above works fine. I found out that their implementation IS using a backing stream and therefor allows all those actions... my question: Are their any plans on implementing this in Tomcat? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CoyoteRequest and it's empty setRequestURI() method
Can anyone explain why the setRequestURI() method in org.apache.coyote.tomcat4.CoyoteRequest is an empty method? The reason I ask is that this disables one from changing the requestURI on a Request from within a valve. I discovered this when I upgraded from Tomcat 4.0.6 to 4.1.24 and my custom valve broke. It took a spin through the source code to figure out the problem. Could it be that this was done for a valid connector reason, but usage from valves was not thought of? Or am I missing something? (This IS a method defined in the Request interface). I _did_ do as much research as possible before hitting the list, but the code comments, etc. do not state a reason for CoyoteRequest not implementing this interface method... Any help would be greatly appreciated as I have only 6 business days left at this client, and this is impacting the ability to finish this Tomcat upgrade. Work-arounds are acceptable at this point too ;-) Thanks!! -- Chris Volk RedWolf Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs setup.xml
remm2003/07/24 10:16:56 Modified:webapps/docs setup.xml Log: - Add basic Windows setup docs (I believe some screenshots would be nice). Revision ChangesPath 1.2 +40 -0 jakarta-tomcat-catalina/webapps/docs/setup.xml Index: setup.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/setup.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- setup.xml 5 Jun 2003 18:28:49 - 1.1 +++ setup.xml 24 Jul 2003 17:16:56 - 1.2 @@ -19,5 +19,45 @@ /section + section name=Windows + +p + Installing Tomcat on Windows can be done easily using the Windows + installer. Its interface and functionality is similar to other wizard + based installers, with only a few items of interest. +/p + +p + ul +listrongInstallation as a service/strong: Tomcat will be +installed as a Windows +NT/2k/XP service no matter what setting is selected. Using the +checkbox on the component page sets the service as auto +startup, so that Tomcat is automatically startup when Windows +starts. For optimal security, the service should be affected a +separate user, with reduced permissions (see the Windows Services +administration tool and its documentation)./li +listrongJava location/strong: The installer will use the registry +or the JAVA_HOME environment variable to determine the base path +of the JDK or a JRE. If only a JRE (or an incorrect path) +is specified, Tomcat will run but will be unable to compile +JSP pages at runtime. Either all webapps will need to be +precompiled (this can be easily done using the Tomcat deployer), +or the codelib\tools.jar/code file from a JDK installation +to the codecommon\lib/code path of the Tomcat installation. +/li +listrongTray icon/strong: When Tomcat is run as a service, there +will not be any tray icon present when Tomcat is running. Note that +when choosing to run Tomcat at the end of installation, the tray +icon will be used even if Tomcat was installed as a service./li + /ul +/p + +pThe installer will create shortcuts allowing starting and configuring + Tomcat. It is important to note that Tomcat administration web + application can only be used when Tomcat is started./p + + /section + /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
remm2003/07/24 10:24:06 Modified:webapps/docs changelog.xml Log: - Changelog update for 5.0.5 (note: I am not tagging yet, and will add entries as needed). Revision ChangesPath 1.9 +191 -8jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- changelog.xml 18 Jul 2003 07:48:56 - 1.8 +++ changelog.xml 24 Jul 2003 17:24:06 - 1.9 @@ -13,6 +13,195 @@ body +section name=Tomcat 5.0.5 Alpha (remm) + + subsection name=General + +changelog + + add + Update the tester web application for Tomcat 5, and make a tester run + part of the release process (remm) + /add + fix + In the checkout target, only checkout modeler from commons instead + of all of commons (funkman) + /fix + fix + Add the catalina-optional JAR in the embed package (remm) + /fix + fix + Fix obscure JAXP related CL problem in embedded mode, by preloading some + descriptors (remm) + /fix + fix + Release notes updates (funkman) + /fix + +/changelog + + /subsection + + subsection name=Catalina + +changelog + + update + Added Embedded.createConnector() methods that take address of type + String (luehe) + /update + fix + Don't set the no-caching headers for protected POSTed pages. This makes + the back button in the browser works as expected. (billbarker) + /fix + fix + bug21341/bug: Fix error page forwarding (remm) + /fix + fix + In the extended log valve, if bytes are requested, then print bytes, + not the date (funkman) + /fix + update + Add a Container.getPipeline() to allow bypassing the (useless) + invoke method (remm) + /update + add + Add code to allow printing partial stack traces for exceptions in HTML + report pages, as well as add a note about the full stack trace of + the root cause being available in the logs (remm) + /add + update + Logs will now contain the root cause of ServletExceptions (remm) + /update + fix + Fix a problem where the Strings weren't escaped in the same way for chars + such as '. This caused problems for localization in French. (remm) + /fix + fix + Add leading + to timezone offset in the access logs (funkman) + /fix + update + Merge ErrorDispacherValve functionality back into StadardHostValve, and + remove associated hacks from StandardServer and StandardHost (remm) + /update + fix + Like some of the other resources, application parameters must not be + reset on a context stop, as they come from a Context element. + Regular parameters read from web.xml should be fine. (remm) + /fix + fix + Correctly update the mapper. The previous code was not compatible with + the invoker servlet and its dynamically added wrappers. (remm) + /fix + fix + Use the context logger for all webapp related error messages (remm) + /fix + update + Remove RequestListenerValve and merge into StandardContextValve (remm) + /update + fix + Fix NPE exception when instances attribute is null (jfarcand) + /fix + fix + bug21822/bug: Valves should only be registered and unregistered when: + addValve or removeValve is called and the associated pipeline is started + or on start and stop of the pipeline (remm) + /fix + +/changelog + + /subsection + + subsection name=Coyote + +changelog + + fix + Slight re-factoring of the JSSE SSL implementation to allow it to work + with non-Sun vendor's 1.4.x JVMs. (billbarker) + /fix + add + Added support for X-Powered-By response header, as defined by the + Servlet 2.4 and JSP 2.0 specs (luehe) + /add + fix + Fix context removal from the mapper when Tomcat is used as embedded + (jfarcand) + /fix + fix + As mandated by the specs, the mapper will always redirect for physical + directories, and will always process physical welcome files mapping + (billbarker) + /fix + + +/changelog + + /subsection + + subsection name=Jasper + +changelog + + fix + bug21753/bug: Fix comment generation, submitted by Eric Carmichael + (billbarker) + /fix + update + Hide all taglib and XML namespace
Re: [5.0.5] New tag tomorrow ?
+1 Amy --- Remy Maucherat [EMAIL PROTECTED] wrote: To be able to reach beta quality around the end of this month, a new milestone will need to be released at the end of this week (and more generally, I think a one milestone per week schedule can't hurt when trying to go to beta - even if we end up missing the deadline ;-) ). As usual, I'll populate the changelog. I'll also try to add some docs content. Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] Authentication for Overlapping Constraints
- Original Message - From: Jean-Francois Arcand [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, July 24, 2003 6:20 AM Subject: Re: [5] Authentication for Overlapping Constraints Bill Barker wrote: Tomcat doesn't adhere to the (new) requirements in the 2.4 Servlet-Spec for handling the case of Overlapping Constraints: spec-quote version=2.4 pfd3 section=12.8.1 When a url-pattern and http-method pair occurs in multiple security constraints, the applicable constraints (on the pattern and method) are defined by combining the individual constraints. /spec-quote I see two ways to address this, but can't pick a clear favorite (hence asking for comments :). 1) Add a method 'List getSecurityConstraints(HttpRequest req, Context ctx)' to Realm, and have AuthenticatorBase loop through them. 2) Have RealmBase create it's own special SecurityConstraint that is the intersection of all of the overlapping constraints, and leave AuthenticatorBase alone. Case 1 has the advantage of being relatively clean from a coding standpoint. Case 2 would probably require adding a 'void intersect(SecurityContraint sc)' method to the SecurityConstraint class to enable it to construct the correct permissions (and this looks like it would be a non-trivial method to implement). Comments/Opinions/Flames? In Realm, we already have: /** * Return the SecurityConstraint configured to guard the request URI for * this request, or codenull/code if there is no such constraint. * * @param request Request we are processing */ public SecurityConstraint findSecurityConstraint(HttpRequest request, Context context); Can we modify that method to properly handle the spec? That is basically my case 2. I'm leaning in the direction of case 1 at the moment. It is easier to implement, much easier to optimize, and for a major-version release we should be able to adapt the Catalina API to do what the spec requires. A custom Realm that doesn't extend RealmBase needs to be re-done for 5.0 in either case to be complient. -- Jeanfrancois This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5] Authentication for Overlapping Constraints
Howdy, 1) Add a method 'List getSecurityConstraints(HttpRequest req, Context ctx)' to Realm, and have AuthenticatorBase loop through them. 2) Have RealmBase create it's own special SecurityConstraint that is the intersection of all of the overlapping constraints, and leave AuthenticatorBase alone. Case 1 has the advantage of being relatively clean from a coding standpoint. Case 2 would probably require adding a 'void intersect(SecurityContraint sc)' method to the SecurityConstraint class to enable it to construct the correct permissions (and this looks like it would be a non-trivial method to implement). Comments/Opinions/Flames? I like the first approach better: +1 on that. Maybe use a Set instead of a List as they're supposed to be unique and order-independent, but that's a nitpick. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21867] New: - problem installing Tomcat 4124 on Win2k
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=21867. 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=21867 problem installing Tomcat 4124 on Win2k Summary: problem installing Tomcat 4124 on Win2k Product: Tomcat 4 Version: 4.1.24 Platform: Other URL: http://jakarta.apache.org/tomcat/tomcat-4.1- doc/README.txt OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I downloaded the package Tomcat-4.1.24.zip extracted it and opened the running.txt - the first problem was that it said I could get this package from http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/ - This directory is empty Second it tells me to set an environment to the variable I installed the JDK - well the windows install did not give me an installation path which is c:\program files\java\j2re1.4.2 (win2k) - just maybe could be noted in the doc Third and most important is the error returned when running startup which is The JAVA_HOME environment variable is not defined correctly This environment variable is needed to run this program Using CATALINA_BASE: c:\tomcat4124 Using CATALINA_HOME: c:\tomcat4124 Using CATALINA_TMPDIR: c:\tomcat4124\temp Using JAVA_HOME: c:\program files\java\j2re1.4.2 The system cannot find the file -Djava.endorsed.dirs=. C:\Tomcat4124\bin my environment is set correctly as I can do a - CD %JAVA_HOME% and it will take me to the installation directory C:\Tomcat4124\binset ALLUSERSPROFILE=C:\Documents and Settings\All Users APPDATA=C:\Documents and Settings\administrator.B2\Application Data CATALINA_HOME=c:\tomcat4124 CommonProgramFiles=C:\Program Files\Common Files ComSpec=C:\WINNT\system32\cmd.exe EXCHICONS=C:\Program Files\Exchsrvr\bin\maildsmx.dll HOMEDRIVE=C: HOMEPATH=\Documents and Settings\administrator.B2 JAVA_HOME=c:\program files\java\j2re1.4.2 NUMBER_OF_PROCESSORS=1 OS=Windows_NT Os2LibPath=C:\WINNT\system32\os2\dll; Path=D:\Perl\bin\;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program F iles\Common Files\Network Associates\VirusScan Engine\4.0.xx\ PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 6 Model 3 Stepping 0, AuthenticAMD PROCESSOR_LEVEL=6 PROCESSOR_REVISION=0300 ProgramFiles=C:\Program Files PROMPT=$P$G SystemDrive=C: SystemRoot=C:\WINNT TEMP=C:\DOCUME~1\ADMINI~1.B2\LOCALS~1\Temp TMP=C:\DOCUME~1\ADMINI~1.B2\LOCALS~1\Temp USERNAME=administrator USERPROFILE=C:\Documents and Settings\administrator.B2 windir=C:\WINNT Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18040] - Entering error-page in web.xml for error code 401 BASIC unexpected behaviour
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=18040. 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=18040 Entering error-page in web.xml for error code 401 BASIC unexpected behaviour [EMAIL PROTECTED] changed: What|Removed |Added Version|4.1.18 |4.1.24 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21867] - problem installing Tomcat 4124 on Win2k
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=21867. 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=21867 problem installing Tomcat 4124 on Win2k --- Additional Comments From [EMAIL PROTECTED] 2003-07-25 00:08 --- it seems that Tomcat will not install with the runtime version of JDK - the full SDK is needed in order for it to work - once this was done the problem was solved - Possibly documentation can be amended to note this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5] Mapper bug?
Hi, I'm currently doing a very basic test: [EMAIL PROTECTED] jfarcand]$ wget http://localhost:8080/ --20:59:22-- http://localhost:8080/ = `index.html' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 400 No Host matches server name localhost 20:59:23 ERROR 400: No Host matches server name localhost. Does I'm missing something here? Same with index.jsp: [EMAIL PROTECTED] jfarcand]$ wget http://localhost:8080/index.jsp --21:00:30-- http://localhost:8080/index.jsp = `index.jsp' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 400 No Host matches server name localhost 21:00:30 ERROR 400: No Host matches server name localhost. I'm using the current head code before jumping into the Mapper/Coyote code (and get tons of -1 :-) .. just kidding ), can someone confirm I'm not wrong? Thanks, -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]