logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: Category configuration bug?
Date Thu, 14 Mar 2002 08:21:53 GMT

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:log4j-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>


Mime
View raw message