You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robbie Gemmell (JIRA)" <qp...@incubator.apache.org> on 2009/08/10 20:43:14 UTC
[jira] Closed: (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
[ https://issues.apache.org/jira/browse/QPID-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robbie Gemmell closed QPID-2038.
--------------------------------
Resolution: Won't Fix
After further consideration and discussion, the above-mentioned path of calling a reset ourselves (as recommended by Log4J maintainers to others who have encountered this issue previously) doesnt seem advisable. Doing so will also reset the Levels of any non-qpid Loggers that are active, such as those for Mina and Commons Configuration. It would take considerable effort to detect and correct that situation ourselves and would probably be error-prone, so as this is somewhat of a corner-case and is easily detectable visually using the LoggingManagement -> RuntimeOptions tab of the management console it would be more sensible to simply document the behaviour.
> 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: M2.1, M3, M4, 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