[
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:[email protected]
