[CODE] Resetting Loggers during Configuration

[Mark Womack <mw...@bevocal.com>]

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

Re: [CODE] Resetting Loggers during Configuration

[Ceki Gülcü <ce...@qos.ch>]

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:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>

--
Ceki


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>