RE: cvs commit: jakarta-log4j/src/java/org/apache/log4j PluginReg istry.java

[Nicko Cadell <ni...@Neoworks.com>]

>   +  /**
>   +    Internal class used to handle listener events from repositories. */
>   +  private static class RepositoryListener
>   +  implements LoggerRepositoryEventListener {
>   +    /**
>   +      Stops all plugins associated with the repository being reset. */
>   +    public void configurationResetEvent(LoggerRepository repository) {
>   +      PluginRegistry.stopAllPlugins(repository);
>   +    }

This means that all the plugins will be stopped when the logger repository
is reset. If you are using a watchdog on the config file, each time the
config file is modified all the plugins will be stopped and re-read from the
config file. This means 2 things:

1) The user cannot easily add a plugin programmatically as it will be
stopped each time the config file is modified. They can listen out for the
configurationResetEvent themselves and re-add their plugin but that does not
seem quite right.

2) There is a time period where the plugin does not exist. It is stopped and
then recreated. If the plugin's settings have not been modified in the
config file this is not required. If you are using the socket receiver
plugin then the socket will be closed for a short period of time. If a
client tries to deliver messages during this period they will be dropped!

1 could be addressed by differentiating between config file supplied plugins
and programmatic plugins and not removing the programmatic ones when the
repository is reset. Not a particularly wonderful idea.

2 could be done by comparing the plugin's properties against the config file
settings and only notifying the plugin if they have been modified. Or
perhaps a new way of notifying a plugin that it's settings have been changed
without stopping and recreating it, maybe just call activateOptions() again
on the old instance. (that of course is complicated if the plugin's name has
changed).

I have been playing around with these ideas in log4net but I have not yet
found a satisfactory solution.

Nicko

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