logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 45721] [PATCH] when showing a stack trace - include the relative package versions and optional jar name to aid debugging
Date Thu, 04 Sep 2008 22:32:49 GMT

--- Comment #12 from Paul Smith <psmith@apache.org>  2008-09-04 15:32:48 PST ---
(In reply to comment #11)
> I've thought a little bit more of this on the drive back home and hope to look
> at the issue in detail in the next 24 hours.  PatternLayout or
> EnhancedPatternLayout probably isn't the appropriate place for the enhancement
> since it may be in a totally different environment that the original caller. 
> For example, if the LoggingEvent + ThrowableInfo has been serialized and sent
> to Chainsaw over a SocketAppender, you'd get the jar or version of the class in
> Chainsaw's environment.

This is technically true.  The common case though is for the local appender to
benefit from it.  If we added a property to PatternLayout as James has done, it
can be documented with the fact that the rendered string is only relevant to
local environments.

> I'd leaning more toward trying to mimic the ObjectRenderer approach and allow
> you to either register a ThrowableRenderer class through a system property or
> configuration file.  Something like:
> java -Dlog4j.ThrowableRenderer=org.apache.log4j.EnhancedThrowableRenderer
> The ObjectRenderer interface could be used for the ThrowableRenderer, but a new
> interface would likely be better.

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

> I'm guessing Paul was decompiling his JVM's implementation of
> Throwable.printStackTrace either explicitly or implicitly through a debugger. 
> Different versions of the class library implemented printStackTrace differently
> (we had some tests fail due to slight differences in JRockit's and GCJ's
> implementation of printStackTrace).  It is good to know that "at" appears to be
> fixed, but users could still override an exception's printStackTrace() and
> confuse the trace parsing.  Using getStackTrace would be more reliable, but
> would require JDK 1.4.  Specifying the throwable renderer as a class would
> allow the user to customize the behavior if they ran into that type of problem. 

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.

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).

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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message