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=34945>. 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=34945 Summary: ThrowableInformation has dubious Stack Trace extraction feature Product: Log4j Version: 1.3alpha Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Appender AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] For every exception, Log4J examines the class (using reflection) to print out the stack trace. For 1.4, this is not necessary, as printStackTrace does the right thing already. For earlier JVMs, it may be better to rely on the client to enhance their Throwable.printStackTrace implementation to do the right thing. There is a good example on how to do this for JVM 1.3: http://www.javaworld.com/javaworld/jw-09-2001/jw-0914-exceptions.html Since I modify printStackTrace for my exception classes, log4j 1.3 could log my "cause"s twice. This would break backwards compatibility for some people. In addition, relying on the method name (which may or may not return a Throwable) may cause problems. For example, if getRootCause() returned a String (or some other type). What if the method call had unforseen side effects? Mainly, it's a performance hit. At least I would recommend skipping the linear search on the method names for JVM 1.4+. (Since java.lang.Throwable must be serializable, I also wonder why it is serialized in this fashion at all. Wouldn't it make sense to defer serialization to output?) -- 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]
