[GUMP@lsd]: jakarta-tomcat-5/jakarta-tomcat-5 failed

2004-04-30 Thread bobh
To whom it may engage...

This is an automated request, but not an unsolicited one. For help 
understanding the request please visit 
http://gump.apache.org/nagged.html, 
and/or contact [EMAIL PROTECTED]

Project jakarta-tomcat-5 has an issue affecting its community integration, and has 
been outstanding for 20 runs.
The current state is 'Failed', for reason 'Build Failed'

Full details are available at:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/jakarta-tomcat-5/index.html
That said, some snippets follow:


Gump provided these annotations:
 - Info - Jar [servlets-default.jar] identifier set to jar basename: [servlets-default]
 - Info - Jar [naming-common.jar] identifier set to jar basename: [naming-common]
 - Info - Jar [naming-resources.jar] identifier set to jar basename: [naming-resources]
 - Info - Jar [catalina.jar] identifier set to jar basename: [catalina]
 - Info - Jar [bootstrap.jar] identifier set to jar basename: [bootstrap]
 - Info - Jar [servlets-common.jar] identifier set to jar basename: [servlets-common]
 - Info - Jar [servlets-invoker.jar] identifier set to jar basename: [servlets-invoker]
 - Info - Dependency on javamail exists, no need to add for property mail.jar.
 - Info - Dependency on jaf exists, no need to add for property activation.jar.
 - Info - Dependency on jakarta-servletapi-5-servlet exists, no need to add for 
property servlet-api.jar.
 - Info - Dependency on jakarta-servletapi-5-jsp exists, no need to add for property 
jsp-api.jar.
 - Info - Dependency on xml-xerces exists, no need to add for property xercesImpl.jar.
 - Info - Dependency on xml-xerces exists, no need to add for property 
xmlParserAPIs.jar.
 - Info - Dependency on jakarta-tomcat-util exists, no need to add for property 
tomcat-util.jar.
 - Info - Dependency on commons-el exists, no need to add for property commons-el.jar.
 - Info - Dependency on commons-logging exists, no need to add for property 
commons-logging-api.jar.
 - Info - Dependency on commons-modeler exists, no need to add for property 
commons-modeler.jar.
 - Info - Dependency on ant exists, no need to add for property ant.home.
 - Info - Dependency on jsse exists, no need to add for property jsse.home.
 - Info - Dependency on jmx exists, no need to add for property jmx.home.
 - Info - Dependency on jmx exists, no need to add for property jmx.jar.
 - Info - Dependency on jmx exists, no need to add for property jmx-tools.jar.
 - Info - Dependency on jndi exists, no need to add for property jndi.home.
 - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.home.
 - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.jar.
 - Info - Dependency on javamail exists, no need to add for property mail.home.
 - Info - Dependency on jakarta-tomcat-coyote exists, no need to add for property 
tomcat-coyote.home.
 - Info - Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property 
jasper.home.
 - Info - Dependency on jaf exists, no need to add for property activation.home.
 - Info - Dependency on commons-modeler exists, no need to add for property 
commons-modeler.home.
 - Info - Dependency on commons-daemon exists, no need to add for property 
commons-daemon.jsvc.tar.gz.
 - Info - Dependency on jakarta-struts exists, no need to add for property struts.home.
 - Info - Enable debug output, due to a sequence of 19 previous errors.
 - Info - Failed with reason build failed


Gump performed this work:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/jakarta-tomcat-5/gump_work/build_jakarta-tomcat-5_jakarta-tomcat-5.html
Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build)
State: Failed
Elapsed: 0 hours, 1 minutes, 13 seconds
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xml-apis.jar:/data3/gump/xml-xalan/java/build/xalan-unbundled.jar:/data3/gump/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -debug -Dgump.merge=/data3/gump/gump-install/work/merge.xml 
-Dbuild.sysclasspath=only -Dtomcat33.home=*Unset* 
-Djsp-api.jar=/data3/gump/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar 
-Dtomcat-coyote.home=/data3/gump/jakarta-tomcat-connectors/coyote 
-Djndi.jar=/data3/gump/opt/jndi1_2_1/lib/jndi.jar 
-Dsite2.home=/data3/gump/jakarta-site2 
-DxmlParserAPIs.jar=/data3/gump/xml-xerces2/java/build/xercesImpl.jar 
-Dactivation.home=/data3/gump/opt/jaf-1.0.1 -Djmx.home=/data3/gump/opt/jmx-1_2-ri 
-Djdbc20ext.jar=/data3/gump/opt/jdbc2_0/jdbc2_0-stdext.jar 
-Djmx-tools.jar=/data3/gump/opt/jmx-1_2-ri/lib/jmxtools.jar 
-Dregexp.jar=/data3/gump/jakarta-regexp/build/jakarta-regexp-20040430.jar 
-Dmail.home=/data3/gump/opt/javamail-1.3 -Dant.home=/data3/gump/ant/dist 
-Dcommons-modeler.home=/data3/gump/jakarta-commons/modeler 
-Dcommons-launcher.jar=/data3/gump/jakarta-commons/launcher/dist/bin/commons-launcher.jar
 
-Dcommons-collections.jar=/data3/gump

Re: [5.0.23] Tag at the end of the week ?

2004-04-30 Thread Endre Stølsvik
On Fri, 30 Apr 2004, Remy Maucherat wrote:

| Filip Hanik - Dev wrote:
|
|  10-4
|
| Let me guess ...
| 10 people will complain that their bug is not fixed in this release, and
| out of these, 4 will point out this is a critical issue and requires a
| new tag immidiately.

hehe!

http://phrases.shu.ac.uk/bulletin_board/22/messages/537.html
http://www.theanswerbank.co.uk/DisplayAnswers.go?question_id=22064category_id=12index=13

-- 
Mvh,
Endre Stølsvik   M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 28709] New: - javax.servlet.http.HttpServletRequest.isRequestedSessionIdValid() returns true for an invalidated session!

2004-04-30 Thread bugzilla
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=28709.
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=28709

javax.servlet.http.HttpServletRequest.isRequestedSessionIdValid() returns true for an 
invalidated session!

   Summary: javax.servlet.http.HttpServletRequest.isRequestedSession
IdValid() returns true for an invalidated session!
   Product: Tomcat 5
   Version: 5.0.16
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This is the of the code sequence executed:

  javax.servlet.http.HttpServletRequestWrapper.getSession(true);
  // here, the debugger shows that the session is valid
  javax.servlet.http.HttpSession.invalidate();
  // here the debugger shows that the session has been invalidated
  javax.servlet.http.HttpServletRequestWrapper.getRequest();
  javax.servlet.http.HttpServletRequest.isRequestedSessionIdValid();
  // this call returns true, which is not expected!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Thanks!

2004-04-30 Thread nacho
Your file is attached.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

unsubscribe

2004-04-30 Thread [EMAIL PROTECTED]


Please unsubscribe me



-- Initial Header ---

From  : [EMAIL PROTECTED]
To  : [EMAIL PROTECTED]
Cc  : 
Date  : 30 Apr 2004 10:50:00 -
Subject : DO NOT REPLY [Bug 28709] New:  -
javax.servlet.http.HttpServletRequest.isRequestedSessionIdValid() returns true for an 
invalidated session!

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=28709.
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=28709

