DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 --- Additional Comments From [EMAIL PROTECTED] 2005-08-04 14:57 --- I found a solution. copy the log4j jar file and rename to another file name, such as log4j-1.2.6.jar. put the both log4j jar files to WEB-INF lib directory. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 --- Additional Comments From [EMAIL PROTECTED] 2005-08-04 15:45 --- Your solution seems more like black magic to me. What do you think you've fixed? And what is it about having 2 log4j jars in WEB-INF/lib changes the thread death behavior? You do realize that the thread death stuff is sporadic, right? You've performed an action and have found that you haven't gotten the error. You attribute the success to your action where, in reality, you can't know whether it was your action or dumb luck that led to success... unless you actually do know the real cause/effect relationship. If so, we're all ears! Until then, this is black magic. Jake -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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]
Re: DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-07-01 23:22 --- Closing as consensus indicates that it is a Tomcat issue. Wish there was a better resolution than INVALID, but that seems to be the closest fit. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 01:08 --- I'm not sure why this issue remains open, given that #26372 has been closed. Whenever there is a ThreadDeath thrown from WebappClassLoader.loadClass() during a webapp restart, it is due to Tomcat invalidating the webapp's ClassLoader while threads are still executing a (long-running) service() method (or even lifecycle method). Tomcat waits 2 seconds, then invalidates the ClassLoader and restarts the app, resulting in a ThreadDeath thrown by the ClassLoader if new class load requests occur. See my comment in #26372 . Given that #26372 has been marked invalid (read as -1 for a configurable [or perhaps longer] wait-time for current requests to complete, prior to invalidating the ClassLoader and restarting the webapp), I think that this issue should now be closed. This is a Tomcat issue for restartable webapps, not a log4j issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 00:42 --- Hi! I'm also experiencing ThreadDeath with Log4j on Tomcat 5.0.28 (bundled with NetBeans 4.0) when restarting applications. I understand you've already seen a lot of stack traces in this discussion. So I'll just give a part of mine: == Caused by: 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(ClassLoader.java:302) at org.apache.log4j.NDC.get(NDC.java:201) at org.apache.log4j.spi.LoggingEvent.getNDC(LoggingEvent.java:229) etc... == Seems like NDC is arranging its instances in a Hashtable with key being the current thread. That might be the reason of such behaviour. Have you thought of switching to ThreadLocal? I'm not sure about how it may affect the performance though. Thanks -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 [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 on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 --- Additional Comments From [EMAIL PROTECTED] 2004-11-23 23:05 --- Running the embedded Tomcat 5.5.4, after I stop and start() a web context, I got the following exception (and the AxisServlet does not run). However, with the exact same web application in the standalone Tomcat 5.5.4, I don't get any exception (and the AxisServlet runs ok) - Starting Coyote HTTP/1.1 on http-80 - Illegal access: this web application instance has been stopped already. Could not load META-INF/services/org.apache.axis.EngineConfigurationFactory. 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. - Illegal access: this web application instance has been stopped already. Could not load org/apache/axis/configuration/EngineConfigurationFactoryServlet.class. 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. - Illegal access: this web application instance has been stopped already. Could not load org.apache.axis.configuration.EngineConfigurationFactoryServlet. 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. - StandardWrapper.Throwable java.lang.ThreadDeath at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1221) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181) at org.apache.commons.discovery.ResourceClass$1.run(ResourceClass.java:77) at java.security.AccessController.doPrivileged(Native Method) at org.apache.commons.discovery.ResourceClass.loadClass(ResourceClass.java:73) at org.apache.axis.configuration.EngineConfigurationFactoryFinder$1.run(EngineConfigurationFactoryFinder.java:122) at java.security.AccessController.doPrivileged(Native Method) at org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactory(EngineConfigurationFactoryFinder.java:113) at org.apache.axis.transport.http.AxisServletBase.getEngineEnvironment(AxisServletBase.java:247) at org.apache.axis.transport.http.AxisServletBase.getEngine(AxisServletBase.java:170) at org.apache.axis.transport.http.AxisServletBase.getOption(AxisServletBase.java:370) at org.apache.axis.transport.http.AxisServletBase.init(AxisServletBase.java:110) at javax.servlet.GenericServlet.init(GenericServlet.java:211) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1053) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:886) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3817) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4079) - Servlet /axis threw load() exception javax.servlet.ServletException: Servlet.init() for servlet AdminServlet threw exception at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1095) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:886) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3817) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4079) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 --- Additional Comments From [EMAIL PROTECTED] 2004-11-23 23:35 --- I meant the AdminServlet did not run. The AxisServlet ran fine. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 java.lang.ThreadDeath caused by log4j when reloading Tomcat app --- Additional Comments From [EMAIL PROTECTED] 2004-09-22 14:12 --- Per Jay Paulsen's findings archived at http://marc.theaimsgroup.com/? t=10957839304r=1w=2, please try adding the Introspector.flush call to your shutdown code and re-testing. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 java.lang.ThreadDeath caused by log4j when reloading Tomcat app --- Additional Comments From [EMAIL PROTECTED] 2004-08-31 20:11 --- I've got the same exception, but without log4j envolvement. To reproduce try this: 1. In TC 5.0.27 login to admin application. 2. Under the Host-Create New Context create the new context pointing to some JSP webapp outside standard webapps directory. 3. When finished successfuly, try to invoke this application and you should get ThreadDeath exception. BTW, it is working fine when deploying to the standard webapps directory. Here is a stack: java.lang.ThreadDeath at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1229) at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1189) at org.apache.jasper.compiler.Parser.parseCustomTag(Parser.java:1316) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1560) at org.apache.jasper.compiler.Parser.parse(Parser.java:126) at org.apache.jasper.compiler.ParserController.doParse (ParserController.java:220) at org.apache.jasper.compiler.ParserController.parse (ParserController.java:101) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:203) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile (JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal (StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:117) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:799) ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371.
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=27371
java.lang.ThreadDeath caused by log4j when reloading Tomcat app
--- Additional Comments From [EMAIL PROTECTED] 2004-08-06 16:25 ---
I can confirm that the following does _not_ solve the ThreadDeath exception
when Tomcat reloads the context following a class compile.
import org.apache.log4j.LogManager;
import org.apache.commons.logging.LogFactory;
public void contextDestroyed(ServletContextEvent scE) {
LogManager.shutdown();
LogFactory.releaseAll();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 java.lang.ThreadDeath caused by log4j when reloading Tomcat app --- Additional Comments From [EMAIL PROTECTED] 2004-08-06 17:55 --- It seems to me that tomcat reuses these classloaders and I have a feeling that when the classloader is being reused. The classloader start method does not get called, causing the classloader to not have been started, generating the ThreadDeath exception whenever the loadClass method is called. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 java.lang.ThreadDeath caused by log4j when reloading Tomcat app --- Additional Comments From [EMAIL PROTECTED] 2004-08-06 17:57 --- What are you basing this on? Any code references would be nice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 java.lang.ThreadDeath caused by log4j when reloading Tomcat app --- Additional Comments From [EMAIL PROTECTED] 2004-08-07 00:55 --- I was looking at the WebappClassLoader class and it contains a started attribute that is used to determine that if the WebappClassLoader instance was started before it can be used to load classes. The started attribute is set using the classes start and stop methods. The ThreadDeath exception is being thrown because when the WebappClassLoader instance is calling the loadClass method it checks that the started attribute is true. If it isn't, it throws the ThreadDeath exception. I then looked at the StandardContext class. It contains a method called reload that is used whenever it wants to reload that particular web application associated to that instance of StandardContext. I also noticed that the StandardContext method will associate a single WebappLoader to the StandardContext instance. This WebappLoader contain the ClassLoader used by this StandardContext web application. The assignment of the WebappLoader is done only once and it is done within the start method only. This method initially checks if the WebappLoader has been associated to the StandardContext. It will then only assign a WebappLoader to the StandardContext if their was none. I deduced by looking at these sections of the code that it seems like whenever a StandardContext web application is being reloaded. Its WebappLoader WebappClassLoader start method is not be called before loading any of the web application classes. It does seem like its stop method is being called whenever the web application is being stopped. This is why I believe that the WebappClassLoader is not being properly setup before being used. I am basing this on looking at the code only. I have not tried to debug this case. It is only a theory based on observations and nothing else. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 java.lang.ThreadDeath caused by log4j when reloading Tomcat app --- Additional Comments From [EMAIL PROTECTED] 2004-08-05 19:36 --- --- Begin Text by Craig McClanahan --- The reason that LogFactory instances are stored in a map keyed by context class loader was to meet a functional requirement that each webapp could have independently configured constellations of Log instances, created by independent LogFactory instances, per webapp -- even if commons-logging.jar itself is installed into a shared class loader (i.e. common/lib or shared/lib in Tomcat). This is why you can't just use a static variable, because there would only be one LogFactory instance across the entire Tomcat JVM. In addition, there is no other reasonable key that is specific to a webapp, but *not* specific to the Servlet API (tying commons-logging use to require servlet.jar would not be a good thing). In order to allow cleanup of these allocated instances, the LogFactory.release() method may be used to ask a LogFactory to release all of its Log instances. In addition, the static LogFactory.release(ClassLoader) method releases references to the LogFactory instance for that class loader. I believe that both of these APIs were just added in 1.0.4. Inside Tomcat, then, a webapp using c-l can add a ServletContextListener whose contextDestroyed() method calls the appropriate release methods to clean up. --- End text by Craig McClanahan --- So to the people who reported this: please try adding such a ServletContextListener and using the above methods that Craig mentioned, and let us know if that makes the error go away. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
