Mark,
Paul
At 08:05 AM 11/28/2004, Mark Womack wrote:
> 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?
It's a separation of concerns' issue. The PluginRegistry is just a bag containing plugins, plus keeps track of listeners.
Also keep in mind that we already have a model for configuring log4j components. It is as follows:
1) Create a new instance of the desired class, call this instance X. 2) Name the instance x. 3) Configure sub-components of X, if any such sub-components exist 4) invoke x.activateOptions
Once point 4 is completed, we have a configured component. Whether the component gets attached somewhere, for example to a logger in the case of an Appender, is not important. x.activateOptions is always called before attaching the component.
If you consider that activateOption methods can throw exceptions (caugt by the Configurator), then it should become clear that calling activateOptions within the PluginRegistry add method is wrong.
One can always call firePluginStarted *after* adding a Plugin to PluginRegistry.
> 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?
As long as log4j components, including Plugins are named entities, then one can keep track of them through their names.
> 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.
If you view the PR as a bag, then the starting and stopping of a Plugin is naturally independent of the PR.
Mark, keep in mind that the current impossibility for us to stop the watchdog thread at LoggingRepository shutdown, constitutes a very serious bug. We MUST be able to cleanly stop the watchdog thread at LoggingRepository shutdown, otherwise application servers like Tomcat cannot cleanly recycle the application. (I cannot over emphasize the importance of this problem.)
To solve it, I wrote the o.a.log4j.scheduler package. Each LoggerRepository comes with a scheduler which is lazily intialized. When the LoggerRepository is shutdown so is its Scheduler (if it has been initialized).
A Watchdog then simply becomes a recurrent Job registered with the Scheduler.
ps. If you can, please post simple text messages, with no HTML.
-Mark
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