javax.servlet.http.HttpServletRequest.isRequestedSessionIdValid() returns true for an 
invalidated session!

   Summary: javax.servlet.http.HttpServletRequest.isRequestedSession
IdValid() returns true for an invalidated session!
   Product: Tomcat 5
   Version: 5.0.16
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This is the of the code sequence executed:

  javax.servlet.http.HttpServletRequestWrapper.getSession(true);
  // here, the debugger shows that the session is valid
  javax.servlet.http.HttpSession.invalidate();
  // here the debugger shows that the session has been invalidated
  javax.servlet.http.HttpServletRequestWrapper.getRequest();
  javax.servlet.http.HttpServletRequest.isRequestedSessionIdValid();
  // this call returns true, which is not expected!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



**ADSL Tiscali, le Haut débit au meilleur prix **
Avec Tiscali, profitez de l'ADSL au meilleur prix partout en France !
Pour profiter de cette offre exceptionnelle, cliquez ici : 
http://register.tiscali.fr/adsl
Sous réserve d'éligibilité à l'ADSL.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 28710] New: - javax.servlet.http.HttpSession.getCreationTime returns 0 for a valid session.

2004-04-30 Thread bugzilla
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=28710.
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=28710

javax.servlet.http.HttpSession.getCreationTime returns 0 for a valid session.

   Summary: javax.servlet.http.HttpSession.getCreationTime returns 0
for a valid session.
   Product: Tomcat 5
   Version: 5.0.16
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


javax.servlet.http.HttpSession.getCreationTime()
  returns 0

This is an excerpt from code execution sequence:

javax.servlet.http.HttpServletRequestWrapper.getSession(true);
// here, the debugger shows that the session is valid
javax.servlet.http.HttpSession.getCreationTime();

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 28711] New: - javax.servlet.http.HttpSession.getLastAccessedTime() returns 0 for a valid session

2004-04-30 Thread bugzilla
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=28711.
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=28711

javax.servlet.http.HttpSession.getLastAccessedTime() returns 0 for a valid session

   Summary: javax.servlet.http.HttpSession.getLastAccessedTime()
returns 0 for a valid session
   Product: Tomcat 5
   Version: 5.0.16
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


javax.servlet.http.HttpSession.getLastAccessedTime()
  returns only 0

This is an excerpt of the code execution sequence:

javax.servlet.http.HttpServletRequestWrapper.getSession(true);
// here, the debugger shows that the session is valid
javax.servlet.http.HttpSession.getLastAccessedTime();

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [5.0.23] Tag at the end of the week ?

2004-04-30 Thread Shapira, Yoav

Hi,
The plan for the next couple of builds sounds fine.  There's probably more interest in 
the JK fixes than anything else at this point.

Endre, welcome to the list.  I hope you don't have a log4j TRACE level type issue with 
tomcat? ;)

Yoav Shapira
Millennium Research Informatics


-Original Message-
From: Endre Stølsvik [mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 5:42 AM
To: Tomcat Developers List
Subject: Re: [5.0.23] Tag at the end of the week ?

On Fri, 30 Apr 2004, Remy Maucherat wrote:

| Filip Hanik - Dev wrote:
|
|  10-4
|
| Let me guess ...
| 10 people will complain that their bug is not fixed in this release, and
| out of these, 4 will point out this is a critical issue and requires a
| new tag immidiately.

hehe!

http://phrases.shu.ac.uk/bulletin_board/22/messages/537.html
http://www.theanswerbank.co.uk/DisplayAnswers.go?question_id=22064category
_id=12index=13

--
Mvh,
Endre Stølsvik   M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/


-
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 28709] - javax.servlet.http.HttpServletRequest.isRequestedSessionIdValid() returns true for an invalidated session!

2004-04-30 Thread bugzilla
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=28709.
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=28709

javax.servlet.http.HttpServletRequest.isRequestedSessionIdValid() returns true for an 
invalidated session!

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-04-30 13:38 ---
Cool, let's start.
I disagree with that, please try the latest release.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 28710] - javax.servlet.http.HttpSession.getCreationTime returns 0 for a valid session.

2004-04-30 Thread bugzilla
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=28710.
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=28710

javax.servlet.http.HttpSession.getCreationTime returns 0 for a valid session.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-04-30 13:39 ---
I disagree with that, please try the latest release.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 28711] - javax.servlet.http.HttpSession.getLastAccessedTime() returns 0 for a valid session

2004-04-30 Thread bugzilla
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=28711.
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=28711

javax.servlet.http.HttpSession.getLastAccessedTime() returns 0 for a valid session

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-04-30 13:39 ---
I disagree with that, please try the latest release.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-site/xdocs-faq misc.xml

2004-04-30 Thread yoavs
yoavs   2004/04/30 06:59:24

  Modified:docs/faq misc.html
   docs/faq/printer misc.html
   xdocs-faq misc.xml
  Log:
  Updated misc FAQ page.
  
  Revision  ChangesPath
  1.19  +57 -21jakarta-tomcat-site/docs/faq/misc.html
  
  Index: misc.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/misc.html,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- misc.html 29 Apr 2004 17:30:30 -  1.18
  +++ misc.html 30 Apr 2004 13:59:24 -  1.19
  @@ -5,31 +5,22 @@
 Tomcat FAQ
align=right src=../images/tomcat.gif/a/td/tr!--HEADER 
SEPARATOR--trtd colspan=2hr size=1 noshade=/td/trtr!--LEFT SIDE 
NAVIGATION--td nowrap=true valign=top 
width=20%pstrongLinks/strong/pullia href=..Tomcat 
Home/a/lilia href=index.htmlFAQ 
Home/a/li/ulpstrongContents/strong/pullia 
href=bugs.htmlBugs/a/lilia href=classnotfound.htmlClass Not 
Found/a/lilia href=connectors.htmlConnectors/a/lilia 
href=database.htmlDatabase/a/lilia 
href=deployment.htmlDeployment/a/lilia 
href=http://nagoya.apache.org/wiki/apachewiki.cgi?Tomcat/Howto;How do 
I/a/lilia href=unix.htmlLinux / Unix/a/lilia 
href=memory.htmlMemory/a/lilia href=meta.htmlMeta/a/lilia 
href=misc.htmlMiscellaneous/a/lilia href=performance.htmlMonitoring / 
Performance/a/lilia 
href=http://nagoya.apache.org/wiki/apachewiki.cgi?Tomcat/Links;Other 
Resources/a/lilia href=security.htmlSecurity/a/lilia 
href=version.htmlWhich Version/a/lilia href=tomcatuser.htmlTomcat User 
List/a/lilia href=windows.htmlWindows/a/li/ul/td!--RIGHT SIDE MAIN 
BODY--td align=left valign=top width=80%table cellspacing=4 width=100% 
border=0trtd nowrap=true valign=top align=lefth1Tomcat 
FAQ/h1h2Miscellaneous Questions/h2/tdtd nowrap=true valign=top 
align=rightsmalla href=printer/misc.htmlimg alt=Printer Friendly Version 
border=0 src=../images/printer.gifbrprint-friendlybrversion
   /a/small/td/tr/tabletable cellpadding=2 
cellspacing=0 border=0trtd bgcolor=#525D76font 
face=arial,helvetica.sanserif color=#ffa 
name=PrefacestrongPreface/strong/a/font/td/trtrtdblockquote
  -p
  -  emTomcat 4.1.27 has a bug with respect to webapp reloading which requires a 
