DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 06:56 --- I suggest you try to reproduce first with only 10 or 50 threads. Reproduction would be successful, if you still observe continuous CPU usage in this case, maybe less than 100%, but still noticeable. Then in this state you take a Thread Dump (sending the QUIT signal to the tomcat process). It will write the method stack for all threads inside tomcat to catalina.out. Wait a few seconds an take another Thread Dump, again wait and take a third one. Then look at the stacks of your working threads. Anything special about the top part of the individual stacks? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problems with SSL_CLIENT_CERT_CHAIN_n from servlet
-Mensaje original-
De: jean-frederic clere [mailto:[EMAIL PROTECTED]
Enviado el: miércoles, 06 de octubre de 2004 16:54
Para: Tomcat Developers List
Asunto: Re: Problems with SSL_CLIENT_CERT_CHAIN_n from servlet
What do have in httpd.conf?
In my httpd.conf I've appended the following lines related to mod_ssl and
mod_jk:
Include /usr/local/java/tomcat4/conf/mod_jk.conf
Include /usr/local/apache/conf/ssl.conf
File mod_jk.conf looks like this:
IfModule !mod_jk.c
LoadModule jk_module /usr/local/apache/libexec/mod_jk.so
/IfModule
JkExtractSSL On
JkHTTPSIndicator HTTPS
JkSESSIONIndicator SSL_SESSION_ID
JkCIPHERIndicator SSL_CIPHER
JkCERTSIndicator SSL_CLIENT_CERT
JkEnvVar SSL_PROTOCOL sslProtocol
JkEnvVar SSL_CLIENT_CERT_CHAIN_0 SSL_CLIENT_CERT_CHAIN_0
JkEnvVar SSL_SERVER_CERT SSL_SERVER_CERT
JkWorkersFile /usr/local/java/tomcat4/conf/workers.properties
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel debug
And file ssl.conf:
IfDefine SSL
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl.crl
SSLPassPhraseDialog builtin
SSLSessionCache dbm:/usr/local/apache/logs/ssl_scache
SSLSessionCacheTimeout 300
SSLMutex file:/usr/local/apache/logs/ssl_mutex
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
SSLLog /var/log/httpd/ssl_engine_log
SSLLogLevel info
VirtualHost _default_:443
DocumentRoot /usr/local/httpd/sslhtdocs
ErrorLog /var/log/httpd/error_log
TransferLog /var/log/httpd/access_log
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /usr/local/apache/conf/ssl.crt/smurf.crt
SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/smurf.key
SSLCACertificateFile /usr/local/apache/conf/ssl.crt/ca-bundle.crt
SSLCARevocationPath /usr/local/apache/conf/ssl.crl
SSLVerifyClient require
SSLVerifyDepth 10
SSLOptions +StdEnvVars +ExportCertData
Files ~ \.(cgi|shtml|phtml|php3?)$
SSLOptions +StdEnvVars +ExportCertData
/Files
Directory /usr/local/apache/cgi-bin
SSLOptions +StdEnvVars +ExportCertData
/Directory
SetEnvIf User-Agent .*MSIE.* \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog /var/log/httpd/ssl_request_log \
%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \%r\ %b
www.semarket.com:/certiver
# Static files
Alias /certiver /usr/local/java/tomcat4/webapps/certiver
Directory /usr/local/java/tomcat4/webapps/certiver
Options Indexes FollowSymLinks
DirectoryIndex index.jsp index.html
/Directory
Location /certiver/WEB-INF/*
AllowOverride None
deny from all
/Location
Location /certiver/META-INF/*
AllowOverride None
deny from all
/Location
JkMount /certiver/* ajp13
/VirtualHost
/IfDefine
Thanks!
___
Jesus Luna Garcia
CertiVeR (U.E. Funded Project)
[EMAIL PROTECTED]
http://www.certiver.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project jakarta-tomcat-dbcp (in Module jakarta-tomcat-5) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project jakarta-tomcat-dbcp has an issue affecting its community integration. This issue affects 14 projects, and has been outstanding for 124 runs. Project State : 'Failed' The following are affected: - avalon-http-context : Avalon SVN - avalon-http-demo : Avalon SVN - avalon-http-examples : Avalon SVN - avalon-http-impl : Avalon SVN - avalon-http-server : Avalon SVN - avalon-http-servlet : Avalon SVN - avalon-http-static : Avalon SVN - avalon-http-test : Avalon SVN - avalon-planet-facilities : Avalon SVN - jakarta-tomcat-5 : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-dbcp : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-tomcat-jk : Connectors to various web servers - metro-reflector-blocks-complete : Avalon SVN Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-dbcp/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole output [naming-factory-dbcp.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-dbcp/gump_work/build_jakarta-tomcat-5_jakarta-tomcat-dbcp.html Work Name: build_jakarta-tomcat-5_jakarta-tomcat-dbcp (Type: Build) State: Failed Elapsed: 3 secs Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dcommons-collections.home=/usr/local/gump/public/workspace/jakarta-commons/collections -Dcommons-dbcp.home=/usr/local/gump/public/workspace/jakarta-commons/dbcp -Dcommons-dbcp.version=07102004 -Dtomcat-dbcp.home=/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps -Dcommons-pool.home=/usr/local/gump/public/workspace/jakarta-commons/pool build-tomcat-dbcp [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-5] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar- Buildfile: build.xml build-tomcat-dbcp: -build-tomcat-dbcp: [copy] Copying 65 files to /usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps [mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps/src/java/org/apache/tomcat/dbcp BUILD FAILED /usr/local/gump/public/workspace/jakarta-tomcat-5/build.xml:630: The following error occurred while executing this line: /usr/local/gump/public/workspace/jakarta-tomcat-5/build.xml:665: Cannot replace directory /usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps/src/java/org/apache/tomcat/dbcp with directory /usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps/src/java/org/apache/commons Total time: 3 seconds - To subscribe to this information via syndicated feeds: RSS: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-dbcp/rss.xml Atom: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-dbcp/atom.xml -- Gump E-mail Identifier (within run) #9. Produced by Gump 2.1.0-alpha-0003. [Run (1007102004, brutus:brutus-public:1007102004)] http://brutus.apache.org/gump/public/index.html http://brutus.apache.org/gump/public/options.html -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31576] New: - Remove code now in ManagerBase from DeltaManager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31576. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31576 Remove code now in ManagerBase from DeltaManager Summary: Remove code now in ManagerBase from DeltaManager Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Remove getter/setter and definition of ExpiredSessions Remove code to add jvmroute to session id and check for duplicates - this is all now done by generateSessionId - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31576] - Remove code now in ManagerBase from DeltaManager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31576. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31576 Remove code now in ManagerBase from DeltaManager --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 09:16 --- Created an attachment (id=12981) Patch to implement changes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 09:18 --- Right. Stack traces showing some kind of bad behavior with the Tomcat code would be a start. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 09:54 --- BTW, for that kind of problem, would it be possible to test using the new thread pool from Tomcat 5.5 ? Get Tomcat 5.5.3, and set strategy=ms on the Connector element. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31567] - 505 request error from .NET client
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31567.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31567
505 request error from .NET client
--- Additional Comments From [EMAIL PROTECTED] 2004-10-07 10:18 ---
I found out that the problem is with first request from .NET soap client.
After this first request following ones are okay because they don't contain
first part which doesn't have user credantials. I never had this problem with
same client but with Tomcats 4.x.
First shot contains actually two requests this is the trace of those requests:
POST /axis/services/Version HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol
1.1.4322.573)
Content-Type: text/xml; charset=utf-8
SOAPAction:
Content-Length: 545
Expect: 100-continue
Connection: Keep-Alive
Host: 127.0.0.1
?xml version=1.0 encoding=utf-8?soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:tns=http://127.0.0.1:8081/axis/services/Version;
xmlns:types=http://127.0.0.1:8081/axis/services/Version/encodedTypes;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;soap:Body
soap:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;q1:getVersion
xmlns:q1=http://axis.apache.org; //soap:Body/soap:EnvelopePOST
/axis/services/Version HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol
1.1.4322.573)
Content-Type: text/xml; charset=utf-8
SOAPAction:
Authorization: Basic YXBzOnRlc3Q=
Content-Length: 545
Expect: 100-continue
Host: 127.0.0.1:8081
?xml version=1.0 encoding=utf-8?soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:tns=http://127.0.0.1:8081/axis/services/Version;
xmlns:types=http://127.0.0.1:8081/axis/services/Version/encodedTypes;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;soap:Body
soap:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;q1:getVersion
xmlns:q1=http://axis.apache.org; //soap:Body/soap:Envelope
*** Below is trace of response from server that I get using telnet *
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm=APS Webservices
Content-Type: text/html;charset=utf-8
Content-Length: 954
Date: Thu, 07 Oct 2004 09:07:08 GMT
Server: Apache-Coyote/1.1
htmlheadtitleApache Tomcat/5.0.28 - Error report/titlestyle!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--/style
/headbodyh1HTTP Status 401 - /h1HR size=1
noshade=noshadepbtype/b Status report/ppbmessage/b
u/u/ppbdescription/b uThis request requires HTTP authentication
()./u/pHR size=1 noshade=noshadeh3Apache
Tomcat/5.0.28/h3/body/htmlHTTP/1.1 505 HTTP Version Not Supported
Date: Thu, 07 Oct 2004 09:07:08 GMT
Server: Apache-Coyote/1.1
Connection: close
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31578] New: - Update description of attributes for Standard and Persistent Managers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31578. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31578 Update description of attributes for Standard and Persistent Managers Summary: Update description of attributes for Standard and Persistent Managers Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Remove description of checkInterval from Standard and Persistent Add description of maxInactiveInterval to Standard and Persistent Add description of sessionIdLength to Standard and Persistent Move description of processExpiredFrequency from Persistent to Standard - its only implemented in StandardManager at the moment Correct minor typo in processExpiredFrequency description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31578] - Update description of attributes for Standard and Persistent Managers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31578. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31578 Update description of attributes for Standard and Persistent Managers --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 10:19 --- Created an attachment (id=12982) Patch to correct documentation as per bug description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 31567] -505 request error from .NET client
The Message has been received, you should get a response shortly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with jakarta-tomcat-connectors-jk2-2.0.[24]-src/jk/native2/configure and HP-UX 11.0
HORSTMAN, MARK A (SBCSI) wrote:
Here's a diff against jakarta-tomcat-5.0.28-src/jakarta-tomcat-connectors to fix the
problem. Configures, compiles and works for Solaris 2.8 and HP-UX 11.0 with
httpd-2.0.52:
Thanks, Could please report it in bugzilla? (To make sure it will not be
forgotten).
Cheers
Jean-Frederic
---8--- snip snip ---8---
diff -rc jakarta-tomcat-5.0.28-src/jakarta-tomcat-connectors/jk/native2/configure.in jakarta-tomcat-5.0.28-src.new/jakarta-tomcat-connectors/jk/native2/configure.in
*** jakarta-tomcat-5.0.28-src/jakarta-tomcat-connectors/jk/native2/configure.in Sat Aug 28 19:14:22 2004
--- jakarta-tomcat-5.0.28-src.new/jakarta-tomcat-connectors/jk/native2/configure.in Tue Oct 5 14:00:50 2004
***
*** 157,163
AC_SUBST(PCRE_LIBS)
dnl Check that at least one WEBSERVER has been given
! if ${TEST} -z $WEBSERVERS ; then
AC_MSG_ERROR(Cannot find any WebServer)
fi
--- 157,163
AC_SUBST(PCRE_LIBS)
dnl Check that at least one WEBSERVER has been given
! if ${TEST} ${WEBSERVERS}x = x ; then
AC_MSG_ERROR(Cannot find any WebServer)
fi
***
*** 164,181
AC_SUBST(WEBSERVERS)
dnl if --with-apr is specified, --with-apr-util must be too
! if ${TEST} ! -z $APR_BUILD -a -z $APR_UTIL_DIR; then
AC_MSG_ERROR([--with-apr and --with-apr-util must be used together])
fi
dnl apache 1.3 consistancy checks
! if ! ${TEST} -z $APACHE_HOME ; then
dnl check if apache 1.3 was selected without apr sources
! if ${TEST} -z $APR_BUILD; then
AC_MSG_ERROR([Apache 1.3 requires apr to built from source, use --with-apr and --with-apr-util])
fi
dnl make sure compiler matchs apxs
! if ${TEST} -n $APACHE_CC -a $APACHE_CC != $CC; then
AC_MSG_RESULT([error])
AC_MSG_RESULT([compiler discovered by configure: ${CC}])
AC_MSG_RESULT([compiler used by apache: ${APACHE_CC}])
--- 164,181
AC_SUBST(WEBSERVERS)
dnl if --with-apr is specified, --with-apr-util must be too
! if ${TEST} ${APR_BUILD}x != x -a ${APR_UTIL_DIR}x = x ; then
AC_MSG_ERROR([--with-apr and --with-apr-util must be used together])
fi
dnl apache 1.3 consistancy checks
! if ${TEST} ${APACHE_HOME}x != x ; then
dnl check if apache 1.3 was selected without apr sources
! if ${TEST} ${APR_BUILD}x = x ; then
AC_MSG_ERROR([Apache 1.3 requires apr to built from source, use --with-apr and --with-apr-util])
fi
dnl make sure compiler matchs apxs
! if ${TEST} ${APACHE_CC}x != x -a ${APACHE_CC}x != ${CC}x; then
AC_MSG_RESULT([error])
AC_MSG_RESULT([compiler discovered by configure: ${CC}])
AC_MSG_RESULT([compiler used by apache: ${APACHE_CC}])
***
*** 185,197
fi
dnl apache 2 consistancy checks
! if ${TEST} ! -z $APACHE2_HOME ; then
dnl check if apache 2 was selected with apr sources
! if ${TEST} ! -z $APR_BUILD; then
AC_MSG_ERROR([Use apr that comes with Apache 2, remove --with-apr])
fi
dnl make sure compiler matchs apxs
! if ${TEST} -n $APACHE2_CC -a $APACHE2_CC != $CC; then
AC_MSG_RESULT([error])
AC_MSG_RESULT([compiler discovered by configure: ${CC}])
AC_MSG_RESULT([compiler used by apache: ${APACHE2_CC}])
--- 185,197
fi
dnl apache 2 consistancy checks
! if ${TEST} ${APACHE2_HOME}x != x ; then
dnl check if apache 2 was selected with apr sources
! if ${TEST} ${APR_BUILD}x != x ; then
AC_MSG_ERROR([Use apr that comes with Apache 2, remove --with-apr])
fi
dnl make sure compiler matchs apxs
! if ${TEST} ${APACHE2_CC}x != x -a ${APACHE2_CC}x != ${CC}x; then
AC_MSG_RESULT([error])
AC_MSG_RESULT([compiler discovered by configure: ${CC}])
AC_MSG_RESULT([compiler used by apache: ${APACHE2_CC}])
diff -rc jakarta-tomcat-5.0.28-src/jakarta-tomcat-connectors/jk/support/jk_apr.m4 jakarta-tomcat-5.0.28-src.new/jakarta-tomcat-connectors/jk/support/jk_apr.m4
*** jakarta-tomcat-5.0.28-src/jakarta-tomcat-connectors/jk/support/jk_apr.m4 Sat Aug 28 19:14:24 2004
--- jakarta-tomcat-5.0.28-src.new/jakarta-tomcat-connectors/jk/support/jk_apr.m4 Tue Oct 5 13:45:00 2004
***
*** 78,84
AC_MSG_ERROR(can't locate ${tempval}/$1)
fi
! if ${TEST} ! -z $tempval ; then
APR_BUILD=apr-build
APR_CFLAGS=-I ${tempval}/include
APR_CLEAN=apr-clean
--- 78,84
AC_MSG_ERROR(can't locate ${tempval}/$1)
fi
! if ${TEST} ${tempval}x != x ; then
APR_BUILD=apr-build
APR_CFLAGS=-I ${tempval}/include
APR_CLEAN=apr-clean
***
*** 142,152
AC_MSG_ERROR(can't locate ${tempval}/$1)
DO NOT REPLY [Bug 28949] - Occasional NoClassDefFoundError for tag classes at startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28949 Occasional NoClassDefFoundError for tag classes at startup --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 11:01 --- I tried it, and it worked (I'm on Windows). I tried increasing the amount of frames too. I don't quite see how it would be different from hitting one of the pages with ab and a high concurrecy. This bug doesn't make sense to me overall: it's getting closer to INVALID. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TCKs for 5.5.3 and 5.0.29
Hi, Thanks for noting and resolving the bug. I'm hesitant to put out a new 5.5.3 build though, because that will create confusion among those who've already downloaded it. But we do have other options: - Just issue a hotfix with StandardWrapper.class, tell people to put it in server/lib. We've done this before with other single-class fixes, so there's precedent. - Issue a new 5.5.3.1 (now possible with the new versioning scheme) release. - Leave this be, keep 5.5.3 at alpha, and have this fix go only into 5.5.4. What do people think? Yoav Shapira Millennium Research Informatics -Original Message- From: Amy Roh [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 5:33 PM To: Tomcat Developers List Subject: Re: TCKs for 5.5.3 and 5.0.29 Thanks Jan for the update. I have confirmed that all JSP TCK tests pass with the latest StandardWrapper.java. I have retagged the file so the 5.5.3 release has the fix. Thanks, Amy Hi Amy, Amy Roh wrote: I ran the Servlet/JSP TCKs. They both passed on the 5.0.29 release. The Servlet TCK passed on the 5.5.3 release but the following 2 JSP TCK tests failed out of 615 tests. Test case throws exception: [BaseUrlClient] null failed! Check output for cause of failure. a.. com/sun/ts/tests/jsp/spec/core_syntax/implicitobjects/URLClient.java#ch eckC onfigTest : URLClient_checkConfigTest b.. com/sun/ts/tests/jsp/spec/tagfiles/implicitobjects/URLClient.java#check Conf igTest : URLClient_checkConfigTest I committed a fix for these 2 failures yesterday (in StandardWrapper.java): revision 1.49 date: 2004/10/06 00:54:46; author: luehe; state: Exp; lines: +1 -1 Undid previous change, as in the case where a servlet has a jsp-file and also declares some init params, as in: servlet servlet-namexxx/servlet-name jsp-file/xxx.jsp/jsp-file init-param param-namename1/param-name param-valuevalue1/param-value /init-param /servlet it needs its *own* JspServlet instance that it can initialize with its own params. Sharing of JspServlet instance is not possible in this case. Will have to come up with a better solution against loss of monitoring info (the JspServlet that handles the above jsp-file currently is not registered with JMX). I think we need to retag this file with 5.5.3. Jan Thanks, Amy - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 6:28 AM Subject: TCKs for 5.5.3 and 5.0.29 Hi, Sun folks, or anyone with access to the Servlet and JSP TCKs: can you please run them against the 5.5.3 and 5.0.29 releases when you get a chance, and post your results here? Thanks in advance ;) Both 5.0.29 and 5.5.3 pass all our internal tests without exception. Yoav Shapira Millennium Research Informatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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 e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TCKs for 5.5.3 and 5.0.29
Shapira, Yoav wrote: Hi, Thanks for noting and resolving the bug. I'm hesitant to put out a new 5.5.3 build though, because that will create confusion among those who've already downloaded it. But we do have other options: - Just issue a hotfix with StandardWrapper.class, tell people to put it in server/lib. We've done this before with other single-class fixes, so there's precedent. - Issue a new 5.5.3.1 (now possible with the new versioning scheme) release. - Leave this be, keep 5.5.3 at alpha, and have this fix go only into 5.5.4. What do people think? The issue is not critical, so proceed with 5.5.3 with a hotfix for people who really need it (so that's the first option). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.0.29 JSP compilation fails when using JDK 1.5.0
Hi, Thanks for spotting and reporting this issue. While Tomcat 5.0.x doesn't officially support J2SE 5.0, we don't want to make things worse with new releases ;) So my apologize for this issue. I'm really busy today and tomorrow at work, and then I'm traveling this weekend [it's a long holiday weekend in the US]. If someone could at least post a .diff patch to fix this, I'd be grateful and I'll try to commit it quickly. If we wait for me, this issue might have to wait a few days ;) Thanks, Yoav Shapira Millennium Research Informatics -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 3:55 PM To: Tomcat Developers List Subject: 5.0.29 JSP compilation fails when using JDK 1.5.0 Tomcat 5.0.28 compiled JSP pages when run using JDK 1.5.0 just fine (out-of-the-box). Also, 5.0.28 seems to work fine under JDK 1.5.0 in general. Tomcat 5.0.29 can no longer compile JSP pages when running under JDK 1.5.0! Given that 1.5.0 has been released and 5.0.28 works fine, I believe this is a serious regression in 5.0.29 that should by itself prevent it from getting a stable rating -- though I'd love to quickly see a 5.0.30 including a fix for this :-) [Tomcat 5.0.29 does seem to work alright under 1.5.0 if you pre-compile all JSP pages via an Ant project...] Note that the startup environment, JSP pages, etc, are identical in both cases. In both cases I use catalina.50.bat start. Also note that the JSP pages use no 1.5 features whatsoever -- I'm just trying to run with JDK 1.5.0. Also, both results hold both for development Jasper settings (fork=false, development=true, reloading=true) and production Jasper settings (fork=true, development=false, reloading=false). The symptom when this fails is the following console message: javac: target release 1.3 conflicts with default source release 1.5 I am *guessing* this may have something to do with the following change log entry: 30984 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30984: Added compilerTargetVM option to Jasper. (yoavs) -- Jess Holle This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TCKs for 5.5.3 and 5.0.29
Hi, OK, I've made the Hotfix available on the www.apache.org/dist download pages, and after giving the mirrors the usual 8 hours to pick it up, I'll post a brief announcement to the user list. Thanks, Yoav Shapira Millennium Research Informatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, October 07, 2004 8:08 AM To: Tomcat Developers List Subject: Re: TCKs for 5.5.3 and 5.0.29 Shapira, Yoav wrote: Hi, Thanks for noting and resolving the bug. I'm hesitant to put out a new 5.5.3 build though, because that will create confusion among those who've already downloaded it. But we do have other options: - Just issue a hotfix with StandardWrapper.class, tell people to put it in server/lib. We've done this before with other single-class fixes, so there's precedent. - Issue a new 5.5.3.1 (now possible with the new versioning scheme) release. - Leave this be, keep 5.5.3 at alpha, and have this fix go only into 5.5.4. What do people think? The issue is not critical, so proceed with 5.5.3 with a hotfix for people who really need it (so that's the first option). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28949] - Occasional NoClassDefFoundError for tag classes at startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28949 Occasional NoClassDefFoundError for tag classes at startup --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 12:56 --- As it is a bug that doesn't happen systematically, I understand that it is for you difficult to accept it as valid. But as I'm not the only one having the problem, I'm sure that it is not a dream (sorry a nighmare) and it sould NOT be changed to INVALID. As you can't reproduce it on your computer, perhaps can you give some indication to those wo can, so that they to find the cause? What would you look at if you could reproduce it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28949] - Occasional NoClassDefFoundError for tag classes at startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28949 Occasional NoClassDefFoundError for tag classes at startup [EMAIL PROTECTED] changed: What|Removed |Added Version|5.0.19 |5.0.28 --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 13:01 --- I'd look at the thread-safety of the relevant classloader. Multiple frames means multiple more-or-less concurrent hits, and if there's a class that needs to be loaded it means multiple concurrent loadClass-type requests. But you don't want to just synchronized everything on the classloader for no reason, as that's a performance penalty. However, that can be a useful diagnostic tool: So here's one approach, if you have the time and really want to help us out: build your own Tomcat 5.0.28 having added the synchronized keyword around every method in every Catalina classloader. Then try your test and see if the error goes away. This is just a guess, but that's what I'd try if I were in your position. It's wild overkill, but you can always strip out the synchronized places one by one afterwards. BTW, updating version from 5.0.19 to 5.0.28 on this issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config manager.xml
yoavs 2004/10/07 06:09:17 Modified:webapps/docs changelog.xml webapps/docs/config manager.xml Log: Bugzilla 31578: update Manager configuration reference. Revision ChangesPath 1.144 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.143 retrieving revision 1.144 diff -u -r1.143 -r1.144 --- changelog.xml 6 Oct 2004 18:48:05 - 1.143 +++ changelog.xml 7 Oct 2004 13:09:17 - 1.144 @@ -37,6 +37,9 @@ fix Register JSP monitoring mbean for each servlet that declares a jsp-file in web.xml. (luehe) /fix + fix +bug31578/bug: Update Manager configuration documentation. (yoavs) + /fix /changelog /subsection 1.10 +45 -18jakarta-tomcat-catalina/webapps/docs/config/manager.xml Index: manager.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/manager.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- manager.xml 5 Oct 2004 17:12:52 - 1.9 +++ manager.xml 7 Oct 2004 13:09:17 - 1.10 @@ -8,6 +8,7 @@ properties author email=[EMAIL PROTECTED]Craig R. McClanahan/author +author email=[EMAIL PROTECTED]Yoav Shapira/author titleThe Manager Component/title /properties @@ -86,11 +87,6 @@ If not specified, the default value is MD5./p /attribute - attribute name=checkInterval required=false -pThe number of seconds between checks for expired sessions -for this manager. The default value is 60 seconds./p - /attribute - attribute name=entropy required=false pA String value that is utilized when seeding the random number generator used to create session identifiers for this Manager. @@ -104,6 +100,18 @@ this Manager, or -1 (the default) for no limit./p /attribute + attribute name=maxInactiveInterval required=false +pThe initial maximum time interval, in seconds, +between client requests before a session is invalidated. A negative value +will result in sessions never timing out. If the attribute is not provided, +a default of 60 seconds is used./p + +pThis attribute provides the initial value whenever a +new session is created, but the interval may be dynamically +varied by a servlet via the +codesetMaxInactiveInterval/code method of the codeHttpSession/code object./p + /attribute + attribute name=pathname required=false pAbsolute or relative (to the work directory for this Context) pathname of the file in which session state will be preserved @@ -113,12 +121,26 @@ disabled by setting this attribute to an empty string./p /attribute + attribute name=processExpiresFrequency required=false +pFrequency of the session expiration, and related manager operations. +Manager operations will be done once for the specified amount of +backgrondProcess calls (ie, the lower the amount, the more often the +checks will occur). The minimum value is 1, and the default value is 6. +/p + /attribute + attribute name=randomClass required=false pJava class name of the codejava.util.Random/code implementation class to use. If not specified, the default value is codejava.security.SecureRandom/code./p /attribute + attribute name=sessionIdLength required=false + pThe length of session ids created by this Manager, excluding any +JVM route information used for load balancing. +The default is 16./p + /attribute + /attributes h3Persistent Manager Implementation/h3 @@ -150,11 +172,6 @@ If not specified, the default value is MD5./p /attribute - attribute name=checkInterval required=false -pThe number of seconds between checks for expired sessions -for this Manager. The default value is 60 seconds./p - /attribute - attribute name=className required=false pJava class name of the implementation to use. This class must implement the codeorg.apache.catalina.Manager/code interface. @@ -171,14 +188,6 @@ environments./p /attribute - attribute name=processExpiresFrequency required=false -pFrequency of the session expiration, and related manager operations. -Manager operations will be done once for
DO NOT REPLY [Bug 31578] - Update description of attributes for Standard and Persistent Managers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31578. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31578 Update description of attributes for Standard and Persistent Managers [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 13:11 --- Patch applied. Thanks for submitting it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28949] - Occasional NoClassDefFoundError for tag classes at startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28949 Occasional NoClassDefFoundError for tag classes at startup --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 13:12 --- If this was the case, then you would get problems for servlet based application as well, or for JSPs which use helper classes. Actually, since a frame is only a way to do a few concurrent requests, you'd get problems during load tests (for ex on the date.jsp example). Syncing everything in the classloader is a bad test IMO. I think it will greatly affect the capability of the server to run concurrent stuff, and as a result it will change the behavior of many other components. Let's not waste time on this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31576] - Remove code now in ManagerBase from DeltaManager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31576. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31576 Remove code now in ManagerBase from DeltaManager [EMAIL PROTECTED] changed: What|Removed |Added Component|Catalina:Modules|Catalina:Cluster --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 13:15 --- Changing component slightly to Cluster from Modules. Thanks for submitting this patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 13:13 --- I wouldn't be quick to conclude this will disappear from Tomcat 5.5. Tomcat 5.5. still uses commons-logging (in fact, more heavily than before), and still locates the commons-logging jar on the bin classpath, because it uses it from the very startup of the server. Tomcat 5.0 and 5.5 both require commons- logging. What your investigation reveals, I think, is that the version of commons-logging used by the webapp must be the same as that uses by Tomcat (which uses the latest stable commons-logging build). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31304] - NoClassDefFoundError: org/apache/commons/collections/CursorableLinkedList
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31304. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31304 NoClassDefFoundError: org/apache/commons/collections/CursorableLinkedList [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 13:33 --- I took your WAR, and modified it for my environment. The only changes were the JDBC driver class (I have Oracle locally, so oracle.jdbc.driver.OracleDriver), and of course database URL, username, and password. Whether I deploy as a packed WAR, or as an expanded directory structure, both dbtest.jsp and dbtestdirect.jsp work for me. (I had to create a dummy table testdata of course to match your query). I get no errors at all, much less that collections error you quote. This was on a clean, new 5.0.28 installation, using Sun JDK 1.4.2 on Solaris 8. I repeated the same thing on Windows 2000, same results. It all works. So I'm closing this item as WORKSFORME. If I were you, I'd try it with a clean installation, as there's no other explanation for what you're seeing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31499] - Contributing catalina launcher for OpenVMS Alpha
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31499. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31499 Contributing catalina launcher for OpenVMS Alpha [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 13:36 --- Changing severity to enhancement. Thanks for your contribution! We'll just find the right place and add it ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Location for contributed startup/shutdown scripts
Hi, We've got a few contributed scripts entered as Bugzilla enhancement items (31447, 31499). They're startup/shutdown scripts for GNU/Linux and OpenVMS. The question is, where in CVS do we put these? I don't want to simply put them in jakarta-tomcat-catalina/catalina/src/bin, and then packaged in $CATALINA_HOME/bin, because that implies we wrote and maintain them. Rather, I'd like to put them in some sort of jakarta-tomcat-contrib repository, with a README that says these scripts are not written, maintained, or supported by us. What do people think? Yoav Shapira Millennium Research Informatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Costin Manolache wrote: No, removing jk2.properties - and removing JkMX - is a good thing. I'll check in the webapp code, it's easier to talk about code - if people don't like it, feel free to -1 :-) In the same spirit, I think we could imagine having a webapp for dynamic configuration of java logging. Rmy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 13:42 --- I've commented a while ago on how to properly package commons-logging: - commons-logging-api goes in the system classloader (it will go first in the delegation order) - put the necessary commons-logging wrapper classes for the logger you're using at the same spot as your logger JAR This seemed to avoid problems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28949] - Occasional NoClassDefFoundError for tag classes at startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28949 Occasional NoClassDefFoundError for tag classes at startup --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 14:08 --- For info: I've just performed a test on an older computer with Windows 2000. Downloaded Tomcat 5.0.28 zip version and placed the small test application attached to this bug in the webapps dir. I've performed 20 times startup.bat, called the default page of the webapp in the browser and then shutdown.bat. In 12 cases everything was correct and in 8 cases one of the frame had the NoClassDefFoundError exception. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28949] - Occasional NoClassDefFoundError for tag classes at startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28949 Occasional NoClassDefFoundError for tag classes at startup --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 14:21 --- I am sure this is a bug. There is just too much documentation and too many disparate reports for that not to be the case. I am also not sure what INVALID means, but if it means that the bug does not exist, that is not right. The bug does exist. So, I assume INVALID does not mean that. I clearly get the undesired behavior both with Marc's test war and with my own application. I should mention that I have different frame based pages. Some of the pages have this problem on a consistent basis. Others never have this problem. Why that would be is a mystery to me. The only apparent difference between the pages is the number of times the custom taglib is used. On the page with twelve uses of the taglib, the behavior is clear and persistent: nearly everytime but not quite. Why that should make a difference is not clear to me. But, that is the only difference I see. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28949] - Occasional NoClassDefFoundError for tag classes at startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28949 Occasional NoClassDefFoundError for tag classes at startup --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 14:33 --- Created an attachment (id=12984) I tested Marc's war 7 times and got the error everytime on a Compaq Presario 2500 running XP Home and Tomcat 5.0 as previously indicated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31581] New: - Tomcat Manager deploys the web application twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31581. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31581 Tomcat Manager deploys the web application twice Summary: Tomcat Manager deploys the web application twice Product: Tomcat 5 Version: 5.0.28 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I deploy a web application using the Tomcat Manager's html interface or Tomcat Manager directly e.g. http://localhost:8080/manager/deploy?config=file:/home/xxx/XXX/build/web/META-INF/context.xmlwar=file:/home/xxx/XXX/build/web/ the application is being deployed twice. I can get rid of the double deploy by setting the host element's autoDeploy property to false in the server.xml file as recomended in Tomcat's documentation, this however is not the ideal solution. I think that Tomcat Manager should deploy correctly out of the box, without any necessary changes of the default settings. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31581] - Tomcat Manager deploys the web application twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31581. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31581 Tomcat Manager deploys the web application twice [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 14:43 --- You're not using this the right way. I don't understand how you get away with not specifying the path parameter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28949] - Occasional NoClassDefFoundError for tag classes at startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28949 Occasional NoClassDefFoundError for tag classes at startup --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 14:54 --- Yoav, you mean in all 3: org.apache.catalina.loader.StandardClassLoader org.apache.catalina.loader.WebappClassLoader org.apache.jasper.servlet.JasperLoader or are there any other class loaders? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28949] - Occasional NoClassDefFoundError for tag classes at startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28949 Occasional NoClassDefFoundError for tag classes at startup --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 14:58 --- Try Tomcat 5.5.3 first. Then I think you shouldn't get guidance if you expect to actually get a fresh look at what this issue could be. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31581] - Tomcat Manager deploys the web application twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31581. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31581 Tomcat Manager deploys the web application twice --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 15:31 --- The path parameter is specified in the supplied context.xml file. Correct me if I am wrong, but according to http://jakarta.apache.org/tomcat/tomcat-5.0-doc/manager-howto.html - the Install using a Context configuration .xml file section, this should be a correct way of use. Am I missing anything? Sorry if I do. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Dominik Drzewiecki wrote: I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html cut Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. /cut I'm running both with the same usename on Windows, and it doesn't work. Since it's Windows and I like to be able to do stuff, I of course run with root privileges. Seems to me it would work on Unix, but is currently broken on Windows (I use XP pro SP 2), or something. Over a TCP port, it works good. I couldn't find a comprehensive guide on all these nice system properties, while there's tons of docs on the new command line commands. If I use the service, which runs with the SYSTEM account, it of course doesn't work any better ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Remy Maucherat wrote: Dominik Drzewiecki wrote: I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html cut Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. /cut I'm running both with the same usename on Windows, and it doesn't work. Since it's Windows and I like to be able to do stuff, I of course run with root privileges. Seems to me it would work on Unix, but is currently broken on Windows (I use XP pro SP 2), or something. Over a TCP port, it works good. I couldn't find a comprehensive guide on all these nice system properties, while there's tons of docs on the new command line commands. If I use the service, which runs with the SYSTEM account, it of course doesn't work any better ;) For those interested in not wasting their time the way I just did, I just found this: http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html quote *Limitation*: On Windows, for security reasons, local monitoring and management is only supported if your default Windows temporary directory is on a file system that supports persistent access control lists (for example, on an NTFS file system). It is not supported on a FAT file system that provide insufficient access controls. /quote I obviously use FAT32, and I have to add that this limitation is quite stupid. No multi user setup would run FAT and expect security, so you are fine allowing anything you want on FAT (at least, I can't see how it makes stuff more secure). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
In general the same-user, same-machine stuff works great (including with Tomcat 5) if you specify -Dcom.sun.management.jmxremote as part of the command line. This is without any special web app or such. What I really want to see is a nice bit of code that allows you to fire up a JMX RMI connector that: * Finds the first free port in a range (e.g. assuming you have a number of slave processes, this does not apply to Tomcat as it does not have such logic for it AJP port, etc). * Support user/password and SSL * Does not rely on implementation internals, i.e. requiring Java 5 is fine, but having hooks into sun.* or MX4J or whatever classes is no good -- Jess Holle Remy Maucherat wrote: Dominik Drzewiecki wrote: I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html cut Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. /cut I'm running both with the same usename on Windows, and it doesn't work. Since it's Windows and I like to be able to do stuff, I of course run with root privileges. Seems to me it would work on Unix, but is currently broken on Windows (I use XP pro SP 2), or something. Over a TCP port, it works good. I couldn't find a comprehensive guide on all these nice system properties, while there's tons of docs on the new command line commands. If I use the service, which runs with the SYSTEM account, it of course doesn't work any better ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Remy Maucherat wrote: For those interested in not wasting their time the way I just did, I just found this: http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html quote *Limitation*: On Windows, for security reasons, local monitoring and management is only supported if your default Windows temporary directory is on a file system that supports persistent access control lists (for example, on an NTFS file system). It is not supported on a FAT file system that provide insufficient access controls. /quote I obviously use FAT32, and I have to add that this limitation is quite stupid. No multi user setup would run FAT and expect security, so you are fine allowing anything you want on FAT (at least, I can't see how it makes stuff more secure). Ah... All my file systems are NTFS... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4690] - sessions not scoped according to spec section 7.3
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=4690. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=4690 sessions not scoped according to spec section 7.3 --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 16:30 --- I just voted for this bug and wanted to voice a comment as well. uPortal 2.3 and higher uses the Pluto JSR-168 portlet container in it's framework and is running into this bug as well. This issue is more pronounced in a portal environment since the abaility to share a session in the manner described in the bug is essential for a portlet to securly pass session scoped data to a servlet outside of the portal to initiate a download or similar action. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4690] - sessions not scoped according to spec section 7.3
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=4690. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=4690 sessions not scoped according to spec section 7.3 --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 16:32 --- It's not my fault if the portal JSR decided to make asumptions about the servlet specification, and then, to be sure that they would piss off people, included their dubious asumptions in their TCK. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31581] - Tomcat Manager deploys the web application twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31581. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31581 Tomcat Manager deploys the web application twice --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 16:54 --- The behavior got clarified in the new code then: you have to use a path parameter, and the path attribute which might have been specified in your context.xml file will be ignored. This way, the auto deployer will not be confused. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Todo list
Remy Maucherat wrote: - Decent default java.util.logging configuration I don't see any sensible configuration given what the standard handlers are (limited rotation options, little possibility of avoiding hardcoding logfiles paths, etc). Also, the reload operation is not exposed to JMX (other operations are exposed, however). So I'll add a default configuration file from the JRE, where we'll add some example catagory names to help users, but that's unfortunately all that can be done by default. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TCKs for 5.5.3 and 5.0.29
Sounds good to me. :-) Thanks, Amy - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 07, 2004 5:47 AM Subject: RE: TCKs for 5.5.3 and 5.0.29 Hi, OK, I've made the Hotfix available on the www.apache.org/dist download pages, and after giving the mirrors the usual 8 hours to pick it up, I'll post a brief announcement to the user list. Thanks, Yoav Shapira Millennium Research Informatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, October 07, 2004 8:08 AM To: Tomcat Developers List Subject: Re: TCKs for 5.5.3 and 5.0.29 Shapira, Yoav wrote: Hi, Thanks for noting and resolving the bug. I'm hesitant to put out a new 5.5.3 build though, because that will create confusion among those who've already downloaded it. But we do have other options: - Just issue a hotfix with StandardWrapper.class, tell people to put it in server/lib. We've done this before with other single-class fixes, so there's precedent. - Issue a new 5.5.3.1 (now possible with the new versioning scheme) release. - Leave this be, keep 5.5.3 at alpha, and have this fix go only into 5.5.4. What do people think? The issue is not critical, so proceed with 5.5.3 with a hotfix for people who really need it (so that's the first option). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29695] - regression in SSL cipher strength
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29695. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29695 regression in SSL cipher strength --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 17:45 --- interestingly, when moving to ibm_j2skd_142 as JVM and setting sslProtocol=SSL algorithm=IbmX509 Mozilla gets back up to 256 bit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java
luehe 2004/10/07 11:09:10 Modified:catalina/src/share/org/apache/catalina/core StandardWrapper.java Log: Added comment Revision ChangesPath 1.51 +5 -1 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java Index: StandardWrapper.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v retrieving revision 1.50 retrieving revision 1.51 diff -u -r1.50 -r1.51 --- StandardWrapper.java 6 Oct 2004 17:10:24 - 1.50 +++ StandardWrapper.java 7 Oct 2004 18:09:10 - 1.51 @@ -338,6 +338,10 @@ String oldJspFile = this.jspFile; this.jspFile = jspFile; support.firePropertyChange(jspFile, oldJspFile, this.jspFile); + +// Each jsp-file needs to be represented by its own JspServlet and +// corresponding JspMonitoring mbean, because it may be initialized +// with its own init params isJspServlet = true; } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs monitoring.xml logging.xml project.xml index.xml
remm2004/10/07 11:16:05 Modified:webapps/docs project.xml index.xml Added: webapps/docs monitoring.xml logging.xml Log: - Add skeleton for JMX and logging docs. Revision ChangesPath 1.24 +3 -0 jakarta-tomcat-catalina/webapps/docs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/project.xml,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- project.xml 1 Sep 2004 22:04:27 - 1.23 +++ project.xml 7 Oct 2004 18:16:05 - 1.24 @@ -39,6 +39,9 @@ item name=18) Clustering href=cluster-howto.html/ item name=19) Load Balancer href=balancer-howto.html/ item name=20) Connectors href=connectors.html/ +item name=21) Monitoring and Management + href=monitoring.html/ +item name=22) Logginghref=logging.html/ /menu menu name=Reference 1.20 +4 -0 jakarta-tomcat-catalina/webapps/docs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/index.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- index.xml 23 Sep 2004 06:55:25 - 1.19 +++ index.xml 7 Oct 2004 18:16:05 - 1.20 @@ -97,6 +97,10 @@ Configuring, using, and extending the load balancer application./li lia href=connectors.htmlstrongConnectors/strong/a - Connectors available in Tomcat, and native web server integration./li +lia href=monitoring.htmlstrongMonitoring and Management/strong/a - +Enabling JMX Remote support, and using tools to monitor and manage Tomcat./li +lia href=logging.htmlstrongLogging/strong/a - +Confuguring logging in Tomcat./li /ol 1.1 jakarta-tomcat-catalina/webapps/docs/monitoring.xml Index: monitoring.xml === ?xml version=1.0? !DOCTYPE document [ !ENTITY project SYSTEM project.xml ] document url=monitoring.html project; properties author email=[EMAIL PROTECTED]Remy Maucherat/author titleMonitoring and Managing Tomcat/title /properties body section name=Introduction /section section name=Enabling JMX Remote pThe Sun website includes the list of options and how to configure JMX Remote on Java 5: a href=http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html; http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html/a. /p /section section name=Monitoring /section section name=Management /section /body /document 1.1 jakarta-tomcat-catalina/webapps/docs/logging.xml Index: logging.xml === ?xml version=1.0? !DOCTYPE document [ !ENTITY project SYSTEM project.xml ] document url=logging.html project; properties author email=[EMAIL PROTECTED]Remy Maucherat/author titleLogging in Tomcat/title /properties body section name=Introduction /section section name=java.util.logging /section section name=log4j /section /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31587] New: - Problems with jakarta-tomcat-connectors/jk/native2/configure and HP-UX 11.0
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31587.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31587
Problems with jakarta-tomcat-connectors/jk/native2/configure and HP-UX 11.0
Summary: Problems with jakarta-tomcat-
connectors/jk/native2/configure and HP-UX 11.0
Product: Tomcat 5
Version: 5.0.28
Platform: HP
OS/Version: HP-UX
Status: NEW
Severity: Normal
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I cannot get the jakarta-tomcat-connectors/jk/native2/configure script to work
without errors under HP-UX 11.0. The problems occur when the script does
something like:
if ${TEST} ${apxs_support} = false ; then
or
if ${TEST} -z $tempval ; then
and the variable being tested has not been previously set. With 'set -x' turned
on to assist in debugging, the first test gives an error of:
+ /usr/bin/test = false
/usr/bin/test[7]: test: Specify a parameter with this command.
while the second ones gives:
+ /usr/bin/test -z
/usr/bin/test[7]: test: Specify a parameter with this command.
This style of variable checking is used extensively throughout the script.
Short of hacking each one to be something like:
if ${TEST} ${apxs_support}x = falsex ; then
or
if ${TEST} ${tempval}x = x ; then
does anyone have any ideas how I can get around this? Is this an autoconf
issue? I've tried re-generating the configure script using buildconf.sh by
installing GNU autoconf-2.58, automake-1.9.2 and libtool-1.5.8 but I get the
same problems.
DIFF PATCH TO FIX
---8--- snip snip ---8---
diff -rc
jakarta-tomcat-5.0.28-src/jakarta-tomcat-connectors/jk/native2/configure.in
jakarta-tomcat-5.0.28-src.new/jakarta-tomcat-connectors/jk/native2/configure.in
*** jakarta-tomcat-5.0.28-src/jakarta-tomcat-connectors/jk/native2/configure.in
Sat Aug 28 19:14:22 2004
---
jakarta-tomcat-5.0.28-src.new/jakarta-tomcat-connectors/jk/native2/configure.in
Tue Oct 5 14:00:50 2004
***
*** 157,163
AC_SUBST(PCRE_LIBS)
dnl Check that at least one WEBSERVER has been given
! if ${TEST} -z $WEBSERVERS ; then
AC_MSG_ERROR(Cannot find any WebServer)
fi
--- 157,163
AC_SUBST(PCRE_LIBS)
dnl Check that at least one WEBSERVER has been given
! if ${TEST} ${WEBSERVERS}x = x ; then
AC_MSG_ERROR(Cannot find any WebServer)
fi
***
*** 164,181
AC_SUBST(WEBSERVERS)
dnl if --with-apr is specified, --with-apr-util must be too
! if ${TEST} ! -z $APR_BUILD -a -z $APR_UTIL_DIR; then
AC_MSG_ERROR([--with-apr and --with-apr-util must be used together])
fi
dnl apache 1.3 consistancy checks
! if ! ${TEST} -z $APACHE_HOME ; then
dnl check if apache 1.3 was selected without apr sources
! if ${TEST} -z $APR_BUILD; then
AC_MSG_ERROR([Apache 1.3 requires apr to built from source, use --with-apr and
--with-apr-util])
fi
dnl make sure compiler matchs apxs
! if ${TEST} -n $APACHE_CC -a $APACHE_CC != $CC; then
AC_MSG_RESULT([error])
AC_MSG_RESULT([compiler discovered by configure: ${CC}])
AC_MSG_RESULT([compiler used by apache: ${APACHE_CC}])
--- 164,181
AC_SUBST(WEBSERVERS)
dnl if --with-apr is specified, --with-apr-util must be too
! if ${TEST} ${APR_BUILD}x != x -a ${APR_UTIL_DIR}x = x ; then
AC_MSG_ERROR([--with-apr and --with-apr-util must be used together])
fi
dnl apache 1.3 consistancy checks
! if ${TEST} ${APACHE_HOME}x != x ; then
dnl check if apache 1.3 was selected without apr sources
! if ${TEST} ${APR_BUILD}x = x ; then
AC_MSG_ERROR([Apache 1.3 requires apr to built from source, use --with-apr and
--with-apr-util])
fi
dnl make sure compiler matchs apxs
! if ${TEST} ${APACHE_CC}x != x -a ${APACHE_CC}x != ${CC}x; then
AC_MSG_RESULT([error])
AC_MSG_RESULT([compiler discovered by configure: ${CC}])
AC_MSG_RESULT([compiler used by apache: ${APACHE_CC}])
***
*** 185,197
fi
dnl apache 2 consistancy checks
! if ${TEST} ! -z $APACHE2_HOME ; then
dnl check if apache 2 was selected with apr sources
! if ${TEST} ! -z $APR_BUILD; then
AC_MSG_ERROR([Use apr that comes with Apache 2, remove --with-apr])
fi
dnl make sure compiler matchs apxs
! if ${TEST} -n $APACHE2_CC -a $APACHE2_CC != $CC; then
AC_MSG_RESULT([error])
AC_MSG_RESULT([compiler discovered by configure: ${CC}])
AC_MSG_RESULT([compiler used by apache: ${APACHE2_CC}])
--- 185,197
fi
dnl apache 2 consistancy checks
! if ${TEST} ${APACHE2_HOME}x != x ; then
dnl check if apache 2 was selected with apr sources
! if ${TEST} ${APR_BUILD}x != x ; then
AC_MSG_ERROR([Use apr that comes with Apache 2, remove --with-apr])
fi
dnl make sure compiler matchs apxs
! if ${TEST} ${APACHE2_CC}x != x -a ${APACHE2_CC}x != ${CC}x;
DO NOT REPLY [Bug 31587] - Problems with jakarta-tomcat-connectors/jk/native2/configure and HP-UX 11.0
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31587. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31587 Problems with jakarta-tomcat-connectors/jk/native2/configure and HP-UX 11.0 [EMAIL PROTECTED] changed: What|Removed |Added Component|Unknown |Native:Integration --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 19:39 --- Changing cmoopnent to Native:Integration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31587] - Problems with jakarta-tomcat-connectors/jk/native2/configure and HP-UX 11.0
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31587. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31587 Problems with jakarta-tomcat-connectors/jk/native2/configure and HP-UX 11.0 --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 19:47 --- Created an attachment (id=12985) Oops... sorry about the size of the original patch report. I didn't know you could provide an attachment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Jess Holle wrote: In general the same-user, same-machine stuff works great (including with Tomcat 5) if you specify -Dcom.sun.management.jmxremote as part of the command line. Again - remember not everyone is using Sun JDK1.5 implementation. My understanding is Macs don't have 1.5 yet, neither most other platforms. This is without any special web app or such. What I really want to see is a nice bit of code that allows you to fire up a JMX RMI connector that: * Finds the first free port in a range (e.g. assuming you have a number of slave processes, this does not apply to Tomcat as it does not have such logic for it AJP port, etc). * Support user/password and SSL * Does not rely on implementation internals, i.e. requiring Java 5 is fine, but having hooks into sun.* or MX4J or whatever classes is no good That's not hard to add. You actually need the first free port in the range for rmiregistry - or you can use existing rmiregistry if one is found. You need different rmi names - that's easier. Adding user/pass/ssl is not hard - if someone has the itch it shouldn't be a problem. javax.man.remote has all that's needed AFAIK. IF you look at jmxremote webapp that I checked in - there is no mx4j or sun code, just plain javax. Costin -- Jess Holle Remy Maucherat wrote: Dominik Drzewiecki wrote: I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html cut Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. /cut I'm running both with the same usename on Windows, and it doesn't work. Since it's Windows and I like to be able to do stuff, I of course run with root privileges. Seems to me it would work on Unix, but is currently broken on Windows (I use XP pro SP 2), or something. Over a TCP port, it works good. I couldn't find a comprehensive guide on all these nice system properties, while there's tons of docs on the new command line commands. If I use the service, which runs with the SYSTEM account, it of course doesn't work any better ;) Rémy - 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: JMX Remote connection
Costin Manolache wrote: Jess Holle wrote: In general the same-user, same-machine stuff works great (including with Tomcat 5) if you specify -Dcom.sun.management.jmxremote as part of the command line. Again - remember not everyone is using Sun JDK1.5 implementation. My understanding is Macs don't have 1.5 yet, neither most other platforms. Sorry. Windows, Solaris, and Linux do, and HPUX will soon. AIX and Mac OS X will lag as always, though if recent history is any guide AIX will lag further than Mac OS X. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Todo list
Remy Maucherat wrote: Remy Maucherat wrote: - Decent default java.util.logging configuration I don't see any sensible configuration given what the standard handlers are (limited rotation options, little possibility of avoiding hardcoding logfiles paths, etc). Also, the reload operation is not exposed to JMX (other operations are exposed, however). So I'll add a default configuration file from the JRE, where we'll add some example catagory names to help users, but that's unfortunately all that can be done by default. Rémy And some people are using log4j :-) I just can't live with the 2-line per log and the formated date, and I found no way to change this ( except writting my own formatter ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31590] New: - Problem deploying a WAR with a META-INF/context.xml file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31590 Problem deploying a WAR with a META-INF/context.xml file Summary: Problem deploying a WAR with a META-INF/context.xml file Product: Tomcat 5 Version: 5.5.3 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I deploy the war in http://svn.cargo.codehaus.org/cargo/trunk/samples/java/src/testinput/tomcat/ it seems that Tomcat 5.5.x where x=3 does not take into account the context.xml file. The war is deployed with a tomcat-context context (instead of tomcatcontext). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31590] - Problem deploying a WAR with a META-INF/context.xml file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31590 Problem deploying a WAR with a META-INF/context.xml file --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 21:27 --- I think there's something bad with your WAR, but your website doesn't work so I can't tell for sure. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31590] - Problem deploying a WAR with a META-INF/context.xml file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31590 Problem deploying a WAR with a META-INF/context.xml file --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 21:33 --- I forgot to mention: In addition to attaching the WAR to the bug report, please also specify how you deploy the said WAR (it's quite hard to guess). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 21:33 --- I am still not happy with the portability implications of this. I still think it would be better for the 'fix' to be part of the application (and hence be portable) rather than part of the container (not portable and may require changes to app between containers depending on how each handles this). That being said, if all other options are inappropriate then I am prepared to consider this patch. Therefore I'd would appreciate it you would consider the following options. 1. I understand that some developers want to include HTML directly. However, given that this has i18n problems and i18n is obviously important to you why not tell your developers that they can't do this and should convert to JSPs? It is a change to the file name, adding a encoding directive and changing references from xxx.html to xxx.jsp. This would be trivial to automate. 2. How about using -Dfile.encoding=... at the JVM level? 3. The patch (and option 2 above) assumes that every file has the same encoding. Is this always the case? Might different files in different apps have different encodings? If so, you could specify a modified version of the default servlet in your web application to handle .html files. With this option you could even handle different static file encodings within the same web app. This option would give you a lot of flexibility (which may or may not be useful to you). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31592] New: - storage format of digested realm passwords depends on default charset
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31592. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31592 storage format of digested realm passwords depends on default charset Summary: storage format of digested realm passwords depends on default charset Product: Tomcat 5 Version: 5.0.0 Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The documentation specifies the digest algorithms which can be used to avoid storing plain text passwords. Unfortunately passwords are strings and the input of digest algorithms are bytes, but the conversion between the two - the charset encoding to be used - is not specified. Looking at the source of org.apache.tomcat.modules.aaa.RealmBase it turns out that it uses the system default charset encoding, which is usually a bad idea for a server software. E.g. moving the server to another machine or using a second server with different locale renders the user database invalid. The best solution would be to explicitly specify an encoding, e.g. UTF-8. But at this moment this may break existing configurations. Another solution is to add an additional parameter to each realm implementation and the command line utility, in which the administrator can specify the encoding. The default of this parameter must be encode using the platform's default charset, in order to not break compatiblity. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4690] - sessions not scoped according to spec section 7.3
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=4690. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=4690 sessions not scoped according to spec section 7.3 --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 23:29 --- It seems to me that the only assumption that was made was that sessions would work normally when used from a cross-context dispatcher. Why is this such a dubious assumption? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa RealmBase.java
billbarker2004/10/07 19:53:38
Modified:src/share/org/apache/tomcat/modules/aaa RealmBase.java
Log:
Add the option to specify the encoding for use in digesting passwords.
To use, specify the attribute digestEncoding=UTF-8 on your Realm element.
Fix for Bug #31592
Revision ChangesPath
1.5 +35 -7
jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/RealmBase.java
Index: RealmBase.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/RealmBase.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- RealmBase.java25 Feb 2004 06:52:40 - 1.4
+++ RealmBase.java8 Oct 2004 02:53:38 - 1.5
@@ -21,6 +21,7 @@
package org.apache.tomcat.modules.aaa;
+import java.io.UnsupportedEncodingException;
import java.security.MessageDigest;
import java.security.Principal;
@@ -68,6 +69,11 @@
protected String digest = No;
/**
+ * The encoding to use for password digesting.
+ */
+protected String digestEncoding=null;
+
+/**
* Gets the digest algorithm used for credentials in the database.
* Should be a value that MessageDigest accepts for algorithm or No.
* No is the Default.
@@ -88,18 +94,40 @@
}
/**
+ * Get the encoding to use for digesting passwords.
+ * If codenull/code then the System encoding is used.
+ */
+public String getDigestEncoding() {
+ return digestEncoding;
+}
+
+/**
+ * Set the encoding to use for digesting passwords.
+ * if codenull/code then the System encoding is used.
+ */
+public void setDigestEncoding(String de) {
+ digestEncoding = de;
+}
+
+/**
* Digest password using the algorithm especificied and
* convert the result to a corresponding hex string.
* If exception, the plain credentials string is returned
* @param credentials Password or other credentials to use in authenticating
this username
* @param algorithm Algorithm used to do the digest
*/
-public static final String digest(String credentials,String algorithm ) {
+public static final String digest(String credentials,String algorithm, String
encoding ) {
try {
// Obtain a new message digest with MD5 encryption
MessageDigest md =
(MessageDigest)MessageDigest.getInstance(algorithm).clone();
// encode the credentials
-md.update(credentials.getBytes());
+ byte [] credBytes = null;
+ if(encoding != null) {
+ credBytes = credentials.getBytes(encoding);
+ } else {
+ credBytes = credentials.getBytes();
+ }
+md.update(credBytes);
// obtain the byte array from the digest
byte[] dig = md.digest();
// convert the byte array to hex string
@@ -121,7 +149,7 @@
if (args[0].equalsIgnoreCase(-a)) {
for (int i = 2; i args.length; i++) {
System.out.print(args[i] + :);
-System.out.println(digest(args[i], args[1]));
+System.out.println(digest(args[i], args[1], null));
}
}
}
@@ -135,7 +163,7 @@
if( digest.equals() || digest.equalsIgnoreCase(No)){
return credentials;
} else {
-return digest(credentials,digest);
+return digest(credentials,digest, digestEncoding);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31592] - storage format of digested realm passwords depends on default charset
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31592. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31592 storage format of digested realm passwords depends on default charset --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 02:59 --- Assuming that you meant to file this against Tomcat 3 (which is where o.a.t.m.aaa.RealmBase lives :), this is fixed now in the CVS. The Realm now has a 'digestEncoding' attribute that can be used to specify the charset (defaulting to the default charset, for BC). Leaving the bug open, incase you really did mean Tomcat 5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31594] New: - Change server.xml default Connector address to localhost + AJP docs tweak
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31594. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31594 Change server.xml default Connector address to localhost + AJP docs tweak Summary: Change server.xml default Connector address to localhost + AJP docs tweak Product: Tomcat 5 Version: 5.0.29 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] My company (an application security services firm) was recently asked by a very large institution to review Tomcat's code base and deployment defaults, in preparation for broader use by the client. One of our recommendations was to change the address of AJP connectors from * to 127.0.0.1. This got me thinking... I'd like to suggest that ALL of Tomcat's Connectors be set to listen on loopback by default. This would be perfect for development and testing purposes on a single machine, but if customers wanted to use it in production, all that would be needed is a one-line change. I have submitted patches for server.xml, server-minimal.xml, and to the docs (http.xml and ajp.xml) explaining the defaults. I have also, for good measure, added a note about minProcessors/ maxProcessors in the AJP docs because they were missing and really ought to be there. In my view default configurations are a safety issue; default-deny seems prudent. If folks feel this is too aggressive for the HTTP Connector, could we at least consider locking down AJP? In 90% of the cases I see, customers put Apache and Tomcat on the same box. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31594] - Change server.xml default Connector address to localhost + AJP docs tweak
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31594. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31594 Change server.xml default Connector address to localhost + AJP docs tweak --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 04:43 --- Created an attachment (id=12989) PATCH ajp.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31594] - Change server.xml default Connector address to localhost + AJP docs tweak
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31594. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31594 Change server.xml default Connector address to localhost + AJP docs tweak --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 04:43 --- Created an attachment (id=12990) PATCH to http.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31594] - Change server.xml default Connector address to localhost + AJP docs tweak
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31594. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31594 Change server.xml default Connector address to localhost + AJP docs tweak --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 04:44 --- Created an attachment (id=12991) PATCH for server.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31594] - Change server.xml default Connector address to localhost + AJP docs tweak
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31594. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31594 Change server.xml default Connector address to localhost + AJP docs tweak --- Additional Comments From [EMAIL PROTECTED] 2004-10-08 04:44 --- Created an attachment (id=12992) PATCH for server-minimal.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
