DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 16:34 --- *** Bug 36250 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 16:41 --- *** Bug 36250 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 --- Additional Comments From [EMAIL PROTECTED] 2005-08-22 18:24 --- *** Bug 36250 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-08-18 19:21 --- *** Bug 36250 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 --- Additional Comments From [EMAIL PROTECTED] 2005-08-16 19:57 --- Sorry, the FAQ points to this issue but it still isn't clear to me how to fix it. Tomcat/bin contains commons-logging-api.jar Each webapp ships with its own log4j*.jar files so what should I be changing in my configuration to prevent a ThreadDeath? Please clarify. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
Thank-you for your e-mail. Please note that i will be away from the office starting Wednesday June 29th, returning Thursday July 7th, with no access to email. In my absence, kindly contact Cheri Dueck at [EMAIL PROTECTED] Kind Regards, Natasha Hasmani Senior Event Manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 Bug 26372 depends on bug 27371, which changed state. Bug 27371 Summary: java.lang.ThreadDeath caused by log4j when reloading Tomcat app http://issues.apache.org/bugzilla/show_bug.cgi?id=27371 What|Old Value |New Value Status|REOPENED|RESOLVED Resolution||INVALID -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-12-31 10:51 --- Please do not reopen the report. If you look in the code, you'll see that if you issue a stop or reload, it will wait only a limited amount of time for current requests to complete. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-12-31 04:56 --- I ran into this issue, and having written a trivial test case, I can confirm that this zilla has nothing to do with logging (commons or log4j) or parent classloaders etc. No amount of fiddling with library classloading will fix it. The real cause is that Tomcat is invalidating (through a call to stop()) the WebappClassLoader belonging to a servlet instance whose service() method runs a little longer than usual in some conditions (2 seconds is enough). This can happen under heavy (server, DB) load, with threads still running in service(), and may occur in any lifecycle event that runs StandardWrapper.unload() e.g. stop, undeploy, reload, shutdown. If the longish service() method needs to load a class after unload() loses its patience, WebappClassLoader throws a ThreadDeath. Might want to leave this one open until I get a chance to log a couple of more concise zillas. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-10-22 17:29 --- Allistair, I'll be glad to continue this discussion on the mailing list and try and explain why I think reloading an app in-place has only limited usage in production environments. This (Bugzilla) is not the right forum for discussions. I'm closing this item as it's not a Tomcat bug, and a link to it has been added to the Tomcat FAQ. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-14 08:06 --- sorry you thought it was a rant, it wasn't meant to come over like that :) i suppose because tomcat has a manager application and reloadable class facility, i assumed it should do that gracefully in all circumstances. it is true i don't fully appreciate all the issues with this feature so i suppose this is just an issue we have to workaround. In fact, the workaround has been listed here now. It is also true that this is in our case was always related to a development instance. I am interested in your comment that reload of webapp is mostly trouble and limited in production environments though. My understanding was that if you want to make a build to production or a patch of some files, you would use ant or similar as we do here to reconstruct the WAR to deploy. Does this not require tomcat being able to reload? In fact, we tell the business the intranet will be down for 5 minutes and post a message page up for inbound requests. We stop tomcat, delete the old war and expanded war files and place the new war and startup tomcat again. We constantly get irked by the fact that if a bug is on production we have to wait until the evening to patch it whereas our ASP coutnerparts can so easily hot-patch. We also use JSP precompilation to improve performance so it's not so easy to patch JSPs either. Anyways! Cheers PS: this was not a rant ... just inquisitive ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-14 08:35 --- I hope hot deployment and redeployment is a reality. However, there are issues when the webapp tries to interact with some services which reside in the system classloader (logging here). Packaging webapps a little differently could solve the problems for now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-13 18:56 --- There's a significant difference between commons-logging.jar and commons- logging-api.jar, it's not just a rename. Every version of commons-logging has both distributions and for good reason. As for the rant about being able to use whatever library and not wortying about the web server dying: I'd point out it's only 'dying' when you're trying the app reload, nor normal usage. This feature is not mandated by the Spec so we're not obliged to provided it in the first place: it's caused mostly trouble and has very limited usage in production environments. So if you have patches for it, that's great, but the common usage scenario for Tomcat doesn't include webapp reload, and so doesn't suffer from this issue at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-11 08:18 --- I have found out that the reason I managed to have this problem in the first place is because I upgraded to Struts 1.2.4 recently where the bundled JAR for common is commons-logging.jar. Would it make sense to rename Tomcat's JAR to commons-logging? Also, is it really not a Tomcat problem that user's cannot use APIs like Struts and who knows what else from Jakarta that demand or come packaged with commons-logging? It seems to me that the webapps should work first and foremost with whatever APIs they like in their LIB and should not have to worry about the application server dying? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-10 20:56 --- If you (any of the people following this thread) want, please suggest text that I can put in the following places: - Tomcat's Logging configuration page - Tomcat's FAQ - Log4J FAQ - Other places you find appropriate Otherwise, I'll come up with some text myself (which will include a link to this Bugzilla issue) and place the text at the above locations. At that time I will close this item, as it's not a Tomcat bug and there's no reason for it to stay open. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 13:13 --- I wouldn't be quick to conclude this will disappear from Tomcat 5.5. Tomcat 5.5. still uses commons-logging (in fact, more heavily than before), and still locates the commons-logging jar on the bin classpath, because it uses it from the very startup of the server. Tomcat 5.0 and 5.5 both require commons- logging. What your investigation reveals, I think, is that the version of commons-logging used by the webapp must be the same as that uses by Tomcat (which uses the latest stable commons-logging build). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 13:42 --- I've commented a while ago on how to properly package commons-logging: - commons-logging-api goes in the system classloader (it will go first in the delegation order) - put the necessary commons-logging wrapper classes for the logger you're using at the same spot as your logger JAR This seemed to avoid problems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 09:02 --- Ceki asked for log4j and commons-logging jar locations. It revealed a disparity between commons-logging in tomcat's bin and the webapp lib. Initial tests with our original log4j file and now replacing commons-logging in the webapp with the commons-logging-api version found in tomcat's bin, is successful. I suppose this will disappear from TC 5.5 but it does appear to have gone away for now .. We will keep an eye on it, but this appears to be the problem - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application [EMAIL PROTECTED] changed: What|Removed |Added Summary|java.lang.ThreadDeath when |java.lang.ThreadDeath when |trwaing to reload an|trying to reload an |application |application Version|5.0.16 |5.0.25 --- Additional Comments From [EMAIL PROTECTED] 2004-10-05 15:17 --- OK, Can confirm that contextDestroyed is called. Discovered LogManager.shutdown(); is working because a logging statement afterwards does not materialize but one before it is fine. System.out.println was used instead. Here is the relevant logging INFO: Reloading this Context has started before Renewals Application Destroyed one Renewals Application Destroyed two Renewals Application Destroyed after Renewals Application Destroyed log4j:WARN No appenders could be found for logger (org.apache.struts.util.PropertyMessageResources). log4j:WARN Please initialize the log4j system properly. 05-Oct-2004 16:13:38 org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already (the eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact) 05-Oct-2004 16:13:38 org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already (the eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact) 05-Oct-2004 16:13:38 org.apache.commons.modeler.Registry registerComponent SEVERE: Null component Catalina:type=JspMonitor,WebModule=//localhost/,J2EEApplication=none,J2EEServer= none 05-Oct-2004 16:13:38 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren SEVERE: Exception invoking periodic operation: java.lang.ThreadDeath at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1229) at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1189) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at org.apache.log4j.spi.LoggingEvent.init(LoggingEvent.java:241) at org.apache.log4j.Category.forcedLog(Category.java:431) at org.apache.log4j.Category.log(Category.java:966) at org.apache.commons.logging.impl.Log4JLogger.error (Log4JLogger.java:195) at org.apache.catalina.session.StandardManager.start (StandardManager.java:659) at org.apache.catalina.core.StandardContext.start (StandardContext.java:4272) at org.apache.catalina.core.StandardContext.reload (StandardContext.java:3021) at org.apache.catalina.core.StandardContext.backgroundProcess (StandardContext.java:4629) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChild ren(ContainerBase.java:1619) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChild ren(ContainerBase.java:1628) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChild ren(ContainerBase.java:1628) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run (ContainerBase.java:1608) at java.lang.Thread.run(Unknown Source) And here is the log4j.properties file. # # Renewals Log4j Configuration # Root #log4j.appender.stdout=org.apache.log4j.ConsoleAppender #log4j.appender.stdout.Target=System.out #log4j.appender.stdout.layout=org.apache.log4j.PatternLayout #log4j.appender.stdout.layout.ConversionPattern=%d - %5p (%C:%L) - %m%n log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=c:/jakarta-tomcat-5.0.25/logs/root.log log4j.appender.R.MaxFileSize=100KB log4j.appender.R.MaxBackupIndex=1 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%d - %5p (%C:%L) - %m%n log4j.rootCategory=error, R
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-05 15:47 --- I suppose the following output lines confim that the trio we talked abour earlier is being called. INFO: Reloading this Context has started before Renewals Application Destroyed one Renewals Application Destroyed two Renewals Application Destroyed after Renewals Application Destroyed Am I Correct? What happens if you simplify the log4j.properties file to say: log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.Target=System.out log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d - %5p (%C:%L) - %m%n log4j.rootCategory=error, console log4j.logger.org.apache.struts=debug If you wish, we can continue this discussion directly. My email is Ceki AATT qos DDOOTT ch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26372. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application --- Additional Comments From [EMAIL PROTECTED] 2004-10-05 16:30 --- You are correct. These were just output messages entered between the 3 calls to ensure they were being called. We can confirm ThreadDeath occurs even with the simplified log4j. Cheers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