hotfix.
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096;
  -  Here are more details.
  -/a
  -  /em
  -/p
  -p
  - In Tomcat 5 - there have been issues with respect to character encoding.
  - ( Usually of the the form ttrequest.setCharacterEncoding(String) doesn't 
work/tt )
  - Odds are, its not a bug. Before filing a bug report, see these bug reports as well
  -as any bug reports linked to these bug reports:
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23929;23929/a,
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25360;25360/a,
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25231;25231/a,
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25235;25235/a,
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22666;22666/a,
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24557;24557/a,
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24345;24345/a,
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25848;25848/a
  -/p
  +  This section contains various miscellaneous questions that are
  +  asked frequently enough to be listed here.
   /blockquote/td/tr/tabletable cellpadding=2 cellspacing=0 
border=0trtd bgcolor=#525D76font face=arial,helvetica.sanserif 
color=#ffa 
name=QuestionsstrongQuestions/strong/a/font/td/trtrtdblockquote
   p
 ul
   li
  +  a href=#tomcat5CharEncoding
  +I'm having a problem with character encoding in tomcat 5.
  +  /a
  +/li
  +li
  +  a href=#tomcat4127webappReloading
  +I have a problem with webapp reloading in tomcat 4.1.27.
  +  /a
  +/li
  +li
 a href=#compile
   I am unable to compile my JSP!
 /a
  @@ -168,10 +159,46 @@
   Who uses tomcat in production?
 /a
   /li
  +li
  +  a href=#commonsLoggingLog4j
  +How do I configure commons-logging and log4j in tomcat 5?
  +  /a
  +/li
 /ul
   /p
   
   /blockquote/td/tr/tabletable cellpadding=2 cellspacing=0 
border=0trtd bgcolor=#525D76font face=arial,helvetica.sanserif 
color=#ffa 
name=AnswersstrongAnswers/strong/a/font/td/trtrtdblockquote
  +  b style=font-size: larger
  +a name=tomcat5CharEncoding
  +  I'm having a problem with character encoding in tomcat 5.
  +/a
  +  /b
  +  div style=padding-left : 20px;
  +In Tomcat 5 - there have been issues with respect to character encoding.
  +( Usually of the the form ttrequest.setCharacterEncoding(String) doesn't 
work/tt )
  +Odds are, its not a bug. Before filing a bug report, see these bug reports as 
well
  +as any 

cvs commit: jakarta-tomcat-site/xdocs-faq misc.xml

2004-04-30 Thread yoavs
yoavs   2004/04/30 07:01:15

  Modified:docs/faq misc.html
   docs/faq/printer misc.html
   xdocs-faq misc.xml
  Log:
  Added Friendster
  
  Revision  ChangesPath
  1.20  +1 -0  jakarta-tomcat-site/docs/faq/misc.html
  
  Index: misc.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/misc.html,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- misc.html 30 Apr 2004 13:59:24 -  1.19
  +++ misc.html 30 Apr 2004 14:01:15 -  1.20
  @@ -748,6 +748,7 @@
 lia 
href=http://developers.slashdot.org/developers/02/08/19/2042235.shtml?tid=108;Various
 (from Slashdot)/a./li
 lia 
href=http://www.theserverside.com/news/thread.tss?thread_id=15073;TheServerSide.com/a
 take on the Slashdot discussion above, with many more references./li
 lia href=http://www.cofax.org;Cofax/a./li
  +  lia href=http://www.friendster.com;Friendster/a./li
 lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li
   /ul
   This list is limited mostly by our free time.  There are numerous other
  
  
  
  1.17  +1 -0  jakarta-tomcat-site/docs/faq/printer/misc.html
  
  Index: misc.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/printer/misc.html,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- misc.html 30 Apr 2004 13:59:24 -  1.16
  +++ misc.html 30 Apr 2004 14:01:15 -  1.17
  @@ -747,6 +747,7 @@
 lia 
href=http://developers.slashdot.org/developers/02/08/19/2042235.shtml?tid=108;Various
 (from Slashdot)/a./li
 lia 
href=http://www.theserverside.com/news/thread.tss?thread_id=15073;TheServerSide.com/a
 take on the Slashdot discussion above, with many more references./li
 lia href=http://www.cofax.org;Cofax/a./li
  +  lia href=http://www.friendster.com;Friendster/a./li
 lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li
   /ul
   This list is limited mostly by our free time.  There are numerous other
  
  
  
  1.16  +1 -0  jakarta-tomcat-site/xdocs-faq/misc.xml
  
  Index: misc.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs-faq/misc.xml,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- misc.xml  30 Apr 2004 13:59:24 -  1.15
  +++ misc.xml  30 Apr 2004 14:01:15 -  1.16
  @@ -764,6 +764,7 @@
 lia 
href=http://developers.slashdot.org/developers/02/08/19/2042235.shtml?tid=108;Various
 (from Slashdot)/a./li
 lia 
href=http://www.theserverside.com/news/thread.tss?thread_id=15073;TheServerSide.com/a
 take on the Slashdot discussion above, with many more references./li
 lia href=http://www.cofax.org;Cofax/a./li
  +  lia href=http://www.friendster.com;Friendster/a./li
 lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li
   /ul
   This list is limited mostly by our free time.  There are numerous other
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-site/xdocs-faq misc.xml

2004-04-30 Thread yoavs
yoavs   2004/04/30 07:03:12

  Modified:docs/faq misc.html
   docs/faq/printer misc.html
   xdocs-faq misc.xml
  Log:
  Fixed broken link to bugzilla 22096.
  
  Revision  ChangesPath
  1.21  +1 -1  jakarta-tomcat-site/docs/faq/misc.html
  
  Index: misc.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/misc.html,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- misc.html 30 Apr 2004 14:01:15 -  1.20
  +++ misc.html 30 Apr 2004 14:03:12 -  1.21
  @@ -196,7 +196,7 @@
 div style=padding-left : 20px;
   Update to a later tomcat version, preferably the latest stable one.
   If you must stay with 4.1.27, get this hotfix:
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096;
  +a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096;Bugzilla 
22096.
   /a
 /divbr
   
  
  
  
  1.18  +1 -1  jakarta-tomcat-site/docs/faq/printer/misc.html
  
  Index: misc.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/printer/misc.html,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- misc.html 30 Apr 2004 14:01:15 -  1.17
  +++ misc.html 30 Apr 2004 14:03:12 -  1.18
  @@ -195,7 +195,7 @@
 div style=padding-left : 20px;
   Update to a later tomcat version, preferably the latest stable one.
   If you must stay with 4.1.27, get this hotfix:
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096;
  +a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096;Bugzilla 
22096.
   /a
 /divbr
   
  
  
  
  1.17  +1 -1  jakarta-tomcat-site/xdocs-faq/misc.xml
  
  Index: misc.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs-faq/misc.xml,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- misc.xml  30 Apr 2004 14:01:15 -  1.16
  +++ misc.xml  30 Apr 2004 14:03:12 -  1.17
  @@ -212,7 +212,7 @@
 answer
   Update to a later tomcat version, preferably the latest stable one.
   If you must stay with 4.1.27, get this hotfix:
  -a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096;
  +a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096;Bugzilla 
