At 06:16 PM 8/28/03 +0200, you wrote:
Two short comments.
1) My name is Ceki not Ciki.
apologies ... mea culpa!!
2) You can use LogManager.resetConfiguration() to reset or clear the existing config before you read the new config file.
I think that is exactly what I was looking for! I thought I had seen something about it somewhere in my travels, but I couldn't remember where. Thanks.
--- regards --- Larry
HTH,
At 08:58 AM 8/28/2003 -0700, Larry Young wrote:Jake,
A quick question about your past use of "configureAndWatch()" ...
I noticed in Ciki's book that when loading a config file, only those parts of the existing configuration which are explicitly mentioned in the new config file are affected. That makes sense if you are interested in configuration "additivity", but if you are simply trying to maintain the configuration of the running system in-sync with the configuration file, then this would be a bad thing. Not only that, but some loggers who share an appender may get effectively disabled if that appender is reconfigured and the logger is not explicitly in the updated config file.
But in looking through the "configureAndWatch()" path of execution, I don't see them attempting to completely cleanout the current configuration and replace it with the new one specified by the config file. In this situation, I would think it was necessary to blow everything away and start again with the new config.
So, how did you deal with this when you were using this feature? Did you have to ensure that loggers were never removed from the config file when it was updated?? Did you make some other mods to ensure consistency?? Any insights or experiences appreciated! Thanks.
--- regards --- Larry
At 06:09 PM 8/27/03 -0500, you wrote:
I used to use the configureAndWatch() method in my webapps, but I advise against it now. The watchdog classes currently have no lifecycle control. LogManager.shutdown() will *not* end the thread that the watchdog uses. If you try to reload your servlet context, the thread will continue to reference the old webapp class loader. Log4j-1.3. should have better options than configureAndWatch(). I would suggest not doing anything to the dtd or DOMConfigurator to provide special support for configureAndWatch(). It will probably be either deprecated or implemented differently later.
That said, if you still want to use configureAndWatch(), you can use the InitContextListener() from log4j-sandbox to provide information to your webapp as to where your configuration file is. There are other options as well, but I'll let you read about those. As for dealing with a non-servlet environment, this is actually less problematic since it probably is the only app running under the JVM, unlike a container environment where lots of apps and lots of class loaders are running. I would just provide configuration option for your standalone app to be able to specify where the log4j.xml file exists. Shouldn't be hard to write. And you'll have to do initialization yourself instead of counting on default initialization.
Jake
-------------------------- Larry Young The Dalmatian Group www.dalmatian.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ceki For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------
Larry Young
The Dalmatian Group
www.dalmatian.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
