commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <>
Subject RE: [configuration] request for comments on refactoring
Date Tue, 18 May 2004 20:31:23 GMT
I think that these ideas actually make a lot of sense..   How many times has
a ConfigurationChangedEvent been something you wanted?   I have a stack of
places where I manually nuke my configuration and reload it b/c I can't
listen for events of any type..

Let's keep this thread moving, but let's not lose focus on getting 1.0 out
the door.   1.0 will pretty much be Configuration as it stands.  These
refactorings sound like 2.0, and as soon as 1.0 is out, we should dive it..
Maybe make a branch for the 2.0 stuff for now?

Emmanuel I belive has volunteered to take a stab a release managering the
1.0, which means we should have something soon!


> -----Original Message-----
> From: Brent Verner []
> Sent: Tuesday, May 18, 2004 1:42 PM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration] request for comments on refactoring
> [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
> | 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message