22096.
   /a
 /answer
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-site/xdocs-faq misc.xml

2004-04-30 Thread yoavs
yoavs   2004/04/30 07:06:10

  Modified:docs/faq misc.html
   docs/faq/printer misc.html
   xdocs-faq misc.xml
  Log:
  Added WebShots.com.
  
  Revision  ChangesPath
  1.22  +1 -0  jakarta-tomcat-site/docs/faq/misc.html
  
  Index: misc.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/misc.html,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- misc.html 30 Apr 2004 14:03:12 -  1.21
  +++ misc.html 30 Apr 2004 14:06:09 -  1.22
  @@ -749,6 +749,7 @@
 lia 
href=http://www.theserverside.com/news/thread.tss?thread_id=15073;TheServerSide.com/a
 take on the Slashdot discussion above, with many more references./li
 lia href=http://www.cofax.org;Cofax/a./li
 lia href=http://www.friendster.com;Friendster/a./li
  +  lia href=http://www.webshots.com;WebShots/a./li
 lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li
   /ul
   This list is limited mostly by our free time.  There are numerous other
  
  
  
  1.19  +1 -0  jakarta-tomcat-site/docs/faq/printer/misc.html
  
  Index: misc.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/printer/misc.html,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- misc.html 30 Apr 2004 14:03:12 -  1.18
  +++ misc.html 30 Apr 2004 14:06:10 -  1.19
  @@ -748,6 +748,7 @@
 lia 
href=http://www.theserverside.com/news/thread.tss?thread_id=15073;TheServerSide.com/a
 take on the Slashdot discussion above, with many more references./li
 lia href=http://www.cofax.org;Cofax/a./li
 lia href=http://www.friendster.com;Friendster/a./li
  +  lia href=http://www.webshots.com;WebShots/a./li
 lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li
   /ul
   This list is limited mostly by our free time.  There are numerous other
  
  
  
  1.18  +1 -0  jakarta-tomcat-site/xdocs-faq/misc.xml
  
  Index: misc.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs-faq/misc.xml,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- misc.xml  30 Apr 2004 14:03:12 -  1.17
  +++ misc.xml  30 Apr 2004 14:06:10 -  1.18
  @@ -765,6 +765,7 @@
 lia 
href=http://www.theserverside.com/news/thread.tss?thread_id=15073;TheServerSide.com/a
 take on the Slashdot discussion above, with many more references./li
 lia href=http://www.cofax.org;Cofax/a./li
 lia href=http://www.friendster.com;Friendster/a./li
  +  lia href=http://www.webshots.com;WebShots/a./li
 lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li
   /ul
   This list is limited mostly by our free time.  There are numerous other
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [5.0.23] Tag at the end of the week ?

2004-04-30 Thread Endre Stølsvik
On Fri, 30 Apr 2004, Shapira, Yoav wrote:

|
| Hi, The plan for the next couple of builds sounds fine.  There's
| probably more interest in the JK fixes than anything else at this point.
|
| Endre, welcome to the list.  I hope you don't have a log4j TRACE level
| type issue with tomcat? ;)

Oh, thanks! .. but I've actually been hangin'/lurking/messing around here
on the list since early 3.2 days..!  :)

And no, there aren't any issues -on level- with the TRACE issue with
Tomcat, although a decent proper actual tagged released build of -some- JK
that -works- would be great! ;)

Thanks for the good work, folks!
Endre



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Word file

2004-04-30 Thread kief
Your file is attached.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28713] New: - Line too long - DoS Attack

2004-04-30 Thread bugzilla
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=28713.
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=28713

Line too long - DoS Attack

   Summary: Line too long - DoS Attack
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Somebody is attacking my Tomcat Server sending a big HTTP header. When the 
server gets this request it throws an IOException and the HTTPProcessor hangs. 

The exception is:

HttpProcessor[80][1] process.parse
java.io.IOException: Line too long
at org.apache.catalina.connector.http.SocketInputStream.readRequestLine
(SocketInputStream.java:271)
at org.apache.catalina.connector.http.HttpProcessor.parseRequest
(HttpProcessor.java:695)
at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:959)
at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1107)
at java.lang.Thread.run(Unknown Source)


After all HTTPProcessors are hung every connection to the server fails. This 
issue is related to Bug 3511. The HTTP port is able to respond but cannot 
respond since there aren't processors available to handle the request. The 
catalina log keeps showing:

HttpConnector[80] No processor available, rejecting this connection

Are there any workarounds for this issue? I don't understand why the processor 
hangs since this should be a handled exception...

Thxs!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/mcast McastServiceImpl.java

2004-04-30 Thread fhanik
fhanik  2004/04/30 08:28:02

  Modified:modules/cluster/src/share/org/apache/catalina/cluster/mcast
McastServiceImpl.java
  Log:
  Setting the interface on the multicast service if there is a bind address
  
  Revision  ChangesPath
  1.10  +6 -1  
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/mcast/McastServiceImpl.java
  
  Index: McastServiceImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/mcast/McastServiceImpl.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- McastServiceImpl.java 27 Feb 2004 14:58:56 -  1.9
  +++ McastServiceImpl.java 30 Apr 2004 15:28:02 -  1.10
  @@ -117,6 +117,11 @@
   throws IOException {
   if ( bind != null) socket = new MulticastSocket(new 
java.net.InetSocketAddress(bind,port));
   else socket = new MulticastSocket(port);
  +if ( bind != null ) {
  +log.info(Setting multihome multicast interface to:+bind);
  +socket.setInterface(bind);
  +log.info(Done setting interface for multicast.);
  +}//end if
   this.member = member;
   address = mcastAddress;
   this.port = port;
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Alain Hirtz/136/DCAG/DCX est absent(e). ist außer Haus

2004-04-30 Thread Alain.Hirtz




Je serai absent(e) du  25/04/2004 au 04/05/2004.

For price requests please mail to [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 21138] - javac cannot compile BaseDirContextTestCase.java

2004-04-30 Thread bugzilla
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=21138.
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=21138

javac cannot compile BaseDirContextTestCase.java

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-04-30 16:23 ---
This has been fixed. See
http://marc.theaimsgroup.com/?l=tomcat-devm=107956260824761w=2

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 21214] - Start menu items don't set endorsed dir

2004-04-30 Thread bugzilla
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=21214.
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=21214

Start menu items don't set endorsed dir

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-04-30 16:40 ---
This has been fixed. See
http://marc.theaimsgroup.com/?l=tomcat-devm=108310571313103w=2

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Which class stores the JNDI resources?

2004-04-30 Thread David
Hi I've run into some problems with Tomcats JNDI storing.. Here is the
situation:

Running Struts 1.1, with a Spring plugin that loads a JNDI Datasource
object.

Resource specified itself in the default context, OR specified in
GlobalResources with a resourceLink to it in the default context.

What happens as I have traced is:
-Tomcat loads
-Resource gets loaded into the namespace WITHOUT its resource params
-Tomcat loads the Struts Action Servlet from my webapp
-Plugin executes and gets an empty DataSource object from the DBCP
Factory
-Struts Action servlet finishes executing its init
-Tomcat loads the Resource into the namespace AGAIN WITH its resource
params

From that point forward I can get a fully populated functioning
datasource.

Now this will work if I specify a resource link inside a specific
Context element for my webapp within server.xml, however we want to
deploy our webapp via a war file so it needs to be in the default
context.

