logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: conversion patterns and caller class information
Date Mon, 07 Jun 2004 13:21:30 GMT
At 08:34 PM 6/6/2004, Jacob Kjome wrote:
>>>>>The whole Monitor idea kind of came from this post:
>>>>>http://paulhammant.com/blog//000241.html
>>>>
>>>>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.
>>
>>While looking at picocontainer, I ran into a delightful article by
>>Martin Fowler:
>>
>>   http://www.martinfowler.com/articles/injection.html
>>
>>>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.
>>
>>I still don't get it. While removing the dependency on log4j or c-l,
>>this introduces a dependency on the monitor interface.
>
>The Monitor interface is internal to the framework.  It is not necessarily 
>to be used by client code using the framework, although there is nothing 
>stopping someone from doing so.


If you read Paul Hammant's article as well as
http://wiki.apache.org/avalon/AvalonNoLogging carefully, you should
realize that the Monitor idea is really about the irrelevance of logging
output. The Monitor technique is a way for library authors ignore the
logging issue with the option of enabling it if the end user really
wants it. The monitor's approach does not solve the problem it claims
it solves, it just defers it. Hence, it's appeal to the unsuspecting
masses.

>BTW, the framework I am talking about is Prevayler ( 
>http://prevayler.codehaus.org/ ).

Very interesting.

>Like I said, the above would be just fine, except that the idea that every 
>logging framework out there would implement that interface is unlikely and 
>the fact that the Monitor is meant for internal use (while still being 
>able to use a single Log4j logging configuration chosen by the user just 
>like normal if the Log4jMonitor interface is used).

What a library author needs from the logging API is for it to be

1) non-disruptive
2) Integrate seamlessly with the user's existing logging environment

JDK 1.4 logging is unlikely to switch to UGLI but that does not mean
that one cannot write an UGLI adapter for JDK 1.4 logging. As for the
various Avalon logging APIs, I expect them to *eventually* adopt UGLI,
although one can never be sure.

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


Mime
View raw message