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 Mon, 07 Jun 2004 23:30:18 GMT
At 03:21 PM 6/7/2004 +0200, you wrote:
>At 08:34 PM 6/6/2004, Jacob Kjome wrote:
>>>>>>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
>>>>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

Whatever the motivations of Paul Hammant (who is also responsible for 
AvalonNoLogging, BTW), I don't think that the Monitor makes logging 
irrelevant.  If we didn't want logging at all, we wouldn't be using the 
Monitor interface in the first place.  What this buys us is a way for the 
user to decide whether they want logging and, if so, what implementation to 
use (ie.  what external libraries do I, the user, want to declare a 
dependency upon).  The Log4jMonitor is there in case they want to use 
Log4j, in which case they can use their standard Log4j config file and view 
logging messages from Prevayler just like they do in their own 
application.  They don't need to know anything special about how a Monitor 
works since it doesn't change the way they think about logging in the first 
place.  Please go into more detail about why a user should have reason to 
"suspect" anything!

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

Yep, the Monitor succeeds at this.

>2) Integrate seamlessly with the user's existing logging environment

Yep, the Monitor succeeds at this.

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

I wonder if we are discussing the same thing?  The Monitor doesn't 
interfere with anything, removes a runtime dependency on any particular 
logging api except via the user's explicit choice to depend on it, and 
free's the library author to set up an internal logging paradigm of his/her 
own choice while, at the same time, leaving the user unaffected.

UGLI is a fine interface, but does create a dependency on an external 
package (however minimal or trivial one might view that) and it fails to 
free the library author from a logging paradigm of his/her own choice. UGLI 
still doesn't solve the Logging API dependency problem.  for instance in 
the classic Log4j usage...

private static final org.apache.ugli.Logger logger = 

What does this buy us?  There is now not only a dependency on the Log4j 
package but also the UGLI package without providing any benefit to the 
user.... unless you pass in the UGLI Logger via IOC, in which case the UGLI 
api becomes useful as a Logging implementation-neutral API.  Are you 
following me here?  Am I following you?


>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