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=43867>. 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=43867 ------- Additional Comments From [EMAIL PROTECTED] 2008-01-25 11:49 ------- The underlying problem has to be resolved in Tomcat. If the Tomcat team would suggest modifications that would make log4j immune to their classloader mucking with class invariants and leaving the class in limbo, it would likely be too drastic to consider to do this late in log4j 1.2's life. So that leaves the question of what log4j should do in the circumstance that it is left in a corrupt state. Prior to log4j 1.2.15, log4j would throw a NPE when an attempt was made to log after the Tomcat class-loader did its damage. In log4j 1.2.15, if that situation occurs log4j emits an error message which is definitely an improvement over a NPE. You have observed that log4j 1.2.15 appears to be more likely to get in that state than log4j 1.2.14 since you never saw the NPE with earlier versions, but now see the error message. That likely is not directly related to the presence of the check and error message. Removing the check for the null repository selector may or may not change the frequency of log4j being in a corrupt state, but it would cause the NPE's to return when it got in that state. It is unreasonable to expect log4j to perform perfectly when the class loader has put it in a state that is not reachable by ordinary means. The options are: 1. Fix the tomcat class loader or provide instructions to avoid the scenario. That would have to be done by the Tomcat project. 2. Identify characteristics that make a library more likely to be corrupted. If the Tomcat project could identify that, we may (or may not) be able to adjust log4j to reduce the likelihood of getting in the corrupt state. 3. Remove the check for null repo which would cause NPE's to return. 4. Change the error to a warning message. 5. Change the error to a debug message (which would generally not be displayed). 6. Change the message so it is not as frightening. -- 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]
