Nicko, > 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:
I'll need to look at the current DOMConfigurator code, but last time I looked the repository was not reset when it is configured using DOMConfigurator. It is considered a "feature" that you can apply different logger settings with each call to configure() and have the previous settings still in affect. I have suggested that a "reset" attribute in the config file could be used to reset before configuring, but I don't remember it being implemented. I could be wrong. Certainly, if one had to implement it by calling the reset call before configuring, what you say is true. > 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. But the same is true of logger/appender settings already. When you reset the configuration, all programmatically added logger/appender settings are lost. And, there would be a period of time where there would be no effective settings. In an implementation I had for the reset feature (I still have it around too), I collected all of the "newly" configured loggers into a vector and after the parsing and configuration phase, the code then "reset" any logger not in that vector. That way no messages were ever lost. Maybe we could do something similar with plugins. > 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! If reset is not called, then no, there will not be a time period where the plugin is not active. See my note for #2 below. > 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. Agreed. I don't really want to differentiate between the two types. > 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). You may have also noted that some care is taken to identify "equal" plugins, and if equal, the currently running one is left in place. So, if I had a SocketReceiver named "x" already running on port 5000 and I reconfigure with an xml file that defines a SocketReceiver named "x" for port 5000, the currently running one will not be disturbed. startPlugin() loses the reference to the new one and returns a reference to the old one. > I have been playing around with these ideas in log4net but I > have not yet > found a satisfactory solution. I had some code in the DOMConfigurator that would collect all of the new plugins into a vector first. Then when parsing of the xml file was complete, it would then start all of the plugins at once. But I opted for the simpler approach of just starting the plugins after parsing them. I do think that some care should be taken with a reset feature. One might want to reset just the logger/appender settings and leave the plugins the same. One might want to reset the plugins and leave the logger/appender settings the same. We could remove the code for the repository reset and add a reset method in PluginRegistry itself. I think that the watchdogs are going to drive some of this. After some review and test cases, they are next. -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
