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-12-08 16:11 ------- i think i know how to reproduce and prevent this error. assistance from the tomcat developers could enhance the workaround. the problem (for me) seems to stem from bad commons-logging interaction. the commons-logging that the container uses to log errors from my context ends up discovering the commons-logging.jar and log4j.jar that I have put in my WEB-APP/lib. the container ends up with instances of classes loaded by the WebAppClassloader associated with the initial instance (initial start cycle) of the webapp. when reload happens, that classloader becomes invalid, and any further classloading that is attempted through it will cause ThreadDeath. However, any classes previously loaded are (apparently) still OK. so the main cause of ThreadDeath can be avoided if all the classes that need to be loaded are loaded while the initial WebAppClassloader is still valid (i.e. before the first reload). the easiest way to force all the classes to load is to LOG A MESSAGE from the appropriate context. until a message has been logged, not all classes in the logging 'execution path' will have been accessed, and so there will be some class loading that happens during the first logged message. after that, that execution path will be 'loaded' and can run till the cows come home. for me, the easiest thing to do is force a JSP error. maybe have a JSP called cant_compile.jsp, and hit it as soon as you start up tomcat. then you will have NO problems until you shutdown tomcat again. an easy solution not requiring any changes at all is to put: log4j.logger.org.apache.catalina.session=DEBUG into log4j.properties. you will not get TOO much debug crapola in your logs (about 15 lines on startup/shutdown). here's where the tomcat developers come in. if tomcat logged something as soon as startup is complete - AT A SUFFICIENTLY HIGH LOGGING LEVEL (eg info) that it will be feasible to have logging enabled at that level. in particular, changing the debug statement at line 655 of StandardManager.java to info seems a likely candidate. then users could set (in log4j.properties or equiv): log4j.logger.org.apache.catalina.session=INFO and not get superfluous debugging statements. -- 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]
