I just read this in the Lilith FAQ: Why is Lilith still only supporting Logback 0.9.9? Logback 0.9.10 introduced new version information in the StackTraceElement string representation. This breaks my current implementation of parsing. Since I parse the STEs both during receiving of original Logback events and during creation of Lilith events in the multiplex appender, the parsing means a significant performance impact. Previously, I circumvented this by using a hack and accessing the STEs directly but this would noe have the downside that I wouldn't be able to retrieve the formerly mentioned version information.<br/> Because of that, I suggested a change to the Logback codebase that would make my life quite a bit easier while it wouldn't have a negative impact on the rest. It could even increase the general logging speed a bit. I hope that Ceki will be able to implement it in time for Logback 0.9.12.<br/> Feel free to take a look at <a href="http://jira.qos.ch/browse/LBCLASSIC-46">LBCLASSIC-46</a> if you like more specific informations. Ceki Gulcu wrote:
Hi Joern,
I am missing the bug picture here. Assuming Lilith receives serialized LoggingEvents, why do you need to transform the ThrowableProxy? Moreover, for exceptions, you don't need to worry about performance. By definition, exceptions are comparatively much rarer than vanilla log statements.
I am guessing that you have your own implementation of ThrowableProxy which is self-nested (on cause). It may be a little obtuse on my part but why don't you implement your ThrowableProxy the way logback's ThrowableProxy does? Is it to isolate Lilith from changes in logback? I would expect logback's ThrowableProxy to be perfectly usable by a GUI, and since we are talking about exceptions, performance should not matter that much.
Joern Huxhorn wrote:
Hi Ceki,
Unfortunately, I'm very, *very* occupied during normal working hours because we're in a hot phase of some of our projects (until february!) so we'd have to arrange a call at around 21:00 or something like that.
One very important point about LBCLASSIC-46 is that you should ignore everything before my "29/Oct/08 10:58 AM" comment because it's essentially outdated. I'll try to write up a understandable ;) summary of what I'm trying to achieve with my suggestion... it's mainly about increasing performance in both Logback and Lilith.
I'll probably just implement it and attach a patch so you can just see for yourself what I mean.
Regards, Joern.
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch