[logback-dev] Logback 0.9.12 ?
ceki at qos.ch
Wed Dec 3 23:34:38 CET 2008
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
> 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.
Logback: The reliable, generic, fast and flexible logging framework for Java.
More information about the logback-dev