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 18:34:15 GMT
Hi Ceki,

See comments below...

At 04:59 PM 6/6/2004 +0200, you wrote:
>At 03:19 PM 6/6/2004, Jacob Kjome wrote:
>>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!!!
>Bah, your oversight just tells us that you are human. Besides, without
>it we would not be having this conversation.

heh :-)

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

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

>To make point clearer, assume for just one moment that all logging
>implementations were based on the following interface:
>// The Universal Generic Logging Interface
>package org.apache.ugli;

That requires a package external to Prevayler to, necessarily, be in the 
classpath.  Not a big deal and certainly better than forcing any one 
logging package on a user (and by far better than being forced to deal with 
commons-logging!!!).  This also assumes that every logging package is going 
to implement this interface.  Just a guess, but I doubt JDK1.4 logging is 
going to implement this.  Call me crazy :-)

>public interface Logger {
>   public boolean isTraceEnabled();
>   public void trace(Object msg);
>   public void trace(Object msg, Throwable t);
>   public boolean isDebugEnabled();
>   public void debug(Object msg);
>   public void debug(Object msg, Throwable t);
>   public boolean isInfoEnabled();
>   public void info(Object msg);
>   public void info(Object msg, Throwable t);
>   public boolean isWarnEnabled();
>   public void warn(Object msg);
>   public void warn(Object msg, Throwable t);
>   public boolean isErrorEnabled();
>   public void error(Object msg);
>   public void error(Object msg, Throwable t);
>Now assume that an implementation of the UGLI Logger were injected
>into client code. How is this different from injecting a monitor
>implementation into the client code?

You're right.  It isn't any different, although it seems that a one or two 
of the other developers like the idea of adding explicit methods to the 
Monitor interface such as streamCorruption() rather than generic debug(), 
info(), etc.  As I said before, the Monitor is really meant exclusively for 
Prevayler internally rather than the outside world.  Personally, I'd like 
it to be more generic and, therefore, reusable.  The interface you've 
defined is quite fine with me.  The main point is being able to have 
multiple implementations backed by nothing, System.out, Log4j, or whatever 

>  As I understand it, there is no
>difference, except that it puts more conceptual distance between the
>user and logging.

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

>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