Can anyone point me to the class handling the saves to JNDI so I can see
exactly what is happening?  Or a good workaround for this?

Thanks,
David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-site/xdocs-faq misc.xml

2004-04-30 Thread yoavs
yoavs   2004/04/30 10:37:23

  Modified:docs/faq misc.html
   docs/faq/printer misc.html
   xdocs-faq misc.xml
  Log:
  
  
  Revision  ChangesPath
  1.23  +2 -1  jakarta-tomcat-site/docs/faq/misc.html
  
  Index: misc.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/misc.html,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- misc.html 30 Apr 2004 14:06:09 -  1.22
  +++ misc.html 30 Apr 2004 17:37:23 -  1.23
  @@ -750,7 +750,8 @@
 lia href=http://www.cofax.org;Cofax/a./li
 lia href=http://www.friendster.com;Friendster/a./li
 lia href=http://www.webshots.com;WebShots/a./li
  -  lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li
  +  lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li 
  +  lia 
href=http://marc.theaimsgroup.com/?l=tomcat-userm=108334244910127w=2;Another 
mailing list thread with production system references.../a/li
   /ul
   This list is limited mostly by our free time.  There are numerous other
   examples and references available by searching online, and undoubtedly
  
  
  
  1.20  +2 -1  jakarta-tomcat-site/docs/faq/printer/misc.html
  
  Index: misc.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/printer/misc.html,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- misc.html 30 Apr 2004 14:06:10 -  1.19
  +++ misc.html 30 Apr 2004 17:37:23 -  1.20
  @@ -749,7 +749,8 @@
 lia href=http://www.cofax.org;Cofax/a./li
 lia href=http://www.friendster.com;Friendster/a./li
 lia href=http://www.webshots.com;WebShots/a./li
  -  lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li
  +  lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li 
  +  lia 
href=http://marc.theaimsgroup.com/?l=tomcat-userm=108334244910127w=2;Another 
mailing list thread with production system references.../a/li
   /ul
   This list is limited mostly by our free time.  There are numerous other
   examples and references available by searching online, and undoubtedly
  
  
  
  1.19  +2 -1  jakarta-tomcat-site/xdocs-faq/misc.xml
  
  Index: misc.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs-faq/misc.xml,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- misc.xml  30 Apr 2004 14:06:10 -  1.18
  +++ misc.xml  30 Apr 2004 17:37:23 -  1.19
  @@ -766,7 +766,8 @@
 lia href=http://www.cofax.org;Cofax/a./li
 lia href=http://www.friendster.com;Friendster/a./li
 lia href=http://www.webshots.com;WebShots/a./li
  -  lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li
  +  lia 
href=http://archives.real-time.com/pipermail/cocoon-users/2003-October/040770.html;Various
 Cocoon on tomcat applications/a./li 
  +  lia 
href=http://marc.theaimsgroup.com/?l=tomcat-useramp;m=108334244910127amp;w=2;Another
 mailing list thread with production system references.../a/li
   /ul
   This list is limited mostly by our free time.  There are numerous other
   examples and references available by searching online, and undoubtedly
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources ResourceUtils.java SetUpDataSourceAction.java

2004-04-30 Thread amyroh
amyroh  2004/04/30 10:54:00

  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources
