qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Created: (QPID-2038) Log4J does not fully reset the configuration when LogWatch is used to apply updated config from log4j.xml while the broker is running
Date Mon, 10 Aug 2009 15:36:16 GMT
Log4J does not fully reset the configuration when LogWatch is used to apply updated config
from log4j.xml while the broker is running
-------------------------------------------------------------------------------------------------------------------------------------

                 Key: QPID-2038
                 URL: https://issues.apache.org/jira/browse/QPID-2038
             Project: Qpid
          Issue Type: Bug
          Components: Java Broker
    Affects Versions: M4, M3, M2.1, 0.5
            Reporter: Robbie Gemmell
            Assignee: Robbie Gemmell
             Fix For: 0.6


Log4J does not fully reset the configuration when LogWatch is used to apply updated config
from log4j.xml while the broker is running. 

DOMConfigurator.configureAndWatch() only applies the new configuration as defined in the XML
file, it does not reset the previous configuration. As such, only the Logger elements specified
in the modified XML file are guaranteed to be set to the requested levels. Any Logger that
previously existed and had a non-inherited Level (eg from a different configuration, or modified
using the management consoles Runtime Operations  logging functions to change the Level of
a Logger not explicitly defined in the XML file) will retain its previous Level even if a
new parent is added or its existing parent level is changed by the XML update.

This behaviour is present to allow multiple configuration files to be used and updated independently
of each other, and is considered by-design. Whilst the PropertyConfigurator has a property
that can be set within a Property file to ensure a full reset is undertaken, the DOMConfigurator
does not. It is possible to achieve this effect by subclassing the XMLWatchdog thread created
by DOMConfigurator.configureAndWatch() and have it call BasicConfigurator.resetConfiguration()
before applying the new configuration. Part of this process resets the level of all existing
loggers to null, making them inherit from any defined parent. It also sets the RootLogger
to DEBUG however, which will result in all Loggers being made DEBUG until the new configuration
is applied, and so to ensure the update will be successful the XML should also be strictly
parsed in advance and the update vetod if any errors or warnings occur.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message