At 12:03 14.03.2002 -0800, you wrote: >Ceki, > >Thanks for the reply. I must have missed your earlier message. I probably >read it and missed the context and connection. > >And yes, the new configuration does not list a previously configured >category. And that category keeps on happily outputing messages.
That is the "expected" behavior. >Is this behavior considered a feature or a limitation? It sounds like a bug >to me if categories are left in a state where they are referencing appenders >that no longer exist or categories not mentioned in the configuration file >are still outputing messages. It's not a bug, it's a feature. This behavior allows the merging of different config files. > From where I am coming from is a development environment where multiple >developers are accessing a system that is up and running for a very long >time. The trace settings are changed on a daily basis, as needed. >Requiring that I track/be knowledgeable of all the categories and their >settings that have been previously set up by other folks is unmanageable. I >set the configuration settings, I am expecting log4j to honor just those >settings. Having rogue categories still outputing messages when they are >not mentioned in the configuration file is messy, in my opinion. It's the price to pay in order to allow config file merging. One interesting feature would be to allow a reset instruction within the config file.... >So, is it a feature or a limitation? I think I have worked out a solution >that will not lock up the entire hierarchy/repository as the configuration >is read/applied, and will honor the exact configuration settings. I will >work on a patch and post it to the dev list by tomorrow, and you can review. >If you consider this a bug, then maybe it can make it into 1.2. If you >consider it a feature enhancement, then it goes into 1.3. Doesn't calling Category.resetConfiguration do trick? What else do you need? >thanks, >-Mark > >-----Original Message----- >From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] >Sent: Thursday, March 14, 2002 12:22 AM >To: Log4J Users List >Subject: Re: Category configuration bug? > > > >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]> > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
