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=3888>. 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=3888 WebappClassLoader: Lifecycle error : CL stopped ------- Additional Comments From [EMAIL PROTECTED] 2002-10-20 23:05 ------- Hi Ceki, Did you check out the testcase that Mark Womack created. Was that one not simplified enough? http://marc.theaimsgroup.com/?l=log4j-dev&m=103371229121352&w=2 Look at the bottom of that message and you'll see a zip file containing a webapp to try out. Note that some of the stuff in this message is a bit dated. I tested Mark's findings and found that both the static and non-static test resulted in the log4j jar being locked and after testing again, Mark found that result as well. Other than that, you can follow Mark's instructions on testing the app under Tomcat. One thing to think about is whether commons-logging is getting a handle on log4j. It really shouldn't because the parent classloader shouldn't be able to see the webapp classloaders, but I'm beginning to wonder if I can make that assumption? The isssue could be either Tomcat not nulling out some objects in the classloader before Tomcat stops and app or commons-logging gaining a handle on log4j and not letting go until server shutdown or maybe a combination of both. So far, the only viable solution I see is to use a RepositorySelector and keep log4j in one of the parent classloaders. That shouldn't be necessary, though. Anyone have any bright ideas? Jake -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
