logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re: conversion patterns and caller class information
Date Sun, 06 Jun 2004 13:19:34 GMT
At 11:59 AM 6/6/2004 +0200, you wrote:

>Hi Jake,
>At 08:16 PM 6/5/2004, Jacob Kjome wrote:
>>I'm noticing an issue with using the conversion characters which generate 
>>caller class information.  In a project I'm working on, logging is done 
>>via a sort of Monitor framework.  Anything can back the Monitor whether 
>>it be System.out, nothing, Log4j, etc.  This makes it so that no logging 
>>framework becomes a runtime dependency of the library unless a user 
>>explicitly configures the library to use a particular Monitor 
>>implementation such as one backed by Log4j.  The thing is, classes call 
>>the monitor to let the obfuscated logger implementation do the 
>>logging.  As such, if I use the Log4j implementation and use the 
>>conversion characters such as "C", "F", "L", and "M", it ends up looking 
>>like logging came from the Log4jMonitor rather than the class that is 
>>calling the log4j monitor, which is what I'd want.
>With respect to the conversion characters such as "C", "F", "L", and "M", 
>how is monitoring different than wrapping? You are aware of the


>  message,

>method right?

Ok, that brainfart was a bit embarrassing!  Of course you are right and it 
works just fine.  I've given the above advice before to others and yet I 
didn't think about using it myself.  Ug!!!

>>The whole Monitor idea kind of came from this post:
>How is the monitor handed down to the reusable component? It looks to me 
>like the logger initialization problem has been replaced by the monitor 
>initialization problem. I don't see the gain... Anyone care to explain?

A single monitor is handed to, essentially, a container which then provides 
this component to all classes in the framework that require it.  In each 
class that will use the monitor, I just provide a Monitor instance 
variable.  I don't create the monitor in the class itself as is the normal 
Log4j usage.  It it up to the user to configure a Monitor implementation 
(or get a default backed by either nothing or System.out) for the container 
and the container will provide it to any class that needs it.  This way the 
user has full control over the components rather than the programmer 
defining components inside the class outside of the control of the 
user.  It's all about IOC (Inversion of Control).  You may have read about 
this stuff before in articles about Picocontainer ( 
http://www.picocontainer.org/ ) and Spring Framework ( 
http://www.springframework.org/ ), to name only two.  Technically, we 
aren't using either of these right now, but the same principal applies.

Besides the user having control over components, this completely removes 
any runtime dependency on Log4j (or any other logging framework) unless one 
explicitly configures the app to use the Log4jMonitor 
implementation.  Unlike commons-logging where you are just trading a 
dependency on Log4j specifically for a dual dependency on commons-logging 
plus some logging implementation such as Log4j or JDK1.4 logging, there is 
no dependency whatsoever unless it is desired.

Hope that makes sense.


>Ceki Gülcü
>      For log4j documentation consider "The complete log4j manual"
>      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org

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

View raw message