You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Afsar Pasha Peeran <ap...@dm.gov.ae> on 2004/01/22 12:29:27 UTC

Dynamically configuring log4j

Hi
 i wanted to know is it possible to use log4j dynamically,
like setting the loglevel and log mode at runtime

i want the log4j to load from the property file and i want to change the properties dynamcially ( at runtime)
how can i do it

Your help is appreciated

please let me know

regards

-----Original Message-----
From: Peter Widmer [mailto:Peter.Widmer@adnovum.ch]
Sent: 22/01/2004 3:25 PM
To: Log4J Developers List
Subject: Re: reload behavior modification / feature request


Hi Rob

Rob Butler wrote:
> Hello all,
> 
> In "The complete manual - log4j" (Printed book) pages 80 - 82 go into great detail of how log4j handles reloading/reconfiguration.  Specifically it documents how reloading a config file does not have the initially expected behavior of removing all original appenders, and then only setting up the new ones in the new file.  This is ok, since it is well documented in the book..  But most of the time I would suspect that people would prefer the behavior of dropping all original appenders, and then creating all the new ones - so that only the new appenders exist after the config file is reloaded.
> 
> It would be great if this behavior could be implemented as well as the original behavior.  This could be implemented by either an additional parameter to the configurators, or an additional method call before calling the configurators.  It could also be implemented as an additional parameter in the configuration files...  log4j.DumpAllAppenders = true.
> 
> In this way we have the option of completely refreshing the configuration of log4j, without needing to be concerned with what the previous configuration of log4j was.  Can this feature be added to log4j?  I think this would work really well with my previous suggestion of having the log4j JMX write out the log4j config file, and then performing a reload of log4j.
> 

As to the jmx implementation, I'm not sure if overwriting the initial 
log4j configuration file is the adequate approach. Or in other words, I 
would prefer to not make jmx-manipulations persistent. In our opinion, a 
restarted application e.g. should use the originally defined log4j 
configuration file instead of a possibly temp. log4j jmx-defined setup 
used, e.g., before a crash of the application. What do you think?

'Peter

> Later
> Rob
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 
> 


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


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