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 _______________________________________________ logback-dev mailing list [email protected] http://qos.ch/mailman/listinfo/logback-dev
