logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Converting Legacy application to use log4j
Date Tue, 25 Mar 2008 18:48:40 GMT

On Mar 25, 2008, at 10:02 AM, James A. N. Stauffer wrote:

> I think log4j has some support for 3rd party loggers so it can do the
> work of determining the calling class but I don't remember the
> details.  If Common.status updates the GUI I would level all calls to
> it the same.  Then it is up to you to change all calls to Common.debug
> to Logger.debug depending on how much work that would be.
>
> On Tue, Mar 25, 2008 at 8:08 AM, Clinton Weiss
> <clinton.weiss@custdata.com> wrote:
>>
>> I'm seeking some advice here.  I have a legacy application with  
>> it's own
>> built in logging system accessed via Common.status(String) and
>> Common.debug(String).  The status method is used to update the  
>> application
>> GUI's status line so the user has some idea of what is going on, it  
>> also
>> emits the String to System.out.  The debug message just emits the  
>> String to
>> System.out.
>>
>> Now, I'd like to replace this setup with log4j, however, the  
>> pitfall is how
>> do I still let the user know what is going on?  I believe I have a  
>> couple of
>> choices here:
>>
>> 1) Import log4j only in the Common class, and still allow all code  
>> to call
>> the status() and debug().  When status or debug are called, it will  
>> inspect
>> the current thread to see which class to pass to the logger and  
>> create (or
>> use a mapped) logger accordingly.  This would probably be the  
>> easiest, but
>> not the correct way of doing it.

Do you really have a requirement to use named loggers?  It would be  
much simpler and efficient to just use the root logger or fixed logger  
names ("com.example.MyApp.status" and "com.example.MyApp.debug").

log4j can determine the calling class name if you use a little  
trickery.  If you just called Logger.debug(), a "%C" would output the  
name of the class that made the call to Logger.debug which would be  
something like com.example.Common.  You could use Logger.forcedLog  
which takes a fully qualified class name which is used to determine  
the boundary between the application and the logging framework.   
However, that method is declared protected so you have to extend  
Logger.  However, that method can be replicated by two public methods,  
so you could do something like:

package com.example;
public class Common {
private static Logger root = Logger.getRootLogger();

void status(final String msg) {
     if (root.isInfoEnabled()) {
          root.callAppenders(new  
org.apache.log4j.spi.LoggingEvent("com.example.Common", root,  
Level.INFO, msg, null));
    }
   //
   //   update status line
   //
}
}


>>
>> 2) Replace all Common.status(String) and Common.debug(String) calls  
>> with
>> logger.info(String) and logger.debug(String).  However, can I  
>> create a class
>> that will listen for logger.info(String) calls and then can update  
>> the GUI's
>> status accordingly?  This, I presume, would be the correct way of  
>> doing it -
>> if it is at all possible.

It is probably not good to mix UI concerns like the status line and  
logging.  For example, you may want to turn off the log file without  
affecting the frequency of updates of the status line.  Or up the  
number of active logged statements without increasing the number of  
status line updates.


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