For the project I'm working on, we've done something similar.  The one 
problem 
that you run into when you do this (or use any sort of abstraction for 
logging) is that
log4j will no longer be able to accurately determine runtime information 
such as 
the calling method/class/line number.  The reason for this is that this 
information is 
determined by generating a Throwable and then locating the relevant 
information in 
the call stack.  By using an abstraction layer, you throw off the 
calculation, so it ends up
always saying that the calling method is your abstracted log method.

If anyone has found a way to get around this, feel free to comment.

-Mike





Veerappan Saravanan <[EMAIL PROTECTED]>
07/17/01 12:46 PM
Please respond to "LOG4J Users Mailing List"

 
        To:     "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]>
        cc: 
        Subject:        RE: Designing Logging class


Reshma,
 
This is Van. The one problem that we are finding with using static utility 
class is that the entire product is cluttered with calls to this static 
logging class. You are essentially bounding logging to this class.
 
i.e, there are going to be calls like 
Logger.debug(...)
Logger.error(...)
 
all over the system.
 
Instead, we are changing the approach, by hiding the implementing class by 
using factory classes. One way to do that is to have a LogFactory (a 
factory singleton object) that returns different logging classes. In this 
case, then the call to log an error will be
 
LogFactory.getLogger().debug(...)
 
In this approach you are hiding the implementation class completely.
 
-Van
 
-----Original Message-----
From: Reshma Badadhe [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 17, 2001 8:18 AM
To: '[EMAIL PROTECTED]'
Subject: Designing Logging class

Hi, 
I am looking into the approach suggested by Van  i.e making logging a 
static utility class. I have a Logger class which is as follows:
public class Logger 
{ 
        //this instance is used for logging to a Trace log 
        static public Category traceCat = Category.getInstance("Trace" +     
Logger.class.getName());
        //this instance is used for logging to an Error log 
        static public Category errCat = Category.getInstance("Error" +    
Logger.class.getName());
        static 
        { 
                PropertyConfigurator.configureAndWatch("xxx.cfg",60000); 
        } 
} 
This class can be then used by other modules that want to log messages. 
But i have some million-dollar questions to ask u "Know-It-Alls" ;-) 
#1) I want the appender corresponding to the traceCat instance to log only 
debug and info messages i.e in the Trace log. 
PropertyConfigurator doesnt support filters. And i tried adding code to do 
so but failed. 
So what options do i have? 
#2) I thought of adding a Constructor to use the single instance approach. 
Will this help in logging messages to same logfile in an appserver 
environment ( message:  "Multiple JVMs writing to one log file"). For the 
same reason, i've used the static initializer to configure the logging 
environment. Does this approach have any flaws?
Thanks in advance. 
resh 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to