[ http://jira.qos.ch/browse/LBCLASSIC-46?page=com.atlassian.jira.plugin.system... ] Joern Huxhorn commented on LBCLASSIC-46: ---------------------------------------- Well, you are right about the reconstruction. It's still possible, even though it's more complex than before because of the additional version information. I've implemented the parsing for the previous ThrowableInformation for the case where the setAccessible call on throwable failed due to SecurityException but I wasn't feeling too well about that approach from the beginning. I also lost the "x common frames omitted" feature because of it, just to save some processor cycles :p My main point is that it generates additional heat. Both the creation of the ThrowableProxy and the reparsing on my side will cost some logging time. I'm also a bit wary about future changes. Those are always more time-consuming and error-prone to implement in case of string parsing than with "proper" data objects. I would like to avoid both the performance impact and the instability inherent to the parsing approach, if possible. A ThrowableProxy like class ThrowableProxy { String throwableClassName; String message; StackTraceElementProxy[] stackTrace; ThrowableProxy cause; int omittedFrames; transient String stringRep; } shouldn't mean any more work on your side (probably even a bit less) and would mean quite a bit less for me. The only downside I see right now is that the "cause" ThrowableProxy would also cache it's string representation, meaning it would cost some memory. But this could be prevented by adding a flush() method which nulls the stringRep so ThrowableProxy could call flush() on the contained cause ThrowableProxy after creation of their own stringRep. One of the use cases I have in mind is to optionally only show the top-most and/or the root cause of the exception in the details view of Lilith. Just to show you that I actually have a reason beside the xml structure... :D I really hope you can do me this favor...
ThrowableInformation should keep the Throwable cause hierarchy intact. ----------------------------------------------------------------------
Key: LBCLASSIC-46 URL: http://jira.qos.ch/browse/LBCLASSIC-46 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: unspecified Environment: Operating System: All Platform: All Reporter: Joern Huxhorn Assignee: Ceki Gulcu Priority: Minor
Instead of a String representation of the whole Throwable stack trace incl. cause ThrowableInformation should instead look like this: public class ThrowableInformation implements Serializable { String throwableClassName; String message; StackTraceElement[] stackTrace; ThrowableInformation cause; } I omitted get/set and private in this example. StackTraceElement is perfectly Serializable and did also receive a public c'tor in Java 5 so I guess that the current ThrowableInformation is more or less a relict of log4j which had to stay compatible with older Java versions. You could obviously keep the getThrowableStrRep() method for compatibility. This bug is somewhat related to LBCLASSIC-45 because I think that ThrowableInformation should also, as LoggingEvent, be just a dumb data container with no real logic. The logic to extract the relevant StackTraceElements should IMHO be moved either into Logger or into a static factory method of ThrowableInformation.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira