Mark,
I sent a similar message a few days ago. I guess you have not seen it. Have you? (See also my in line comment.) Anyway, he it is: ---------------- This is from the log4j book (soon to be published). I hope it helps: Reloading of a configuration file or reconfiguration of log4j from a different configuration file is allowed and is also thread safe. The crucial point to remember is that invoking any of the log4j configurators does not reset the previous configuration however reconfiguration has obviously some effect on the existing configuration. In particular, all appenders of any logger explicitly mentioned in the new configuration will be closed and removed from that logger. Appenders attached to loggers not mentioned in the new configuration file remain untouched. If an appender is attached to multiple loggers, then it is possible for the appender to be closed during the reconfiguration but remain attached to a logger not mentioned in the second configuration file. In this case, log4j will warn you about trying to log to a closed appender. First configuration file <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> <log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/'> <appender name="A1" class="org.apache.log4j.FileAppender"> <param name="File" value="A1.log"> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%r %p [%t] %c - %m%n"/> </layout> </appender> <appender name="A2" class="org.apache.log4j.FileAppender"> <param name="File" value="A2.log"> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%r %p [%t] %c - %m%n"/> </layout> </appender> <logger name="com.foo"> <appender-ref ref="A2" /> </logger> <logger name="com.wombat"> <appender-ref ref="A2" /> </logger> <root> <priority value ="debug" /> <appender-ref ref="A1" /> </root> </log4j:configuration> The first configuration file defines an appender A1 attached to the root logger, a second appender A2 is attached to loggers "com.foo" and "com.wombat". Second configuration file: <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> <log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/'> <appender name="A1" class="org.apache.log4j.FileAppender"> <param name="File" value="A1.log"> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%r %p [%t] %c - %m%n"/> </layout> </appender> <logger name="com.foo"> <level value=WARN"> </logger> <root> <priority value ="debug" /> <appender-ref ref="A1" /> </root> </log4j:configuration> When the second configuration file is read by the DOMConfigurator, since the root logger is mentioned in the second file, all the appenders in the root are closed and then removed. A new appender called A1 is instantiated, configured and attached to root. Logger "com.foo" is mentioned in the second configuration file. Consequently, A2 will be closed and removed from "com.foo". However, it will remain attached to "com.wombat". Trying to log with "com.wombat" logger will cause log4j to emit a warning. At 21:57 13.03.2002 -0800, you wrote: >I am trying to track down some strange behavior that I see occasionally >regarding the configuration of Categories. Maybe others have already >encountered it. > >When our code starts, log4j configuration data is read and applied. Later, >the configuration data changes and our program has a mechanism to detect the >change and apply the new configuration data (ironically it is not using the >Watchdog mechanism that I have talked about before, but a different >mechanism altogether). The code calls the doConfigure() of the >DOMConfigurator to reconfigure log4j with the new configuration data. > >My bug is that even though the new reconfiguration appears to have been >correctly applied (according to the log4j debug log messages), categories >that were previously configured to output, but should now be configured to >no longer output, are still outputing log messages as if the old >configuration is in place. How can this be? Most of the time, the new >configurations use the same appenders, with the same names, but have >different sets of categories. I'm thinking this bug occurs when a category >that was previously defined in the configuration is removed altogether from >the new configuration, so the Category does not get "reset". But I am still >tracking. I assume that the new configuration file (conveniently) fails to mention the categories that (mysteriously) continue to output, correct? >I looked at the code for both DOMConfigurator and PropertyConfigurator, and >I could not find any obvious code (to me at least) where the configuration >was "cleared", reseting the output settings of all the categories, before >applying the new configuration. Did I miss something obvious? Does it >occur someplace else? Is this by design? > >An obvious way to try to fix the bug, would be to call >Hierarchy.resetConfiguration() before calling doConfigure(). But I would >expect doConfigure() to do this already. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
