https://issues.apache.org/bugzilla/show_bug.cgi?id=45721
--- Comment #11 from Curt Arnold <[EMAIL PROTECTED]> 2008-09-04 10:15:50 PST --- I've thought a little bit more of this on the drive back home and hope to look at the issue in detail in the next 24 hours. PatternLayout or EnhancedPatternLayout probably isn't the appropriate place for the enhancement since it may be in a totally different environment that the original caller. For example, if the LoggingEvent + ThrowableInfo has been serialized and sent to Chainsaw over a SocketAppender, you'd get the jar or version of the class in Chainsaw's environment. I'd leaning more toward trying to mimic the ObjectRenderer approach and allow you to either register a ThrowableRenderer class through a system property or configuration file. Something like: java -Dlog4j.ThrowableRenderer=org.apache.log4j.EnhancedThrowableRenderer The ObjectRenderer interface could be used for the ThrowableRenderer, but a new interface would likely be better. I'm guessing Paul was decompiling his JVM's implementation of Throwable.printStackTrace either explicitly or implicitly through a debugger. Different versions of the class library implemented printStackTrace differently (we had some tests fail due to slight differences in JRockit's and GCJ's implementation of printStackTrace). It is good to know that "at" appears to be fixed, but users could still override an exception's printStackTrace() and confuse the trace parsing. Using getStackTrace would be more reliable, but would require JDK 1.4. Specifying the throwable renderer as a class would allow the user to customize the behavior if they ran into that type of problem. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