ResourceUtils.java SetUpDataSourceAction.java
  Log:
  Change to list any additionally JNDI data-sources that are present
  in the web.xml file, but not defined either globally or at the context level,
  on the context level maintenance page to make it possible to click on the
  data-source and edit it.
  
  Revision  ChangesPath
  1.11  +4 -15 
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/ResourceUtils.java
  
  Index: ResourceUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/ResourceUtils.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- ResourceUtils.java28 Apr 2004 16:46:03 -  1.10
  +++ ResourceUtils.java30 Apr 2004 17:53:59 -  1.11
  @@ -22,6 +22,7 @@
   import java.util.Iterator;
   import java.util.Collections;
   
  +import javax.management.Attribute;
   import javax.management.AttributeNotFoundException;
   import javax.management.MBeanServer;
   import javax.management.ObjectName;
  @@ -205,20 +206,8 @@
   mserver.getAttribute(oname, driverClassName);
   results.add(oname.toString());
   } catch (AttributeNotFoundException ex) {
  -// if context resource definition doesn't exist
  -// get the global resource definition
  -if (resourcetype.equals(Context)) {
  -rname = new ObjectName( domain + RESOURCE_TYPE + 
  -GLOBAL_TYPE + ,class= + DATASOURCE_CLASS + ,*);
  -Iterator globalIter = (mserver.queryMBeans(rname, 
null).iterator());
  -while (globalIter.hasNext()) {
  -ObjectInstance globalInstance = 
  -(ObjectInstance) globalIter.next();
  -ObjectName globalOname = globalInstance.getObjectName();
  -mserver.getAttribute(globalOname, driverClassName);
  -results.add(globalOname.toString());
  -}
  -}
  +mserver.setAttribute(oname, 
  +new Attribute(driverClassName, ));
   }
   }
   
  
  
  
  1.5   +27 -26
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SetUpDataSourceAction.java
  
  Index: SetUpDataSourceAction.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SetUpDataSourceAction.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- SetUpDataSourceAction.java27 Feb 2004 14:59:04 -  1.4
  +++ SetUpDataSourceAction.java30 Apr 2004 17:53:59 -  1.5
  @@ -21,6 +21,7 @@
   import java.util.Iterator;
   import java.util.Locale;
   import javax.management.Attribute;
  +import javax.management.AttributeNotFoundException;
   import javax.management.MBeanServer;
   import javax.management.MBeanServerFactory;
   import javax.management.QueryExp;
  @@ -136,26 +137,33 @@
   String attribute = null;
   try {
   ObjectName oname = new ObjectName(objectName);
  -attribute = name;
  -dataSourceForm.setJndiName
  -((String) mserver.getAttribute(oname, attribute));
  -attribute = url;
  -dataSourceForm.setUrl
  -((String) mserver.getAttribute(oname, attribute));
  -attribute = driverClassName;
  -dataSourceForm.setDriverClass
  -((String) mserver.getAttribute(oname, attribute));
  -attribute = username;
  -dataSourceForm.setUsername
  -((String) mserver.getAttribute(oname, attribute));
  -attribute = password;
  -dataSourceForm.setPassword
  -((String) mserver.getAttribute(oname, attribute));
  +try {
  +attribute = name;
  +dataSourceForm.setJndiName
  +((String) mserver.getAttribute(oname, attribute));
  +attribute = url;
  +dataSourceForm.setUrl
  +((String) mserver.getAttribute(oname, attribute));
  +attribute = driverClassName;
  +dataSourceForm.setDriverClass
  +((String) mserver.getAttribute(oname, attribute));
  +attribute = username;
  +

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread glenn
glenn   2004/04/30 12:15:26

  Modified:catalina/src/share/org/apache/catalina/session
JDBCStore.java PersistentManagerBase.java
StandardManager.java StandardSession.java
StoreBase.java
  Log:
  The JDBCStore required a great deal of unnecessary db
  queries to manage the persisted data. This could severly
  impact its ability to scale to large numbers of sessions.
  
  1. When a JSESSIONID cookie was submitted with a request where
 the Session no longer exists multiple queries of the db occurred
 to try and load a persisted Session from the Store. I was
 seeing four attempts to load from the persistence store
 each request when a Session did not exist for a JSESSIONID.
  
 PersistentManagerBase swapIn() and swapOut() were patched
 to maintain a Hashtable of JSESSIONID's which do not exist
 in the Store so that they don't have to be checked multiple
 times.  Each checkInterval the Hashtable is cleared to
 prevent it from consuming too much memory.
  
  2. The StoreBase.processExpires() method triggers a load of
 each Session persisted to the db each checkInterval to
 perform its test to determine if the Session has expired.
 This incurred alot of overhead on the db, especially
 if there was a large amount of session data. The number
 of queries performed each checkInterval is 1 + number of
 sessions persisted to the db + number of expired sessions
 removed.
  
 The StoreBase.processExpires() method was overridden
 in JDBCStore.  The method in JDBCStore performs a
 query of the db to find only those Sessions which should
 be expired. The number of queries performed here is 1 +
 2 * the number of expired sessions (load then remove
 of expired session).
  
  3. JDBCStore.remove() is being called sometimes with a null
 sessionid String causing an unnecessary synchronization
 and db query.
  
 Added a check for a null sessionid String at top of method.
  
  Problems with expiring sessions have been reported numerous times.
  The basic problem is as follows, starting at time 0 min and with
  a max inactive interval of 30 minutes:
  
  00 min: First request, new session created, LastAccessedTime 0
  02 min: Second request, reuse session, LastAccessedTime 0
  31 min: Third request, reuse session, LastAccessedTime now 2
  33 min: Background manager thread expires session even though
  it has only been two minutes since the remote clients
  last request.
  
  The argument for not changing how this works is based on how
  the Servlet Spec defines Session.getLastAccessedTime().
  
  But I agree with all those who have complained about this
  behaviour that Tomcat session timeouts are buggy.
  
  So I came up with a compromise that still allows the
  HttpSession.getLastAccessedTime() to return the time of the
  previous request for those who are Servlet Spec purists.
  
  But internally sessions are expired when
  current time  last request + max inactive interval.
  
  When we do a major revision we should consider adding
  the StandardSession.getLastUsedTime() method to the
  org.apache.catalina.Session interface.
  
  Revision  ChangesPath
  1.13  +119 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/JDBCStore.java
  
  Index: JDBCStore.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/JDBCStore.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- JDBCStore.java20 Mar 2004 10:57:18 -  1.12
  +++ JDBCStore.java30 Apr 2004 19:15:26 -  1.13
  @@ -201,6 +201,11 @@
*/
   protected PreparedStatement preparedLoadSql = null;
   
  +/**
  + * Variable to hold the codeprocessExpires()/code prepared statement.
  + */
  +protected PreparedStatement preparedExpiresSql = null;
  +
   // - Properties
   
   /**
  @@ -630,6 +635,11 @@
* @exception IOException if an input/output error occurs
*/
   public void remove(String id) throws IOException {
  +
  +if (id == null) {
  +return;
  +}
  +
   String removeSql =
   DELETE FROM  + sessionTable +  WHERE  + sessionIdCol +
= ?  AND  + sessionAppCol +  = ?;
  @@ -742,7 +752,7 @@
   preparedSaveSql.setBinaryStream(3, in, size);
   preparedSaveSql.setString(4, session.isValid()?1:0);
   preparedSaveSql.setInt(5, session.getMaxInactiveInterval());
  -preparedSaveSql.setLong(6, session.getLastAccessedTime());
  +preparedSaveSql.setLong(6, 
((StandardSession)session).getLastUsedTime());
   preparedSaveSql.execute();

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:

glenn   2004/04/30 12:15:26

  Modified:catalina/src/share/org/apache/catalina/session
JDBCStore.java PersistentManagerBase.java
StandardManager.java StandardSession.java
StoreBase.java
  Log:
  The JDBCStore required a great deal of unnecessary db
  queries to manage the persisted data. This could severly
  impact its ability to scale to large numbers of sessions.
  
  1. When a JSESSIONID cookie was submitted with a request where
 the Session no longer exists multiple queries of the db occurred
 to try and load a persisted Session from the Store. I was
 seeing four attempts to load from the persistence store
 each request when a Session did not exist for a JSESSIONID.
  
 PersistentManagerBase swapIn() and swapOut() were patched
 to maintain a Hashtable of JSESSIONID's which do not exist
 in the Store so that they don't have to be checked multiple
 times.  Each checkInterval the Hashtable is cleared to
 prevent it from consuming too much memory.
  
  2. The StoreBase.processExpires() method triggers a load of
 each Session persisted to the db each checkInterval to
 perform its test to determine if the Session has expired.
 This incurred alot of overhead on the db, especially
 if there was a large amount of session data. The number
 of queries performed each checkInterval is 1 + number of
 sessions persisted to the db + number of expired sessions
 removed.
  
 The StoreBase.processExpires() method was overridden
 in JDBCStore.  The method in JDBCStore performs a
 query of the db to find only those Sessions which should
 be expired. The number of queries performed here is 1 +
 2 * the number of expired sessions (load then remove
 of expired session).
  
  3. JDBCStore.remove() is being called sometimes with a null
 sessionid String causing an unnecessary synchronization
 and db query.
  
 Added a check for a null sessionid String at top of method.
  
  Problems with expiring sessions have been reported numerous times.
  The basic problem is as follows, starting at time 0 min and with
  a max inactive interval of 30 minutes:
  
  00 min: First request, new session created, LastAccessedTime 0
  02 min: Second request, reuse session, LastAccessedTime 0
  31 min: Third request, reuse session, LastAccessedTime now 2
  33 min: Background manager thread expires session even though
  it has only been two minutes since the remote clients
  last request.
  
  The argument for not changing how this works is based on how
  the Servlet Spec defines Session.getLastAccessedTime().
  
  But I agree with all those who have complained about this
  behaviour that Tomcat session timeouts are buggy.
  
  So I came up with a compromise that still allows the
  HttpSession.getLastAccessedTime() to return the time of the
  previous request for those who are Servlet Spec purists.
  
  But internally sessions are expired when
  current time  last request + max inactive interval.
  
  When we do a major revision we should consider adding
  the StandardSession.getLastUsedTime() method to the
  org.apache.catalina.Session interface.
And of course you don't discuss this before making the change ?
This is the old branch, so this is clearly not acceptable.
I have to -1 regardless of the possible merits.
Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Filip Hanik - Dev
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]

And of course you don't discuss this before making the change ?
This is the old branch, so this is clearly not acceptable.
I have to -1 regardless of the possible merits.

Ok, so he forgot to ask the developers if this would be ok, no big deal. Can happen to 
anybody.
But if someone is fixing code and improving it, I don't think a -1 is fair just
because you felt that you werent able to control the changes.

If there is more to the story which would require the -1 to go into effect, you would 
need to share that. take-it-lightlyAfter
all, we are not running a Boss/JBoss show here :)/take-it-lightly

So if there is more to it, share is please, so that we can all know why this change is 
not reasonable. It is not the -1 that I am
against, it is the lack of explanation to it.

Filip




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Remy Maucherat
Filip Hanik - Dev wrote:
And of course you don't discuss this before making the change ? 
This is the old branch, so this is clearly not acceptable. I have
to -1 regardless of the possible merits.
Ok, so he forgot to ask the developers if this would be ok, no big
deal. Can happen to anybody. But if someone is fixing code and
improving it, I don't think a -1 is fair just because you felt that
you werent able to control the changes.
If there is more to the story which would require the -1 to go into
effect, you would need to share that. take-it-lightlyAfter all, we
are not running a Boss/JBoss show here :)/take-it-lightly
I'm not very amused. Obviously the changes have nothing to do with JBoss.

