logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <mwom...@bevocal.com>
Subject CODE: Watchdog, FileWatchdog, HTTPWatchdog
Date Tue, 08 Jan 2002 23:43:45 GMT
Sometime back I submitted changes to the existing Watchdog and FileWatchdog
classes.  The main goal was to make it easy to create other Watchdog
subclasses and to build more functionality into the Watchdog class.
Enclosed is a second pass at the changes.  I think this new version is much
better than my previous attempt.  I am submitting them for possible
inclusion into a future version of Log4J, and would appreciate any feedback
anyone might have regarding the design and implementation.  Even if you
think it is all crap, I would like to hear why.

I have enclosed the full java files instead of patches.  If folks feel that
these changes should be included, I will generate universal cvs patch files
against the current cvs versions.


org.apache.log4j.helpers.Watchdog.java - Just about a complete rewrite of
this class.  I felt that so much was changing, it would be better to start
fresh.  It now extends Runnable instead of subclassing Thread.  A Watchdog
can be started, stopped, and re-started.  The static portion of the class
maintains a list of active Watchdog's, and there is a static method,
stopAllWatchdogs(), which can be used to stop all active watchdogs.  This
class is now configuration specific with a method of reconfigure.  Since
that is all watchdogs are currently used for, I thought this was ok, but I
could rework the design to move the configuration related code to a subclass
of ConfigurationWatchdog.  A watchdog still has the check interval (aka
delay) property.  In addition, you can now set the test modification time
(the initial time it tests against, defaults to 0) or the configuration
class (the configurator to use for reconfiguration, defaults to
PropertyConfigurator).  Subclasses of Watchdog must implement two methods:

  getModificationTime() - Returns the modifcation time of the entity being
  getConfigurationStream() - Returns an InputStream that contains the
reconfiguration data.

Also, it should be noted that the Watchdog class makes absolutely no
assumptions about the entity being watched or that the reconfiguration data
even comes from the watched entity.  It can be a file, multiple files, a
url, whatever.  It just requires a modification time to test against and an
InputStream containing the configuration data.  All of this is provided by
the Watchdog subclass.

The upside to the new design, in my opinion, is that you can now create a
Watchdog, set it up to use a specific configurator, and start it.  You never
have to call a configureAndWatch() method on the configurator or have the
author of the configurator class implement that method.  The only
requirement is that the configurator has to support a doConfigure() method
that uses an InputStream.  And you are not limited to the type of Watchdog
used in the configureAndWatch() method, which right now is only
FileWatchdog, it can be any watchdog class that anyone has developed.

org.apache.log4j.helpers.FileWatchdog.java - This is a new version of the
FileWatchdog implemented to conform to the Watchdog design.  It implements
the getModificationTime() and getConfigurationStream() methods.  Nothing new
here; i basically used Ceki's original implementation.

org.apache.log4j.PropertyConfigurator.java - Changed configureAndWatch() to
use the new FileWatchdog class.  Also had to add a new
doConfigure(InputStream, LoggingRespository) method so that it could be used
with the new Watchdog design.  This was trivial.

org.apache.log4j.xml.DOMConfigurator.java - Changed configureAndWatch() to
use the new FileWatchdog class.

org.apache.log4j.helpers.HTTPWatchdog.java - This is a new class implemented
using the Watchdog design.  It can be configured to watch a url, and when
the Last-Modified response header value changes, the url is used as a source
for the new configuration data.  This would allow you to put configuration
information for multiple machines onto a web server.  Any change to the file
on the web server would be picked up on any machine that has set up to use
this watchdog to watch the url.

Again, I would appreciate any feedback anyone has regarding these changes,
design, and implementation.

Thanks for your time,

View raw message