logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 43867] - NOPLoggerRepository error during shutdown
Date Fri, 25 Jan 2008 19:49:25 GMT
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


Mime
View raw message