So if there is more to it, share is please, so that we can all know
why this change is not reasonable. It is not the -1 that I am 
against, it is the lack of explanation to it.
I consider the change is inappropriate for Tomcat 4.1.x. But actually, I 
really don't care anoymore about this branch, so make my vote a -0.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Which class stores the JNDI resources?

2004-04-30 Thread Sandy McArthur
Been there. This has been fixed already. Use a newer release of tomcat.

On Apr 30, 2004, at 1:34 PM, David wrote:

Hi I've run into some problems with Tomcats JNDI storing.. Here is the
situation:
Running Struts 1.1, with a Spring plugin that loads a JNDI Datasource
object.
Resource specified itself in the default context, OR specified in
GlobalResources with a resourceLink to it in the default context.
What happens as I have traced is:
-Tomcat loads
-Resource gets loaded into the namespace WITHOUT its resource params
-Tomcat loads the Struts Action Servlet from my webapp
-Plugin executes and gets an empty DataSource object from the DBCP
Factory
-Struts Action servlet finishes executing its init
-Tomcat loads the Resource into the namespace AGAIN WITH its resource
params
From that point forward I can get a fully populated functioning
datasource.
Now this will work if I specify a resource link inside a specific
Context element for my webapp within server.xml, however we want to
deploy our webapp via a war file so it needs to be in the default
context.
Can anyone point me to the class handling the saves to JNDI so I can 
see
exactly what is happening?  Or a good workaround for this?

Thanks,
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Sandy McArthur


