Enclosed is a modified version of DOMConfigurator.java which implements resetting of Loggers, during configuration, that are not referenced in the configuration data. This version is just a demonstration. If the technique is approved of, I will submit a more complete set of patches that can control this new behavior via a setting in the configuration file and also implement in PropertyConfigurator as well.
As discussed on the user list last week (and other times before that), current log4j behavior for when a new configuration file is applied at runtime is to configure just Logger's that are referenced by the configuration file. All other loggers are left untouched, possible referencing appenders that have been closed. This behavior allows for applying/merging different configurations over time. While useful, there are times when a developer would rather have the new configuration be the exact configuration, and that loggers not referenced by the configuration would be "reset" so that they are no longer outputing messages to old appenders and level settings. The changes I am submitting implement this behavior. All of my changes to the DOMConfigurator code are marked by the string "###", so you can just search for it to see the proposed changes. Basic changes: - parse() and parseCategory() methods have modifications to keep track of the set of Loggers referenced by the new configuration data. Each logger is placed into a Hashtable (by name) for future reference. - Once the configuration data has been processed, the parse() method calls a new method, resetOtherLoggers() passing it the hash table of loggers that were referenced in the configuration. resetOtherLoggers() gets the complete list of loggers and enumerates through it. If a logger is not found in the hash table, it is then "reset". Why these changes? 1) I think this behavior is useful (but it should be optional so that the current behavior is default). While I see the usefulness of the current behavior, there are times when you want to set the configuration for log4j to exactly match the given configuration data. I know I'll use this functionality, if accepted. 2) I believe that this implementation avoids synchonizing the entire repository, so (unlike the Hierarchy.resetConfiguration() method) it will not be blocking all log messages while the loggers are being reset. Only the logger that is being reset will be blocked for the duration of the reset calls. All other logging messages can continue unhindered. 3) Making this behavior part of the configure() method allows developers to call just one method instead of two (resetConfiguration() and then configure()). If you agree that this is an acceptable solution/implementation and would like to integrate it into log4j, then for the real patch I will: 1) Implement in DOMConfigurator and PropertyConfigurator. 2) Implement it as optional behavior controllable via an attribute/property setting in the configuration data. Just let me know. Comments, suggestions are welcome, of course. thanks, -Mark
DOMConfigurator.java
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
