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
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
