Summary: | log4j is susceptible to exceptions thrown by Exception classes | ||
---|---|---|---|
Product: | Log4j - Now in Jira | Reporter: | David Johnson <davidj> |
Component: | Appender | Assignee: | log4j-dev <log4j-dev> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | fapache, thorbjoern |
Priority: | P2 | ||
Version: | 1.2 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | other | ||
Attachments: | Example to simply reproduce bug. |
Description
David Johnson
2007-12-07 10:29:17 UTC
Yes, this seems like a really bad idea. I ran into this too. The telnet appender has issues that can cause a null pointer (bug 44109) and those blow right back out into calling code too. A call to "log" shouldn't ever throw an exception back - it should trap it and report is somewhere, perhaps to the loggers that are working, or at a minimum to the console. This sound like a good idea. Just to be certain that the bug report is understood correctly, can you create a small example which shows the behaviour? Created attachment 23185 [details]
Example to simply reproduce bug.
I just bumped into the very same bug and since there was no recent activity I created an example myself. It proves the bug against 1.2.15. You will find the details in the attached file. I did not offer a patch because IMHO it's just a matter of try/catch in ThrowableInformation.getThrowableStrRep() and someone who knows log4j better might also know what smart thing may be appropriate after catching :) P.S. My real case was logging AxisFault through AsyncAppender. Somehow between logger.error(...) and effective buffer flush to disk the exception passed became invalid and caused the async appender to fail, producing later a global failure for the entire application. Adding myself to cc. Committed fix in rev738488 |