https://issues.apache.org/bugzilla/show_bug.cgi?id=45721
--- Comment #13 from Curt Arnold <[EMAIL PROTECTED]> 2008-09-04 21:08:26 PST --- >From comment #12 >I'm not sure how this gets around your Chainsaw scenario at all, doesn't this >suffer from the same problem? Anyway, I think this sort of problem just needs >to be documented. Unless the serialized form of the ThrowableInformation can >carry with it all the details of the classes at computation time so that it can >be displayed on some remote end. That would change the payload weight of that >class significantly though. I'm not sure that is going to be worth the >cost/effort. AsyncAppender and the SocketAppenders call LoggingEvent.getThrowableStrRep() before queuing the logging event or sending it across the wire. The serialized form of the ThrowableInfo only contains the resulting string representation of the throwable. Any configured ThrowableRenderer would occur in this step which would be on the thread doing the logging and not in the dispatching thread or deserializing environment. >I had always thought the Layout was responsible for emitting the Throwable >string, but as I learnt yesterday working on Pinpoint that that's not actually >correct. That felt odd to me. Really the Layout should be responsible for >outputting the Throwable in it's presentation form (if needed), but obviously >log4j's design, right or wrong, now prohibits that approach. The log4j 2.0 two pass approach of an extract phase during the call to extract value objects followed by a render phase, likely deferred, that only works on the extracted value objects should allow arbitrary formatting of the Throwable. However, the log4j 1.2 design limits the layout to working with the output of ThrowableInfo.getThrowableStrRep. >Having a ThrowableRenderer is actually probably the best of all worlds. It >would be nice to have the Configurators support this new property (ala >log4j.debug), and even nicer if it didn't have to specify a full class name >(log4j.useSpiffyExceptionFormat which uses a known default class). Could prepend "org.apache.log4j." if Class.forName() can't find the class, so you could do either log4j.ThrowableRenderer=org.apache.log4j.SpiffyExceptionRenderer or log4j.ThrowableRenderer=SpiffyExceptionRenderer The ObjectRenderer classes are in org.apache.log4j.or, I guess we could add "org.apache.log4j.tr". However, abbreviations in package names aren't desirable and adding three more classes to org.apache.log4j doesn't seem like a big deal. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
