At 23:25 24.05.2002 +0200, Ceki Gülcü wrote: >At 13:13 24.05.2002 -0700, Mark Womack wrote: >>I am hoping to get started on the watchdog implementation in the next week. >> >>1) How would people prefer I start? By checking in my current >>implementation, or would folks be interested in reviewing it prior to >>checkin? > >I have a small preference to look at the code before CVS commit, >assuming the code is your specification document. It does not really >matter that much. CVS commits can be modified or even undone. > >>2) When I do check in the code, under what package should it be checked in >>under? Do we have guidelines? > >How about o.a.log4j.config?
BTW, the DigesterConfigurator will probably also end up there. >>3) Can someone come up with a more descriptive name than "watchdog"? Some >>that have come to my mind are "ConfigWatcher" or "Reconfigurator". I am >>open to suggestions. > >DOMReconfigurator or PropertiesReconfigurator sounds fine. > >>thanks, >>-Mark Do you have any concepts to add since the last proposal? If I remember correctly we all agreed that it was a good idea to separate "Watchdog" functionality from configuratiors code. An idea that I find appealing (but which runs contrary to the separation principle) is the ability to start/stop configurators from configuration scripts. Here is an example: Deployer fires up application X on a server at 8:00 AM on Monday. The log4j config script contains the following: log4j.reloadOnChange=true log4j.reloadCheckPeriod=30s log4j.rootLogger=.... .... This causes PropertiesConfigurator to delagate checks for changes to a different component, perhaps PropertiesReconfigurator. The deployer makes changes to the log4j config scripts on several occasions until he totally satisfied at which time he changes the config file to: log4j.reloadOnChange=false log4j.reloadCheckPeriod=30s log4j.rootLogger=.... .... This is when it becomes interesting. Once stopped there is not way to restart reconfigrators a.k.a. watchdogs from the config file. The only solution is to have a component which listens to a certain channel (sockets, JMS, ..) for signals ordering the launch (or relaunch) of a watchdog. The JMX framework is geared towards handling such management operations. All we have to do is to "instrument" congifurators. (Instrumenting an object means enhancing it such that it becomes manageable by JMX). As some of you already know, some log4j components are already JMX instrumentalized. More precisely, loggers can be managed with JMX as well as *all* appenders and layouts regardless of their type. It is really cool stuff. I am surprised that no one picked it up from where I left the code 6 months ago despite my previous appeals. Probably because the code comes with no documentation whatsoever... -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
