You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Oliver Heger (JIRA)" <ji...@apache.org> on 2007/01/10 21:21:27 UTC
[jira] Resolved: (CONFIGURATION-143) [configuration] Support event
listeners for configurations
[ https://issues.apache.org/jira/browse/CONFIGURATION-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver Heger resolved CONFIGURATION-143.
----------------------------------------
Resolution: Fixed
Fix Version/s: 1.4
Basic event support (i.e. the "raw event layer") was added a while ago. I would like to close this ticket. For enhanced requirements (e.g. filtering of events) further tickets can be opened.
> [configuration] Support event listeners for configurations
> ----------------------------------------------------------
>
> Key: CONFIGURATION-143
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-143
> Project: Commons Configuration
> Issue Type: Improvement
> Affects Versions: 1.2 Final
> Environment: Operating System: other
> Platform: Other
> Reporter: Oliver Heger
> Priority: Minor
> Fix For: 1.4
>
> Attachments: events-tests.diff, events.diff, events.diff
>
>
> I would like to suggest creating a ConfigurationEvent class and a
> ConfigurationEventListener interface for monitoring changes on configurations.
> AbstractConfiguration could act as an event source allowing listeners to
> register itself at an instance. Whenever this instance is modified a
> notification is sent out to all registered listeners.
> The event class could contain
> - a reference to the affected Configuration object
> - an ID about the type of the event (e.g. property added, property removed,
> configuration cleared etc.)
> - the name of the affected property if applicable
> - the value of the affected property if applicable
> The listener interface could be quite simple and contain only a single method:
> void configurationChanged(ConfigurationEvent event);
> While an implementation should not be too complicated some details need to be
> cleared:
> - ATM as AbstractConfiguration is implemented an operation could cause multiple
> events. For instance setProperty() is implemented as calling clearProperty() and
> then addProperty(). Should this be caught and treated as a single event?
> - Should a reload of a file based configuration cause an event? Could this be
> problematic if a called listener tries to access the configuration?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org