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=37498>. 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=37498 ------- Additional Comments From [EMAIL PROTECTED] 2006-03-16 09:36 ------- (In reply to comment #5) > getLogger().getClass().getClassLoader() == WebappClassLoader > this.getClass().getClassLoader() == StandardClassLoader > > Maybe this is 100% correct and expected behaviour How did you guess ? ;) > . But the problem that occurs > is the call to log the Tomcat Container situation relys on the web-apps class > files (which we just deleted/removed). The files are "deleted/removed" after, when stopping the classloader. In listenerStop, the classloader is fully able to load any class, and the context classloader is also correctly set. > Okay.. I think I may have a proper path for this problem, during the setup of > the Context in StandardContext#start() we zap the logger instance for use > while > re run some web-app related method. This is because some (bad) components may call getLogger before the context classloader is correctly set. This is not the case here. > I think we should also zap it again when we unbind and return that thread back > to the containter execution context so all future logging is done with TCs > logging instances from StandardClassLoader. This is not "future logging", this is perfectly valid logging, done in the application context, which is still available. > Please explain any specific objections to that. The issues is that there's no reason to do that. > I realize logging and > ClassLoaders are a nightmare. No. Only certain technologies have issues. You would have no issues with java.util.logging, for example. -- 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]
