PluginRegistry Review

[Mark Womack]

Attempting to get my head wrapped around this stuff before starting on the watchdog design and implementation.   1) You guys beat me to it.  I was going to make the change from a static, separate PluginRegistry to a per-LoggerRepository instance.  Good move.  That really simplified the implementation, of which there was serious need.  Thanks.   2) startPlugin was changed to addPlugin and it appears that the activateOptions() method is no longer called in startPlugin.  Why?  Right after the plugin is added to the registry, we call firePluginStarted(), which isn't true anymore; the registry has no idea when the plugin will be started.  Just wondering if this is an oversight or if there was a reason.  Is there ever a case where you would want to add a plugin to the registry but not start it immediately?   3) All of the isEquivalent checking has been removed.  The reason this was here before was related to the upcoming watchdog stuff.  Let's say you have a receiver configured in your xml configuration.  That xml configuration changes, the watchdog see this, and initiates the reconfiguration.  Now, the same reciever is still configured in the xml file, no differences.  If you shutdown the existing receiver, create and start a new receiver (all with the same settings), there will be a period of time where logging events will not be received and will be lost; the time in which the receiver is not there.  The isEquivalent was a way to get around this.  If it appears that the plugin is equivalent to an existing one, then let the existing one remain, thus having no "down time".  I'd like to do this "is equivalent" check more elegantly; it places a burden on the plugin developer to implement correctly.  Or maybe the above scenario does not warrant this feature?   4) Does it bother anyone that plugins can be started/stopped independently of the PluginRegistry?  I'm not sure how to enforce all plugin actions done through the registry.  Maybe it is not that big of a deal.   -Mark