logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: ThrowableInformation.getThrowable()
Date Wed, 16 Mar 2005 17:47:41 GMT

Thanks for bringing up this point. You've made quite a convincing case.

At 05:46 PM 3/16/2005, Krassavine Anatoli wrote:
>I have noticed that in 1.3-alpha ThrowableInformation does not store the 
>throwable it represents. I followed the discussion about it and I 
>understand the logic behind this decision. However, I have encountered a 
>situation in my project where my inability to get to original Throwable 
>object from inside Log4J is a serious showstopper, which leaves me with 3 
>1) Cap version of log4j we use at to 1.2.9
>2) Ditch log4J in favour of Sun logging
>3) Hack log4J code and create a custom library
>None of these approaches is something I like, hence I wanted to petition 
>to either reinstate ThrowableInformation.getThrowable() or to be given an 
>advice on how to work around this restriction.
>For the projects I am working on I need to develop a comprehensive 
>diagnostics system. In development terms it means custom appenders and 
>filters. A significant amount of business logic requires access to 
>exception object and its full exception stack:
>1)       Identification of duplicate exceptions
>2)       Access to additional context information stored inside exception 
>as value objects
>3)       Intelligent auto-learning logging event routing
>Up to 1.2.9 LoggingEvent provided me with a wealth of information to work 
>on. In 1.3 suddenly all I could work with is a string dump of a stack 
>frame. First of all, this causes loss of a significant amount of context 
>information. Second, it requires me to spend a disproportionate amount of 
>time analysing the text and converting it back to typed objects.
>I understand that the omission of throwable was done for the sake of 
>simplified and more consistent remote logging. However, in my case (and in 
>case of majority of log4j users) remote logging is a minority special 
>case. Most of the logging is done locally. This means that I got penalized 
>on a practical and useful feature for the sake of compatibility with 
>special cases which I rarely use.
>This seems to be a wrong way to address the issue. Instead of cutting the 
>functionality down to the least common denominator, I think log4j should 
>accept that the data content inside LoggingEvent varies depending on how 
>it was propagated – it is richer if we stay within the same JVM and poorer 
>if we do remote debugging and vary context of LoggingEvent accordingly. 
>This seems to be a fair trade-off.
>In technical terms, the simplest solution would be to reinstate transient 
>throwable variable inside ThrowableInformation.
>Please advice.
>Yours Sincerely,
>      Toly
>Anatoli Krassavine
>Solutions Architect
>Post Office Account
>Fujitsu Services LTD
>Forest Road, Feltham, Middlesex, TW13 7EJ
>This e-mail is only for the use of its intended recipient.  Its contents 
>are subject to a duty of confidence and may be privileged.  Fujitsu 
>Services does not guarantee that this e-mail has not been intercepted and 
>amended or that it is virus-free.

Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message