PGP.sig
Description: This is a digitally signed message part


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Tom Anderson
I'm just a list lurker (so my opinion doesn't count) but I'm really 
happy to see these fixes.   I have had to override JDBCStore and 
PersistentManagerBase at my site to make similar fixes so that things 
work acceptably (yes, I submitted patches but they weren't accepted).   
Having these fixes in would allow me to upgrade to 4.1.x and get rid of 
my old overridden classes.

Thanks Glenn!
~Tom
On Apr 30, 2004, at 1:15 PM, [EMAIL PROTECTED] wrote:

glenn   2004/04/30 12:15:26

  Modified:catalina/src/share/org/apache/catalina/session
JDBCStore.java PersistentManagerBase.java
StandardManager.java StandardSession.java
StoreBase.java
  Log:
  The JDBCStore required a great deal of unnecessary db
  queries to manage the persisted data. This could severly
  impact its ability to scale to large numbers of sessions.
  1. When a JSESSIONID cookie was submitted with a request where
 the Session no longer exists multiple queries of the db occurred
 to try and load a persisted Session from the Store. I was
 seeing four attempts to load from the persistence store
 each request when a Session did not exist for a JSESSIONID.
 PersistentManagerBase swapIn() and swapOut() were patched
 to maintain a Hashtable of JSESSIONID's which do not exist
 in the Store so that they don't have to be checked multiple
 times.  Each checkInterval the Hashtable is cleared to
 prevent it from consuming too much memory.
  2. The StoreBase.processExpires() method triggers a load of
 each Session persisted to the db each checkInterval to
 perform its test to determine if the Session has expired.
 This incurred alot of overhead on the db, especially
 if there was a large amount of session data. The number
 of queries performed each checkInterval is 1 + number of
 sessions persisted to the db + number of expired sessions
 removed.
 The StoreBase.processExpires() method was overridden
 in JDBCStore.  The method in JDBCStore performs a
 query of the db to find only those Sessions which should
 be expired. The number of queries performed here is 1 +
 2 * the number of expired sessions (load then remove
 of expired session).
  3. JDBCStore.remove() is being called sometimes with a null
 sessionid String causing an unnecessary synchronization
 and db query.
 Added a check for a null sessionid String at top of method.

  Problems with expiring sessions have been reported numerous times.
  The basic problem is as follows, starting at time 0 min and with
  a max inactive interval of 30 minutes:
  00 min: First request, new session created, LastAccessedTime 0
  02 min: Second request, reuse session, LastAccessedTime 0
  31 min: Third request, reuse session, LastAccessedTime now 2
  33 min: Background manager thread expires session even though
  it has only been two minutes since the remote clients
  last request.
  The argument for not changing how this works is based on how
  the Servlet Spec defines Session.getLastAccessedTime().
  But I agree with all those who have complained about this
  behaviour that Tomcat session timeouts are buggy.
  So I came up with a compromise that still allows the
  HttpSession.getLastAccessedTime() to return the time of the
  previous request for those who are Servlet Spec purists.
  But internally sessions are expired when
  current time  last request + max inactive interval.
  When we do a major revision we should consider adding
  the StandardSession.getLastUsedTime() method to the
  org.apache.catalina.Session interface.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Which class stores the JNDI resources?

2004-04-30 Thread David
Any idea which version has it fixed sandy? I've tried Tomcat 4.1.30 as
well as 5.0.19 to no avail.  Is it only in cvs at this point?
Thanks,
David

-Original Message-
From: Sandy McArthur [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 30, 2004 3:12 PM
To: Tomcat Developers List
Subject: Re: Which class stores the JNDI resources?


Been there. This has been fixed already. Use a newer release of tomcat.

On Apr 30, 2004, at 1:34 PM, David wrote:

 Hi I've run into some problems with Tomcats JNDI storing.. Here is the
 situation:

 Running Struts 1.1, with a Spring plugin that loads a JNDI Datasource
 object.

 Resource specified itself in the default context, OR specified in
 GlobalResources with a resourceLink to it in the default context.

 What happens as I have traced is:
 -Tomcat loads
 -Resource gets loaded into the namespace WITHOUT its resource params
 -Tomcat loads the Struts Action Servlet from my webapp
 -Plugin executes and gets an empty DataSource object from the DBCP
 Factory
 -Struts Action servlet finishes executing its init
 -Tomcat loads the Resource into the namespace AGAIN WITH its resource
 params

 From that point forward I can get a fully populated functioning
 datasource.

 Now this will work if I specify a resource link inside a specific
 Context element for my webapp within server.xml, however we want to
 deploy our webapp via a war file so it needs to be in the default
 context.

 Can anyone point me to the class handling the saves to JNDI so I can 
 see
 exactly what is happening?  Or a good workaround for this?

 Thanks,
 David


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Sandy McArthur


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Remy Maucherat
Tom Anderson wrote:
I'm just a list lurker (so my opinion doesn't count) but I'm really 
happy to see these fixes.   I have had to override JDBCStore and 
PersistentManagerBase at my site to make similar fixes so that things 
work acceptably (yes, I submitted patches but they weren't accepted).   
Having these fixes in would allow me to upgrade to 4.1.x and get rid of 
my old overridden classes.
The optimization part of the patch is useful. The session expiration 
fixes ae risky and change the API of some rather visible objects. The 
patch does not seem to cause any regressions, but obviously, there has 
been tons of examples where it looked to be the case, and problems occurred.

So overall, I think the patch is too risky for that branch. But however, 
since I don't use it anymore, my opinion is not worth much.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Glenn Nielsen
On Fri, Apr 30, 2004 at 09:19:30PM +0200, Remy Maucherat wrote:
 [EMAIL PROTECTED] wrote:
 
 glenn   2004/04/30 12:15:26
 
   Modified:catalina/src/share/org/apache/catalina/session
 JDBCStore.java PersistentManagerBase.java
 StandardManager.java StandardSession.java
 StoreBase.java
   Log:
   The JDBCStore required a great deal of unnecessary db
   queries to manage the persisted data. This could severly
   impact its ability to scale to large numbers of sessions.
   
   1. When a JSESSIONID cookie was submitted with a request where
  the Session no longer exists multiple queries of the db occurred
  to try and load a persisted Session from the Store. I was
  seeing four attempts to load from the persistence store
  each request when a Session did not exist for a JSESSIONID.
   
  PersistentManagerBase swapIn() and swapOut() were patched
  to maintain a Hashtable of JSESSIONID's which do not exist
  in the Store so that they don't have to be checked multiple
  times.  Each checkInterval the Hashtable is cleared to
  prevent it from consuming too much memory.
   
   2. The StoreBase.processExpires() method triggers a load of
  each Session persisted to the db each checkInterval to
  perform its test to determine if the Session has expired.
  This incurred alot of overhead on the db, especially
  if there was a large amount of session data. The number
  of queries performed each checkInterval is 1 + number of
  sessions persisted to the db + number of expired sessions
  removed.
   
  The StoreBase.processExpires() method was overridden
  in JDBCStore.  The method in JDBCStore performs a
  query of the db to find only those Sessions which should
  be expired. The number of queries performed here is 1 +
  2 * the number of expired sessions (load then remove
  of expired session).
   
   3. JDBCStore.remove() is being called sometimes with a null
  sessionid String causing an unnecessary synchronization
  and db query.
   
  Added a check for a null sessionid String at top of method.
   
   Problems with expiring sessions have been reported numerous times.
   The basic problem is as follows, starting at time 0 min and with
   a max inactive interval of 30 minutes:
   
   00 min: First request, new session created, LastAccessedTime 0
   02 min: Second request, reuse session, LastAccessedTime 0
   31 min: Third request, reuse session, LastAccessedTime now 2
   33 min: Background manager thread expires session even though
   it has only been two minutes since the remote clients
   last request.
   
   The argument for not changing how this works is based on how
   the Servlet Spec defines Session.getLastAccessedTime().
   
   But I agree with all those who have complained about this
   behaviour that Tomcat session timeouts are buggy.
   
   So I came up with a compromise that still allows the
   HttpSession.getLastAccessedTime() to return the time of the
   previous request for those who are Servlet Spec purists.
   
   But internally sessions are expired when
   current time  last request + max inactive interval.
   
   When we do a major revision we should consider adding
   the StandardSession.getLastUsedTime() method to the
   org.apache.catalina.Session interface.
 
 And of course you don't discuss this before making the change ?
 This is the old branch, so this is clearly not acceptable.
 I have to -1 regardless of the possible merits.
 
 Rémy
 

Remy,

I am sick and tired of your crap. For whatever reason you don't like
any of my contributions.  You always try to find some way to justify
a -1 of anything I contribute.  Frankly you are the main reason why
I rarely contribute to Tomcat any more.  I just got tired of dealing
with your shit. IMHO your interactions with people on this list and in
bugzilla hurts the Tomcat community.

And of course I did discusss this patch before I committed it.
I posted a summary of the patch on Apr 20 which contained the
same information as my commit message. From anyone else I would
expect an apology, but not from an egotistical piece of shit like you.

And for those of you watching from the sidelines this is the first
time on any of the ASF/Tomcat lists I have attacked someone personally.
I have always tried to keep discussions technical rather than get
personal.

My warmest regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Glenn Nielsen
Thanks for the words of encouragement.

Glenn

On Fri, Apr 30, 2004 at 03:27:00PM -0600, Tom Anderson wrote:
 I'm just a list lurker (so my opinion doesn't count) but I'm really 
 happy to see these fixes.   I have had to override JDBCStore and 
 PersistentManagerBase at my site to make similar fixes so that things 
 work acceptably (yes, I submitted patches but they weren't accepted).   
 Having these fixes in would allow me to upgrade to 4.1.x and get rid of 
 my old overridden classes.
 
 Thanks Glenn!
 ~Tom
 
 On Apr 30, 2004, at 1:15 PM, [EMAIL PROTECTED] wrote:
 
 glenn   2004/04/30 12:15:26
 
   Modified:catalina/src/share/org/apache/catalina/session
 JDBCStore.java PersistentManagerBase.java
 StandardManager.java StandardSession.java
 StoreBase.java
   Log:
   The JDBCStore required a great deal of unnecessary db
   queries to manage the persisted data. This could severly
   impact its ability to scale to large numbers of sessions.
 
   1. When a JSESSIONID cookie was submitted with a request where
  the Session no longer exists multiple queries of the db occurred
  to try and load a persisted Session from the Store. I was
  seeing four attempts to load from the persistence store
  each request when a Session did not exist for a JSESSIONID.
 
  PersistentManagerBase swapIn() and swapOut() were patched
  to maintain a Hashtable of JSESSIONID's which do not exist
  in the Store so that they don't have to be checked multiple
  times.  Each checkInterval the Hashtable is cleared to
  prevent it from consuming too much memory.
 
   2. The StoreBase.processExpires() method triggers a load of
  each Session persisted to the db each checkInterval to
  perform its test to determine if the Session has expired.
  This incurred alot of overhead on the db, especially
  if there was a large amount of session data. The number
  of queries performed each checkInterval is 1 + number of
  sessions persisted to the db + number of expired sessions
  removed.
 
  The StoreBase.processExpires() method was overridden
  in JDBCStore.  The method in JDBCStore performs a
  query of the db to find only those Sessions which should
  be expired. The number of queries performed here is 1 +
  2 * the number of expired sessions (load then remove
  of expired session).
 
   3. JDBCStore.remove() is being called sometimes with a null
  sessionid String causing an unnecessary synchronization
  and db query.
 
  Added a check for a null sessionid String at top of method.
 
   Problems with expiring sessions have been reported numerous times.
   The basic problem is as follows, starting at time 0 min and with
   a max inactive interval of 30 minutes:
 
   00 min: First request, new session created, LastAccessedTime 0
   02 min: Second request, reuse session, LastAccessedTime 0
   31 min: Third request, reuse session, LastAccessedTime now 2
   33 min: Background manager thread expires session even though
   it has only been two minutes since the remote clients
   last request.
 
   The argument for not changing how this works is based on how
   the Servlet Spec defines Session.getLastAccessedTime().
 
   But I agree with all those who have complained about this
   behaviour that Tomcat session timeouts are buggy.
 
   So I came up with a compromise that still allows the
   HttpSession.getLastAccessedTime() to return the time of the
   previous request for those who are Servlet Spec purists.
 
   But internally sessions are expired when
   current time  last request + max inactive interval.
 
   When we do a major revision we should consider adding
   the StandardSession.getLastUsedTime() method to the
   org.apache.catalina.Session interface.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]