You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Jason <ja...@yahoo.com> on 2005/09/04 00:08:43 UTC

Configuration Strategy

Hello,

I'm in the process of adding log4j to a project I'm
working on and I have a question about a configuration
strategy.  I'd like to initialize the configuration of
loggers in our system based on a common property file
named mysystemlog4j.properties.  To this end, I've
added something like the following static block to the
class I happen to be working on:

//Begin Code 
static
{
  URL url =      
someclass1.class.getResource("/mysystemlog4j.properties");
  PropertyConfigurator.configure( url );
}
//End Code

This works fine as far as this class is concerned but
ideally I'l like this code to execute only once system
wide but I'm not sure how to accomplish this.  The
system is such that there is no single class which I
can always count on to have been loaded before any
logging calls are made from elsewhere in the
application so there doesn't seem to be any natural
place to stick the static block.  I'm considering
creating a class com.mycompany.utility.LogInit which
contains nothing but the static block and then
requiring each class which contains log statement to
create a new LogInit( ) in it's ctor.  Obviously the
LogInit static block will only be executed once so
this will work but it seems there should be a better
solution.  One last note:  I'd rather stay away from
depending on any properties having been passed to the
vm as various components of the product might
ultimately end up in different scenarios where we
don't control startup of the vm.  Any thoughts would
be greatly appreciated.

-jason


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: Configuration Strategy

Posted by shy guy <sh...@gmail.com>.
If its a web project, you could use a startup servlet

On 9/6/05, James Stauffer <st...@gmail.com> wrote: 
> 
> One way to solve your problem is to use automatic configuration (i.e
> rename to log4j.properties and add to your classpath).

Re: Configuration Strategy

Posted by James Stauffer <st...@gmail.com>.
One way to solve your problem is to use automatic configuration (i.e
rename to log4j.properties and add to your classpath).

On 9/3/05, Jason <ja...@yahoo.com> wrote:
> Hello,
> 
> I'm in the process of adding log4j to a project I'm
> working on and I have a question about a configuration
> strategy.  I'd like to initialize the configuration of
> loggers in our system based on a common property file
> named mysystemlog4j.properties.  To this end, I've
> added something like the following static block to the
> class I happen to be working on:
> 
> //Begin Code
> static
> {
>   URL url =
> someclass1.class.getResource("/mysystemlog4j.properties");
>   PropertyConfigurator.configure( url );
> }
> //End Code
> 
> This works fine as far as this class is concerned but
> ideally I'l like this code to execute only once system
> wide but I'm not sure how to accomplish this.  The
> system is such that there is no single class which I
> can always count on to have been loaded before any
> logging calls are made from elsewhere in the
> application so there doesn't seem to be any natural
> place to stick the static block.  I'm considering
> creating a class com.mycompany.utility.LogInit which
> contains nothing but the static block and then
> requiring each class which contains log statement to
> create a new LogInit( ) in it's ctor.  Obviously the
> LogInit static block will only be executed once so
> this will work but it seems there should be a better
> solution.  One last note:  I'd rather stay away from
> depending on any properties having been passed to the
> vm as various components of the product might
> ultimately end up in different scenarios where we
> don't control startup of the vm.  Any thoughts would
> be greatly appreciated.
> 
> -jason
> 
> 
> 
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
> 
> 


-- 
James Stauffer
Are you good? Take the test at http://www.livingwaters.com/good/

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


RE: Configuration Strategy

Posted by Moran Ben-David <mo...@place-base.com>.
Jason,

I'll share what me and my colleagues have done in our code base and
hopefully that will help.

All our classes get loggers via a Loggers class.  We declare that in our own
namespace (i.e. com.placebase.log.Loggers).  The Loggers class offers the
getLogger() function for example.  In this function, calls something similar
to your code (below) that initializes log4j once from a configuration file
(actually from a Jakarta Commons Configuration, but that's not important).

I'm a big fan of lazy instantiation, and try to whenever possible to offer
services through an encapsulation of the initialization step.  It's worked
well for us, and doesn't really encumber our classes.  That is, by creating
a bridge to the actual Log4J code between our classes (via
com.placebase.log.Loggers) hasn't been a problem.  However, we don't use the
vast amount of nuances in Log4J.

Hope that helps,
Moran

> -----Original Message-----
> From: Jason [mailto:jasonriz@yahoo.com]
> Sent: Saturday, September 03, 2005 6:09 PM
> To: log4j-user@logging.apache.org
> Subject: Configuration Strategy
> 
> Hello,
> 
> I'm in the process of adding log4j to a project I'm
> working on and I have a question about a configuration
> strategy.  I'd like to initialize the configuration of
> loggers in our system based on a common property file
> named mysystemlog4j.properties.  To this end, I've
> added something like the following static block to the
> class I happen to be working on:
> 
> //Begin Code
> static
> {
>   URL url =
> someclass1.class.getResource("/mysystemlog4j.properties");
>   PropertyConfigurator.configure( url );
> }
> //End Code
> 
> This works fine as far as this class is concerned but
> ideally I'l like this code to execute only once system
> wide but I'm not sure how to accomplish this.  The
> system is such that there is no single class which I
> can always count on to have been loaded before any
> logging calls are made from elsewhere in the
> application so there doesn't seem to be any natural
> place to stick the static block.  I'm considering
> creating a class com.mycompany.utility.LogInit which
> contains nothing but the static block and then
> requiring each class which contains log statement to
> create a new LogInit( ) in it's ctor.  Obviously the
> LogInit static block will only be executed once so
> this will work but it seems there should be a better
> solution.  One last note:  I'd rather stay away from
> depending on any properties having been passed to the
> vm as various components of the product might
> ultimately end up in different scenarios where we
> don't control startup of the vm.  Any thoughts would
> be greatly appreciated.
> 
> -jason
> 
> 
> 
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
> 
> 
> ---------------------------------------------------------------------
> 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