DO NOT REPLY [Bug 26479] - setAutoCommit() never set to true
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26479. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26479 setAutoCommit() never set to true [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-28 07:32 --- Upgrade to a recent version of Tomcat (4.1.29) and re-test. No one wants to look for bugs which may have been fixed already. Your problem with the MySQL connection dying after being idle sounds like autoReconnect isn't being set in the db connection URL. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26452] - Welcome-file not forwarding to servlet
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26452. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26452 Welcome-file not forwarding to servlet --- Additional Comments From [EMAIL PROTECTED] 2004-01-28 08:44 --- Look at my example. Does that behavior makes sense ? No. So you have your answer :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: failover-problem and session mixup: jakarta-tomcat-connectors: jk_ajp_common.c
Henri Gomez wrote: Alexander Schwartz a écrit : Hello Tomcat-Developers, we are currently experiencing some problems with mod_jk with loadbalancing: (A) when a post-request fails while receiving data from tomcat, the loadbalancer tries to send the request to the other tomcat, but forgets the post body content (i.e. login and password submitted by the user). The size of the body content is only a few bytes ( 100), so it's not the known problem with bodies longer than 8k. (B) it seems that sometimes after a POST-failover body data from an old request is sent to the other tomcat when the first connection failed. This leads to a session mix-up user mix-up! The setup is a simple cluster configuration: one apache httpd with mod_ssl in front, mod_jk with one configured loadbalance worker with sticky sessions and two child ajp13 workers in the middle, two tomcats in the back. Versions involved: mod_jk 1.2.4, Tomcat 4.1.27 (but also tested with mod_jk 1.2.5 and Tomcat 4.1.29). Apache on AIX, version 1.3.29. The latest version of jk_ajp_common.c in CVS don't seem to have relevant changes. We have searched the mailinglists, the only source I have found is in tomcat-user-mailinglist where Jean-Philippe Belanger describes a similar problem in the mails from 14 Jan 2004 (the empty POST body) and 12 Jan 2004 (the empty POST body and the session mixup). He didn't investigate further but got himself a cisco load balancer. Another post is here, but I found no replies/solutions. http://www.mail-archive.com/[EMAIL PROTECTED]/msg48833.html (A) can be reproduced quite easily using netcat as a simulator of the first tomcat and a second real tomcat. If you kill netcat after it has accepted a POST-connection from a mod_jk, mod_jk will forward the request to the other tomcat without the POST-body But we can't reproduce (B), but it has definitely happened. We suspect that POST-Recovery code might send an old request body while executing the following statements. Please note that the log statement refers to op-reply while the following if statement refers to op-post! (this is cut and paste from the orginal source): It used to works but it was before the content-header add-on code. This piece of is a nightmare, and I see no easier solution than copying the HEAD+POST in temp buffer but I'd like to have Bill, Mladen and JFC advices... That is what I am doing in the modified mod_jk2 I use to connect to embbed tomcats. BTW, could you send the code as diff -Nru ? - 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 26487] New: - JNDIRealm not working - using incorrect filter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26487. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26487 JNDIRealm not working - using incorrect filter Summary: JNDIRealm not working - using incorrect filter Product: Tomcat 5 Version: 5.0.18 Platform: PC OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When using the JNDIRealm, no role checking succeeds. Looking at the debug, this is due to an incorrect search filter being created, prepending and appending invalid characters (\28 and \29) to the filter. The server.xml works fine on previous versions. This occurs on both Windows and Linux. Log output: 2004-01-27 14:48:02 JNDIRealm[Catalina]: Username tomcat successfully authenticated 2004-01-27 14:48:02 JNDIRealm[Catalina]: getRoles(uid=tomcat,dc=test,dc=com) 2004-01-27 14:48:02 JNDIRealm[Catalina]: Searching role base 'dc=test,dc=com' for attribute 'cn' 2004-01-27 14:48:02 JNDIRealm[Catalina]: With filter expression '\28uniqueMember=uid=tomcat,dc=test,dc=com\29' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26475] - JAASRealms behave different in Tomcat 5.x then Tomcat 4.x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26475. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26475 JAASRealms behave different in Tomcat 5.x then Tomcat 4.x [EMAIL PROTECTED] changed: What|Removed |Added Component|Catalina|Catalina:Modules --- Additional Comments From [EMAIL PROTECTED] 2004-01-28 09:07 --- /WEB-INF is the application classloader, not the server classloader. This does not convince me at all. If somehow the realm can look up stuff, the conext CL is the webapp CL during the realm initialization. If nobody looks at this report within a week, I'll close it again. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26488] New: - compiler does not notice changes to static includes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26488. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26488 compiler does not notice changes to static includes Summary: compiler does not notice changes to static includes Product: Tomcat 4 Version: 4.1.29 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi I could have sworn this was working in one of the previous versions of Tomcat4. Anyhow, if I create a page that uses %@ include file=xxx.jspf % commands, the compiler will not notice if I make changes to xxx.jspf and recompile the page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
hello
ALERT! This e-mail, in its original form, contained one or more attached files that were infected with a virus, worm, or other type of security threat. This e-mail was sent from a Road Runner IP address. As part of our continuing initiative to stop the spread of malicious viruses, Road Runner scans all outbound e-mail attachments. If a virus, worm, or other security threat is found, Road Runner cleans or deletes the infected attachments as necessary, but continues to send the original message content to the recipient. Further information on this initiative can be found at http://help.rr.com/faqs/e_mgsp.html. Please be advised that Road Runner does not contact the original sender of the e-mail as part of the scanning process. Road Runner recommends that if the sender is known to you, you contact them directly and advise them of their issue. If you do not know the sender, we advise you to forward this message in its entirety (including full headers) to the Road Runner Abuse Department, at [EMAIL PROTECTED] The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment. file attachment: data.pif This e-mail in its original form contained one or more attached files that were infected with the [EMAIL PROTECTED] virus or worm. They have been removed. For more information on Road Runner's virus filtering initiative, visit our Help Member Services pages at http://help.rr.com, or the virus filtering information page directly at http://help.rr.com/faqs/e_mgsp.html. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-connectors distribution
On Tue, 2004-01-27 at 17:49, martin grotzke wrote: dear developers, the current version of the jakarta-tomcat-connectors jk2 is 2.0.2. moreover, the connectors are released together with the tomcat-src. what can be seen as the current stable one? i'm using the jpackage.org's mod_jk2-rpms, these are built with the connector-sources shipped with the latest tomcat-4.1 release. at jpackage, there's the question now if it would be better to provide an rpm built with the connectors shipped with the latest tomcat-release, or if it should be built with the connectors 2.0.2. what would you suggest? i think i'm on the correct list, am i not? please could you send some comments to my questions? regards, martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
embedded tomcat and JMX sample code
I am looking for some sample code that will demonstrate how to embed tomcat in a java application using JMX. I would like to write some documentation on how to do this, as there is none that exists that I have found on tomcat's web site. I would imagine that there must be some code somewhere that was used for testing the new infrastructure. Everywhere I have turned so far, has told me to look at the JBoss source code, but I figure that the tomcat development team must have some code laying around that will demonstrate this. thank you for your time. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WANTED: next release mod_jk2 after 14 months!!
Hi all, I'm sure that a lot of folks want to see a new release of mod_jk2; and looking at: http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/ it seems that the last version 2.0.2 was released 14 (!!) months ago comments? Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-connectors distribution
Hi Martin, On Tue, 2004-01-27 at 17:49, martin grotzke wrote: dear developers, the current version of the jakarta-tomcat-connectors jk2 is 2.0.2. moreover, the connectors are released together with the tomcat-src. what can be seen as the current stable one? i'm using the jpackage.org's mod_jk2-rpms, these are built with the connector-sources shipped with the latest tomcat-4.1 release. at jpackage, there's the question now if it would be better to provide an rpm built with the connectors shipped with the latest tomcat-release, or if it should be built with the connectors 2.0.2. what would you suggest? i think i'm on the correct list, am i not? yes - at least here are the developers which maintain mod_jk/mod_jk2. please could you send some comments to my questions? I would also like to get a release since bug reports are a lot more useful if they can mention a version number; if currently someone enters a bug with mod_jk2 he has to tell at what date he fetched from CVS. Also seems that the developers has successfully avoided to release any mod_jk2 2003 version: http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/ Congratulations to all here around: 14 months without a release is probably worth an entry in the Guinness book! in addtion the STATUS.txt shows '2.0.2 : in progress' although we are currently already at 2.0.4 not to mention the CHANGES files maybe we should cry louder?? Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26492] New: - Strange Session id behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26492. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26492 Strange Session id behavior Summary: Strange Session id behavior Product: Tomcat 5 Version: 5.0.18 Platform: Other OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm maintaining a JSP/servlet web using SSL, running on Apache 2.0.48 and Tomcat 5.0.18. Cookies are used for session identifier communication (not url rewriting). Some users using the web are experiencing very strange session id behaviour, the behaviour is like this: When these users make their first request to the web, they already have an session id that is invalid, i.e. request.getRequestedSessionId() is not null and the id is not a session id that has been recently created by Tomcat (I've a session listener in Tomcat that logs session creation and destruction). As expected, Tomcat creates a new session id for the users (because the session id is invalid) but the next requests from the users do not use that session id but instead continue to use the session id that they used in the first request. So Tomcat continues to create new session ids for each request, example: request.getRequestedSessionId() request.getSession(false).getId() request.getRequestURI() 01A960C22480CE9F445CDE48DE333F31451BA13F85AE631148022C93DFDD2811 /first_request.jsp 01A960C22480CE9F445CDE48DE333F31CBF44C3C065502D6397BC44A7AB659F9 /second_request.jsp 01A960C22480CE9F445CDE48DE333F316453C03AF5DD2B9EA1F27D225589E8B2 /third_request.jsp 01A960C22480CE9F445CDE48DE333F3193F173966F28A972A2E70C32CC8E848B /fourth_request.jsp If the users close their browser and try again - they (most often) continue to have the same problem but request.getRequestedSessionId() is not the same as it was at last time... What could be the reason for this behaviour? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26494] New: - JDBCRealm and DataSourceRealm with case insensitive user names
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26494. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26494 JDBCRealm and DataSourceRealm with case insensitive user names Summary: JDBCRealm and DataSourceRealm with case insensitive user names Product: Tomcat 4 Version: 4.1.29 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Both the JDBCRealm and the DataSourceRealm don't handle tables with case insensitive user names very well: Users can enter any capitalisation, but request.getRemoteUser() does not normalize the user name to the exact capitalisation stored in the database table. Instead, it returns the (variable) spelling user by the user who just logged on. My proposal is to change JDBCRealm and DataSourceRealm in a way that the Realm implementation reads the user name contained in the database along with the password (SELECT userName, credentials FROM users WHERE userName = ?) and store the retrieved user name in the Credentials object. I could provide patches for Tomcat 4.1 and 5.0, but like to know if this change has got any chance of being accepted. Regards, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26495] New: - JDBCRealm and DataSourceRealm with case insensitive user names
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26495. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26495 JDBCRealm and DataSourceRealm with case insensitive user names Summary: JDBCRealm and DataSourceRealm with case insensitive user names Product: Tomcat 5 Version: 5.0.18 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Both the JDBCRealm and the DataSourceRealm don't handle tables with case insensitive user names very well: Users can enter any capitalisation, but request.getRemoteUser() does not normalize the user name to the exact capitalisation stored in the database table. Instead, it returns the (variable) spelling user by the user who just logged on. My proposal is to change JDBCRealm and DataSourceRealm in a way that the Realm implementation reads the user name contained in the database along with the password (SELECT userName, credentials FROM users WHERE userName = ?) and store the retrieved user name in the Credentials object. I could provide patches for Tomcat 4.1 and 5.0, but like to know if this change has got any chance of being accepted. Regards, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR
Dies ist eine automatisch generierte Fehler e-mail. Die von Ihnen verwendete Empfängeradresse existiert auf diesem System nicht. Bitte überprüfen Sie den Namen und die Domain (STUBAITAL.at, NEUSTIFT.at usw.) *** Fehler-Nachricht: 195.227.87.40 does not like recipient. Remote host said: 550 User unknown or not available - Empfaenger unbekannt oder nicht erreichbar Giving up on 195.227.87.40 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26482] - Broken Link
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26482. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26482 Broken Link [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-28 09:32 --- No, you need to compile and deploy the sample webapp first. Please post on tomcat-user for new user help, it works well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANTED: next release mod_jk2 after 14 months!!
Hi all, I'm sure that a lot of folks want to see a new release of mod_jk2; and looking at: http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/ it seems that the last version 2.0.2 was released 14 (!!) months ago comments? We sure DO WANT a new release. regz, Dominik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
You sent potentially unsafe content:
You sent a message that contained potentially harmful content. Original message recipient(s): [EMAIL PROTECTED] Scan report: Virus '[EMAIL PROTECTED]' in text.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANTED: next release mod_jk2 after 14 months!!
Dominik Drzewiecki wrote: Hi all, I'm sure that a lot of folks want to see a new release of mod_jk2; and looking at: http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/ it seems that the last version 2.0.2 was released 14 (!!) months ago comments? We sure DO WANT a new release. I also need a release and I will try to make it happend soon. regz, Dominik - 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 26492] - Strange Session id behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26492. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26492 Strange Session id behavior [EMAIL PROTECTED] changed: What|Removed |Added Severity|Critical|Enhancement --- Additional Comments From [EMAIL PROTECTED] 2004-01-28 17:37 --- This works reasonably well. However, if the client submits more that one session cookie, only the first one is takes into account right now. I think there's a bug or enhancement about that for 4.1.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] 4.1.30 release vote
Amidst all this junk email ... ballot Release 4.1.30 as Stable: [ ] Yes [ ] No /ballot Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: embedded tomcat and JMX sample code
Mark W. Webb wrote: I am looking for some sample code that will demonstrate how to embed tomcat in a java application using JMX. I would like to write some documentation on how to do this, as there is none that exists that I have found on tomcat's web site. I would imagine that there must be some code somewhere that was used for testing the new infrastructure. Everywhere I have turned so far, has told me to look at the JBoss source code, but I figure that the tomcat development team must have some code laying around that will demonstrate this. The Ant script in the embed distribution can directly be translated into JMX commands. Other than that, we have no Java JMX code (so look in the JBoss/Tomcat integration for that). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANTED: next release mod_jk2 after 14 months!!
Good morning All. Recently there was mention of a patch for Mod_Jk2 (to work with APR 1.0) which was questioned in regard to a previous 'bug' report. Since then, it is my understanding the previous correspondent was happy with a solution now in place regarding the earlier bug. Which, I think, brings us back again to the patch(s) needed for Mod_Jk2 to support APR 1.0 again. There has been at least one fix for Mod_Jk2 on NetWare put into CVS that would be nice to see appear in an authentic Apache binary, and it would be even nicer to see a resolution to the APR 1.0 patch submitted if a new release is to be made. A new release is 'due', especially if such a release is still able to work with earlier versions of Apache and APR. My 0.02c Norm - Original Message - From: Günter Knauf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 29, 2004 12:48 AM Subject: WANTED: next release mod_jk2 after 14 months!! Hi all, I'm sure that a lot of folks want to see a new release of mod_jk2; and looking at: http://www.apache.de/dist/jakarta/tomcat-connectors/jk2/source/ it seems that the last version 2.0.2 was released 14 (!!) months ago comments? Guenter. - 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 26496] - Session listeners are not notified when webapp redeployed/stopped (or server is shut down)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26496. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26496 Session listeners are not notified when webapp redeployed/stopped (or server is shut down) --- Additional Comments From [EMAIL PROTECTED] 2004-01-28 16:41 --- I forgot to mention, that the same problem apparently exists in Tomcat 4.x series(tested against 4.1.24). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26449] - Webdav servlet will not open in IE web folder.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26449. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26449 Webdav servlet will not open in IE web folder. --- Additional Comments From [EMAIL PROTECTED] 2004-01-28 21:05 --- This is invalid but it is actually because of a bug in IE. Steps to reproduce: 1. Install tomcat 5 (latest version), enable webdav servlet (read docs for details) 2. Start tomcat 5 3. Open internet exploer 4. Select File Open 5. Enter http://localhost/webdav/ 6. Tick the open as webfolder option There are actually two problems. A. IE actually requests http://localhost/webdav rather than http://localhost/webdav/ B. Tomcat returns a 302 to this request, redirecting to http://localhost/webdav/ IE ignores this redirect Further info may be found at http://www.mail-archive.com/[EMAIL PROTECTED]/msg109970.html I have tried in vain to get MS to do something about this. To quote from their reply: quote However, I'm sorry to inform you that this issue falls outside the support boundaries for Microsoft Windows products. I would like to suggest that you contact Microsoft Support Professional. I believe that they will assist you best since this issue relates to development. /quote And I thought webdav was user functionality... If you feel inclined to try and get MS to do something about this, best of luck! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26496] - Session listeners are not notified when webapp redeployed/stopped (or server is shut down)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26496. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26496 Session listeners are not notified when webapp redeployed/stopped (or server is shut down) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-28 17:22 --- This is invalid (there are even working examples of this in the two examples webapps). Please don't reopen the report, and instead post to tomcat-user for advice. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26373] - getServletContext().getRequestDispatcher() fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26373 getServletContext().getRequestDispatcher() fails --- Additional Comments From [EMAIL PROTECTED] 2004-01-28 18:35 --- Yes it was only with a load on startup servlet. Why FIXED? I don't see any mention of such a fix in the changelog of 5.0.17 or 5.0.18. Can you be a bit more explicit. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: failover-problem and session mixup: jakarta-tomcat-connectors: jk_ajp_common.c
Am Di, den 27.01.2004 schrieb Henri Gomez um 18:00: It used to works but it was before the content-header add-on code. This piece of is a nightmare, and I see no easier solution than copying the HEAD+POST in temp buffer but I'd like to have Bill, Mladen and JFC advices... My code tries to avoid post recovery completly as my application is at the moment not safe to process a (POST) reqest twice. I wonder if post recovery is really needed. The most common error for post recovery is the We will know only at read time if the remote host closed the connection (half-closed state - FIN-WAIT2) (stated i.e. at ajp_get_reply() function comment) With ping/pong avaliable, is it still needed? As I looked deeper into you code I found that mod_jk retries the request even after headers and/or parts of the body have already been sent to the client. To me it seems that ajp_get_reply() needs some extended return value after it has called ajp_process_callback() to process JK_AJP13_SEND_HEADERS or JK_AJP13_SEND_BODY_CHUNK to set op-recoverable to JK_FALSE. Again: my code avoids this complicated decisions by promoting less recovery mechanisms, but early and clean failure :) Cheers, Alex. -- Alexander Schwartz ([EMAIL PROTECTED]) http://www.ahus1.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26496] New: - Session listeners are not notified when webapp redeployed/stopped (or server is shut down)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26496.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26496
Session listeners are not notified when webapp redeployed/stopped (or server is shut
down)
Summary: Session listeners are not notified when webapp
redeployed/stopped (or server is shut down)
Product: Tomcat 5
Version: 5.0.16
Platform: PC
OS/Version: Other
Status: NEW
Severity: Major
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
If I have an HttpSessionListener implementation defined in web.xml, or I have an
attributes in
session which implement HttpSessionBindingListener, neither one gets notified when I
redeploy war file via manager (ant task) nor if I stop/remove it via manager's web
interface. Also
those events are not fired if I stop tomcat.
In code below SESSION TERMINATED never gets
printed when you close tomcat or redeploy/remove/stop webapplication via manager.
I
believe, it should happen. That is, session must be invalidated by container upon
destroyng
webapplication.
For instance, in my case, we need to notify a legacy system, that our user
finished his work, we can't force him to click on Log out button, so we must track
session
expiration. It all works fine (natural expiration by timeout), but when I redeploy new
version of
our webapp via ant task, existing sessions are not terminated properly.
=== Test code
===
package test;
import javax.servlet.http.HttpSessionBindingEvent;
import
javax.servlet.http.HttpSessionBindingListener;
import
javax.servlet.http.HttpSessionEvent;
import
javax.servlet.http.HttpSessionListener;
public class MySessionListener implements
HttpSessionListener {
public void sessionCreated(HttpSessionEvent _aArg0)
{
System.out.println(SESSION CREATED);
}
public void
sessionDestroyed(HttpSessionEvent _aArg0) {
System.out.println(SESSION
TERMINATED);
}
}
=== goes to web.xml ===
listener
listener-
classtest.MySessionListener/listener-class
/listener
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26373] - getServletContext().getRequestDispatcher() fai
Thank you for writing to HousingHelp. Please note that the answers to many questions about housing selection can be found on our website: www.emory.edu/HOUSING/SELECTION Thank you for choosing to Live at Emory! University Housing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26373] - getServletContext().getRequestDispatcher() fai
Thank you for writing to HousingHelp. Please note that the answers to many questions about housing selection can be found on our website: www.emory.edu/HOUSING/SELECTION Thank you for choosing to Live at Emory! University Housing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add ability for Realm authentication to tell the user the reason for auth failure
On Friday 23 January 2004 20:59, Remy Maucherat wrote: - 26236 about the JAAS realm: it would be a very useful fix, and shouldn't be too complex Well... I've tried to reproduce the bug... I've created my own LoginModule, and two classes wich implements de java.security.Principal interface (one for the user principal and other to the roles principals) just like the bug description said, and it worked fine! I also couldn't figure out how the method hasRole() in the RealmBase class can be related to this problem because the method createPrincipal() (which is called by the authenticate() method in the JAASRealm class) creates a GenericPrincipal, as expected by the hasRole() method. I think the problem can be related to the LoginModule of the user application, maybe it's not returning any RolePrincipal or something like that. As a new guy to the tomcat source-code, I can be just missunderstanding something... any ideas? Thanks in advance! -- Carlos H. ([EMAIL PROTECTED]) Núcleo de Informática UNERJ UNERJ - Centro Universitário de Jaraguá do Sul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add ability for Realm authentication to tell the user the reason for auth
Thank you for writing to HousingHelp. Please note that the answers to many questions about housing selection can be found on our website: www.emory.edu/HOUSING/SELECTION Thank you for choosing to Live at Emory! University Housing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26492] - Strange Session id behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26492. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26492 Strange Session id behavior [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-28 18:18 --- I've fixed this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26492] - Strange Session id behavior
Thank you for writing to HousingHelp. Please note that the answers to many questions about housing selection can be found on our website: www.emory.edu/HOUSING/SELECTION Thank you for choosing to Live at Emory! University Housing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26135] - Tomcat 5.0.16 leaks memory when a webapp is reloaded or stopped/started
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26135. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26135 Tomcat 5.0.16 leaks memory when a webapp is reloaded or stopped/started [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-01-28 23:54 --- I believe this is a bug within Tomcat... Here is a way to replicate it: Use the Struts blank war. Available here: http://mirrors.isc.org/pub/apache/jakarta/struts/binaries/jakarta-struts-1.1.zip Load that webapp, and open two browser windows, one to the Tomcat Manager and one to the Tomcat Status page. View the available memory. You will see it cycle within a meg as garbage collection is run. Then use Tomcat Manager to reload the struts webapp. The free memory should now be a meg less. This will continue until you reach 0, when a major garbage collection will occur, but it just looks like memory is released, as the Total Memory usage has now increased. You can continue this cycle until the memory reaches the total allocated, and Tomcat will fall over. If this is truly a non issue, then I feel the Tomcat developers need to answer this issue more directly (like the release notes). We have customers that run multiple occurrences of our webapp under a single Tomcat, and need to reload... With the leak... they end up having to restart Tomcat to free the memory... causing support issues. I look forward to become more educated on why this is (not) an issue... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26452] - Welcome-file not forwarding to servlet
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26452. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26452 Welcome-file not forwarding to servlet [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-27 08:09 --- I have to disagree: welcome files cannot possibly apply to extension mapping. This was already discussed with Jean François a while ago. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26507] New: - Jasper Generator java Error (useBean ObjectArray)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26507.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26507
Jasper Generator java Error (useBean ObjectArray)
Summary: Jasper Generator java Error (useBean ObjectArray)
Product: Tomcat 5
Version: 5.0.18
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
JSP Code in
- DataField implements Serializable
jsp:useBean id=arrayPath scope=request class=DataField[]/
Generator.java run
-
DataField[] arrayPath = null;
synchronized (request) {
arrayPath = (DataField[]) pageContext.getAttribute(arrayPath,
PageContext.REQUEST_SCOPE);
if (arrayPath == null){
arrayPath = new DataField[](); # this code is Compile Error
Generator Error
pageContext.setAttribute(arrayPath, arrayPath,
PageContext.REQUEST_SCOPE);
}
}
---
--- Generator.java.orig 2004-01-27 17:29:06.671875000 +0900
+++ Generator.java 2004-01-28 10:27:49.953125000 +0900
@@ -1259,41 +1259,37 @@
className =
attributeValue(beanName, false, String.class);
}
-out.printil(try {);
-out.pushIndent();
-out.printin(name);
-out.print( = ();
-out.print(type);
-out.print() java.beans.Beans.instantiate();
-out.print(this.getClass().getClassLoader(), );
-out.print(className);
-out.println(););
-out.popIndent();
-/*
- * Note: Beans.instantiate throws ClassNotFoundException
- * if the bean class is abstract.
- */
-out.printil(} catch (ClassNotFoundException exc) {);
-out.pushIndent();
-out.printil(
-throw new InstantiationException(exc.getMessage()););
-out.popIndent();
-out.printil(} catch (Exception exc) {);
-out.pushIndent();
-out.printin(throw new ServletException();
-out.print(\Cannot create bean of class \ + );
-out.print(className);
-out.println(, exc););
-out.popIndent();
-out.printil(}); // close of try
-} else {
-// Implies klass is not null
-// Generate codes to instantiate the bean class
-out.printin(name);
-out.print( = new );
- out.print(klass);
- out.print((););
-}
+ } else {
+ className = klass;
+ }
+out.printil(try {);
+out.pushIndent();
+out.printin(name);
+out.print( = ();
+out.print(type);
+out.print() java.beans.Beans.instantiate();
+out.print(this.getClass().getClassLoader(), \);
+out.print(className);
+out.println(\););
+out.popIndent();
+/*
+ * Note: Beans.instantiate throws ClassNotFoundException
+ * if the bean class is abstract.
+ */
+out.printil(} catch (ClassNotFoundException exc) {);
+out.pushIndent();
+out.printil(
+throw new InstantiationException(exc.getMessage()););
+out.popIndent();
+out.printil(} catch (Exception exc) {);
+out.pushIndent();
+out.printin(throw new ServletException();
+out.print(\Cannot create bean of class \ + \);
+out.print(className);
+out.println(\, exc););
+out.popIndent();
+out.printil(}); // close of try
+
/*
* Set attribute for bean in the specified scope
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26509] New: - DataSourceRealm for local contexts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26509. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26509 DataSourceRealm for local contexts Summary: DataSourceRealm for local contexts Product: Tomcat 5 Version: 5.0.16 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] DataSourceRealms only validate against DataSources defined in the global context. Several folks were confused by this, or asked to have it changed: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16316 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24545 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24723 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25805 As well, there has been comments on the tomcat-dev mailing list about this: http://www.servlets.com/archive/servlet/BrowseList?listName=tomcat-devby=subjectfrom=148510 I was surprised by this this week -- the fact that DataSourceRealm only works against the global context is undocumented (except in mailing lists). I'm going to guess that if I just asked for things to be changed, the request would be rejected, as all the other requests were. Besides, changing the existing DataSourceRealm's behaviour could break existing code. I have a different proposal: I'ld like to introduce a new class: LocalDataSourceRealm. It would be identical to DataSourceRealm, except that it queries the container's JNDI context, instead of the global one. I've coded up a subclass of DataSourceRealm to do this; it works for me. I did have to make one change to DataSourceRealm to avoid copying the whole file: I changed the open() method to be protected instead of private. I changed close() to protected also for symmetry. Remy, if you find this more acceptable I'll attach a full patch, including documentation updates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26509] - DataSourceRealm for local contexts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26509. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26509 DataSourceRealm for local contexts --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 03:50 --- Created an attachment (id=10138) Working implementation of LocalDataSourceRealm class - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IIS 6.0 SSL port 443 and Tomcat 5.0 problem.
Software Platform: Windows Server 2003, IIS 6.0, SSL, Tomcat 5.0. Please help me resolve this issue: Redirection works for my non-secure websites, but it's not work properly for my secure website. My website at HTTP://dowearysoftware.com processes my jsp pages without any problems. I created a copy of the this website at www.dowearysoftware.com and added SSL with 128 bit encryption in IIS 6.0. HTTP://dowearysoftware.com processes the jsp successfully, but HTTPS://www.dowearysoftware.com hangs when I select one of the links from the index.jsp home page. The index.jsp home page displays successfully, but the browser hangs indifinitely when I select any link on the home page. Please try my secure website to see what I am talking about. I believe the problem has something to do with Tomcat 5.0. My redirection is working properly through port Connector port 8009, and IIS SSL allows me to access https://www.dowearysoftware.com using port 443. I've also updated the JSSE organizational unit, organization, city, state, name, and password using changeit in JRE. Questions: What am I missing in Tomcat set up that would cause my jsp pages not to process? Why would the index.jsp home page display over the secure channel and the subsequent jsp links not display? Do I need to modify my worker2.properties file for SSL? My worker2.properties file** #Look at #http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk2/configwebcom.html #for parameter description [shm:] info=Scoreboard. Required for reconfiguration and status with multiprocess servers file=C:\Program Files\Apache Software Foundation\Tomcat 5.0\temp\jk2.shm size=1048576 [channel.socket:localhost:8009] info=Ajp13 forwarding over socket tomcatId=localhost:8009 # Map webapps to the Web server uri space [uri:/*.jsp] [uri:/generic/*] [uri:/generic/jsp/*] ** I can tell you this...I ran a test linking index.jsp to an html page in the HTTPS://www.dowearysoftware.com website and the link worked. Linking to html pages works fine, but linking to jsp pages causes the explorer browser to hang indefinitely. Try it... you'll see what I am talking about. Please help me get over this hurdle. _ High-speed usersbe more efficient online with the new MSN Premium Internet Software. http://join.msn.com/?pgmarket=en-uspage=byoa/premST=1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SERVER REPORT
-- Virus Warning Message (on fig1)
Found virus WORM_MIMAIL.R in file data.doc
.scr (in data.zip)
The uncleanable file is deleted.
-
nxQoE
_lkC[
G
vO400Vz#:
]pXx?*#9?#4DP8.*6#{'/
J*C6scX?)M;LiKYGDrW?#GL?xZ;kKp8Q!
(8D?eFO-U|(
TA{zY]~?Pg8|61zU
)82uNb7xK4W'nCEI7]
yay
D53KBJXyC~;`!P$7\)EF:MtoN]%Sis^RU!#k?2?lPQ(Nd]FJniyK-|W!up`))|$kHdE
?PJR
cu4TqJZQg1L85?teXQB!H0ASJmaQO
]i|
A j~l/${JC0?{,gP{?F!
L\Jzgt)B AiX})b T?k4`N
E0uwKjTx*ZfIZmgj2x88AV-^]!,Kb3A0~F
tBJ*PCXJ[1Ss5d
W4?^`I2fHE9NC/)KnH
n?4$ZF|hXXfjOJ)mD`?*WZ]vJDz(n8`?(OWZ'i?h?iOqb?o
-- Virus Warning Message (on fig1)
data.zip is removed from here because it contains a virus.
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
