Fwd: RE: New Watchdog

[Ceki Gülcü <ce...@qos.ch>]

For information.

>Delivered-To: cgu@qos.ch
>From: Mark Womack <mw...@bevocal.com>
>To: 'Ceki G�lc�' <ce...@qos.ch>
>Subject: RE: New Watchdog
>Date: Mon, 7 Jan 2002 11:48:50 -0800 
>X-Mailer: Internet Mail Service (5.5.2655.55)
>
>Ceki,
>
>Enclosed is an HTTPWatcher class which watches a URL, and when the
>last-modified header changes, the url as a source for the reconfiguration
>data.  I wrote it last night.
>
>One other point that I did not make very strongly in my last email, is that
>with the new Watchdog class, the developer can specify the type of Watchdog
>they want to use instead of only relying on what is provided by the
>configurator class.  Right now, Property and DOM configurator
>configureAndWatch() methods require a file for the FileWatchdog.  But, now
>we can just as easily support different watchdog types simply by creating
>the watchdog, giving it the configurator class to use, and then starting it.
>I don't know if you really need any configuration methods on the
>configurators at all and would never need to add a method to support a
>specific type of Watchdog.
>
>hope to hear from you,
>-Mark
>
>-----Original Message-----
>From: Mark Womack 
>Sent: Sunday, January 06, 2002 4:08 PM
>To: 'Ceki G�lc�'
>Subject: New Watchdog
>
>
>Ceki,
>
>Way back, I submitted an updated version of the Watchdog class.  The idea
>being that I felt it needed some work in order to support other kinds of
>watchdogs.  That and there was the suggestion that Watchdogs be creatable
>via the configuration file (which in retrospect I'm not sure was a good
>idea).
>
>Anyway, enclosed is another stab at the Watchdog class.  I reworked my
>original idea over the holidays, and I think this version is much better.
>Please review and consider it for inclusion in a future version of Log4J.
>Even if you think it is crap, I would like to hear back from you so I learn
>from it.  I also included an updated DOMConfigurator.java that uses the
>updated FileWatchdog class.
>
>- The Watchdog class is now more configuration oriented, having a
>reconfigure() method.  Since watchdogs are currently only used for
>reconfiguration, I thought this was ok, but I could rework the class to move
>the configuration specific code into a ConfigurationWatchdog subclass.
>- Watchdogs can be very standalone.  Just give them a configurator class,
>and they can handle the rest.  The only requirement is that the configurator
>has to support a version of the doConfigure() method that supports an
>InputStream.  If this method was moved into the Configurator interface, then
>I would not need to use reflection to find the method; I could assume it was
>there.
>- Watchdogs can be started, stopped, re-started.  They implement the
>Runnable interface instead of extending Thread directly.  And the Watchdog
>class maintains a static list of active Watchdogs.  This makes it fairly
>easy to stop all of the active watchdogs from one location.
>- The base Watchdog class makes absolutely no assumptions of what entity is
>being watched (file, etc) and no assumptions that the configuration settings
>are directly connected to the watched entity (ie. you could write a watchdog
>that watches file A but then grabs the configuration information from a file
>B).  It only needs the configuration settings to be provided as an
>InputStream.
>
>My goal is still to write an HTTPWatchdog class to watch a given url and
>reconfigure is the Last-Modified field in the response header is greater
>than the one the watchdog has.  I am going to work on that tonight and this
>next week.
>
>Again, I would appreciate your comments.
>
>Thanks for your time,
>-Mark   
>

--
Ceki G�lc� - http://qos.ch