[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [configuration] request for comments on refactoring
From:       Brent Verner <brent () rcfile ! org>
Date:       2004-05-18 11:41:59
Message-ID: 20040518114159.GA36459 () rcfile ! org
[Download RAW message or body]

[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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]