I've googled the many discussions about the impact of using "configureAndWatch()" in a servlet. The Log4J FAQ says it is "unsafe" to use this in a J2EE application because of the nature of how this works. Discussion about this has been going on for a very long time (in internet time).
I'd like to understand exactly why this is unsafe, and what someone might do to rectify this. >From what I can see, if the appserver has started with an app that uses this, it will start a background thread that will run until the appserver shuts down. If a new version of the app is deployed (or even if the current version is redeployed), the "init()" method of the servlet will call "configureAndWatch()" again, which will start another background thread, in addition to the first one, which will be watching the log4j.xml file. Each time the app is redeployed, it will add another background thread, until the appserver is restarted. In addition, if the app with the servlet is stopped without stopping the appserver, the background thread will continue to run and watch the log4j.xml file. If it finds the file has changed, it will reload the Log4J configuration, but I'm not sure what it's loading it into, as I believe the original classloader that created the thread is gone by this point. That makes my brain hurt. I would guess the way to rectify this would be to write your own loop in a thread that watches the log4j.xml file, with a timeout on each iteration, which checks a static flag that could be set in the "destroy()" method. If "configureAndWatch()" in a servlet is really unsafe, I find it hard to believe someone hasn't written a reusable replacement for "configureAndWatch()" that can exit on command. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
