Reposted question from user (quoted below) and my response.
In general, the approach I am using is to have a static field in the application of some type. In many applications, where I am using the getopt classes, I have a hashtable which contains the various settings gleaned from the command-line and configuration files. I also store the
logger as a key in that hashtable. The hashtable is passed to all of the major components of the application.
This works very well for logging information from classes that are specifically a part of the application being developed rather than targetted for later reuse or as part of a reusable library. For building libraries, we are planning on supplying a static "getlogger" method which
will return a reference to a singleton logger. There will also be static methods to configure that logger and also to register and return specific named loggers for those applications where it makes sense to use more than
one logger (e.g., an application server where an "emergency" at an application level is not necessarily an "emergency" at the server level.)
I wanted to hold off on implementing this until I had a better idea how people (including us) intend to use the library. I have seen a number of approaches in various languages and they all have problems. One of my
major goals is to be able to have libraries which use the logging facilities be able to interact cleanly and for it to be possible to fit a library into a number of logging schemes without too much hassle. One consequence of this, is that reusable code should avoid logging at any level above NOTICE, throwing an exception for actual problems. Logging of errors should be done at the point where the exception is caught, because only there is enough context available to determine the severity of the problem.
On Fri, 3 Nov 2000, Thomas Bishop wrote:
> Hi Eric,
>
> I just have a question of your approach to setting up
> logging for an application. I assume that in general
> you use a single logger (and single log file) to store
> log messages for an application. If this so, you would
> need some way of passing the "logger" to the individual
> classes of the application. One way this can be done is
> to pass the logger object pointer to the class constructor.
> Another way might be to have a static method that could be
> called in the classes to get a global logger. I'm thinking
> this approach may be advantageous, particularly in the case
> of static methods/classes where the logger cannot be passed
> via a constructor.
>
> I am just curious how you are approaching this issue.
>
> BTW, I finally pulled downed the updated source code.
>
> THANKS.
>
>
> Thom --
>
>
> --
> Thomas Bishop
> Integral Software Technologies Inc.
> <tbishop@intsofttech.com>
> http://www.intsofttech.com
> --
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One other thing- I missed your statement/question about a single log file. That really depends. For most client applications, that might be the case. Often, for servers, you will want to register multiple log listeners
that filter out some of the messages for special processing. For instance, DEBUG messages are sent to a trace file, regular messages are sent to a log file, security realated messages sent someplace special, and emergency
messages echoed to a console or pager. Ideally, this should be user configurable. I can see a need for some reusable Java Beans for configuring and storing listeners.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Reposted question from user (quoted below) and my response.
In general, the approach I am using is to have a static field in the application of some type. In many applications, where I am using the getopt classes, I have a hashtable which contains the various settings gleaned from the command-line and configuration files. I also store the
logger as a key in that hashtable. The hashtable is passed to all of the major components of the application.
This works very well for logging information from classes that are specifically a part of the application being developed rather than targetted for later reuse or as part of a reusable library. For building libraries, we are planning on supplying a static "getlogger" method which
will return a reference to a singleton logger. There will also be static methods to configure that logger and also to register and return specific named loggers for those applications where it makes sense to use more than
one logger (e.g., an application server where an "emergency" at an application level is not necessarily an "emergency" at the server level.)
I wanted to hold off on implementing this until I had a better idea how people (including us) intend to use the library. I have seen a number of approaches in various languages and they all have problems. One of my
major goals is to be able to have libraries which use the logging facilities be able to interact cleanly and for it to be possible to fit a library into a number of logging schemes without too much hassle. One consequence of this, is that reusable code should avoid logging at any level above NOTICE, throwing an exception for actual problems. Logging of errors should be done at the point where the exception is caught, because only there is enough context available to determine the severity of the problem.
On Fri, 3 Nov 2000, Thomas Bishop wrote:
> Hi Eric,
>
> I just have a question of your approach to setting up
> logging for an application. I assume that in general
> you use a single logger (and single log file) to store
> log messages for an application. If this so, you would
> need some way of passing the "logger" to the individual
> classes of the application. One way this can be done is
> to pass the logger object pointer to the class constructor.
> Another way might be to have a static method that could be
> called in the classes to get a global logger. I'm thinking
> this approach may be advantageous, particularly in the case
> of static methods/classes where the logger cannot be passed
> via a constructor.
>
> I am just curious how you are approaching this issue.
>
> BTW, I finally pulled downed the updated source code.
>
> THANKS.
>
>
> Thom --
>
>
> --
> Thomas Bishop
> Integral Software Technologies Inc.
> <tbishop@intsofttech.com>
> http://www.intsofttech.com
> --
One other thing- I missed your statement/question about a single log file. That really depends. For most client applications, that might be the case. Often, for servers, you will want to register multiple log listeners
that filter out some of the messages for special processing. For instance, DEBUG messages are sent to a trace file, regular messages are sent to a log file, security realated messages sent someplace special, and emergency
messages echoed to a console or pager. Ideally, this should be user configurable. I can see a need for some reusable Java Beans for configuring and storing listeners.