I favour the idea, but I want to propose a slightly different approach: factor the new functionality out into two different classes: 1 - the reloadable aspect - methods reload() and reloadConfiguration() 2 - the filewatcher triggering aspect.
Step 1 results in a reloadable module class, but allows for additional different triggering mechanisms, e.g. by filechanges, nodechange events or at scheduled intervals. Step 2 can be implemented as a subclass of the reloadable module class (from step1), provided as a utility. The general idea, off course, is flexibility. If the proposal can be restated along these lines, I'll be in favour of it. Rob van Maris Technical Consultant Quantiq xmedia & communication solutions Koninginneweg 11-13 1217 KP Hilversum T +31 (0)356257211 M +31 (0)651444006 E [EMAIL PROTECTED]
