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 carnold@apache.org 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
|