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=41939>. 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=41939 ------- Additional Comments From [EMAIL PROTECTED] 2007-03-26 06:38 ------- This bug should not be dismissed. My own web application includes one instance each of commons-logging-1.1.jar and log4j-1.2.14.jar. My $CATALINA_HOME/common/lib does not contain a commons-logging jar (unless the class files are embedded in one of the other jars???). Additionally, the NPE is thrown by log4j code. In fact, I have done some debugging on the log4j code-base, and the behavior that I witnessed defied standard java convention. That is, the NPE is caused by certain static class fields (whose values are set at instantiation) arbitrarily becoming null when one attempts to reload the context that contains the log4j jar. In effect, certain static members of the log4j classes are not being re-initialized when the context is reloaded. For my part, I have worked around the issue by patching my log4j to re-initialize the problem fields itself when they are detected to be null, but in all honesty, this hack should be unnecessary. Now, I would not say that this bug is a number one priority show-stopper (or even that it should be fixed), but it should, at least, be acknowledged. -- 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]
