You are right about the Configurator not resetting the repository. I'm not sure where I got that notion from. Maybe it was too early in the morning to be writing emails!
Sounds like you have covered all the bases. The only thing that might be slightly confusing to a user when using a watchdog is that they could delete the configuration file (which the watchdog would notice, but produce an error about) thinking that it would 'turn off' logging. Of course it just leaves the logging unchanged. I suppose that is down to user education. > -----Original Message----- > From: Mark Womack [mailto:[EMAIL PROTECTED]] > Sent: 10 December 2002 16:58 > To: 'Log4J Developers List' > Subject: RE: cvs commit: jakarta-log4j/src/java/org/apache/log4j > PluginReg istry.java > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
