Hi Mark,
Thanks for your contribution. Adding a new configuration directive such that a configurator resets the existing configuration is a good idea. Doing all sorts of the tricks in order to optimize the reset operation is not. Don't tune what you don't need to tune. Regards, Ceki At 10:06 19.03.2002 -0800, you wrote: >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 > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
