[2004-05-18 12:35] Emmanuel Bourg said: | Brent Verner wrote: | | >org.apache.commons.configuration.event | > ConfigurationChangedListener - receives notification when a | > Configuration has changed | > ConfigurationChangedEvent - sent by a ConfigurationProvider | > when its Configuration (or storage) has been modified. | > In my config system, I have a FileModificationMonitor | > subsystem (probaby to be renamed to ResourceModificationMonitor | > and contributed to a suitable jakarta project) that checks | > files for modification and sends a FileModifiedEvent to | > a listener.
RE: naming of non-std properties file: Yes. The .properties name implies adherence to the format used by the j.u.Properties class. Maybe .xprop(ertie)s would be best for the custom-parsed properties files. | There is a patch in Bugzilla to add support for reloadable | configurations (see | http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25661) but no work has | been done on notification yet. How far should we go for notifications ? | Should we just tell the configuration has changed, or should we | enumerate the modified keys ? Maybe there is a way to leverage the | [event] component here. Good to see the reloadable configuration is on the horizon. heh. I started started with a PersistentConfiguration class, too :-), but I drifted away as I refactored further... the CURL class (and the delegated Handler and ConfigurationProvider classes) made it look rather redundant in my approach considering that the configuration having a (symbolic) location implied some external storage. I wasn't aware of the sandbox-event bits. I may have found a home (or a replacement) for my FileModificationMonitor :-) I've not found need to know about individual modified keys, but then my whole configuration system has always been file-based (and only modified via the actual file, not the application code). In my view of things, the ConfigurationChangedEvent could be made smart enough to accomodate either behaviour, and allow the Listener(s) to respond as needed. Having said that our event classes might (need to) be too specific to use much of what is in what I'd assume to be the generic code in sandbox-event. One thing I have learned the hard way :-\, is that a transactional reload() method is required to prevent breakage when the modified config file is unparseable (i.e., a busted xml document). Instead of changing any of the active configuration when an attempt is made to reload an unparseable configuration file, I've found it best to fire the ConfigurationChangedEvent with a payload that lets the app react to the failed reload (most often logging a message, but in some cases I've actually had it send an email...) Thanks for your comments. I'll be more than glad to help in getting the reload bits done if you need it in hopes that it will make it easier to merge my config system into commons-config. cheers. brent -- "Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing." -- Duane Allman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]