DO NOT REPLY [Bug 38929] - [configuration] Support event listeners for configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38929. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 --- Additional Comments From [EMAIL PROTECTED] 2006-04-16 17:58 --- I checked in a slightly modified version of my last patch because I need this functionality now for continuing work on the re-design of ConfigurationFactory. This should provide basic support for events that are fired whenever a configuration is modified. More sophisticated event support may be implemented on top of these classes. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38929] - [configuration] Support event listeners for configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38929. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #17985|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-04-02 17:35 --- Created an attachment (id=18016) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18016action=view) Implementation of basic event support for configuration classes This patch implements complete support for raw events that are generated for each update of a configuration object. The problem with the clearProperty() method mentioned in the last comment was solved by providing a clearProperty() implementation in AbstractConfiguration that deals with the event stuff and then delegates to a new clearPropertyDirect() method. This method is implemented empty in AbstractConfiguration. Derived classes now instead of implementing clearProperty() override clearPropertyDirect(). These changes should not introduce binary incompatibilities. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38929] - [configuration] Support event listeners for configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38929. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 --- Additional Comments From [EMAIL PROTECTED] 2006-04-02 17:35 --- Created an attachment (id=18017) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18017action=view) Test classes for event support -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38929] - [configuration] Support event listeners for configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38929. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 --- Additional Comments From [EMAIL PROTECTED] 2006-03-26 19:16 --- Created an attachment (id=17985) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17985action=view) Initial implementation of raw events for configuration updates Start of an implementation for supporting event listeners. New o.a.c.configuration.events package. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38929] - [configuration] Support event listeners for configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38929. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 --- Additional Comments From [EMAIL PROTECTED] 2006-03-26 19:25 --- I attached a patch with an initial implementation for this enhancement request (dealing with the raw events, which can be the base of high-level event listeners). The idea is to have a class EventSource that provides basic functionality for registering and notifying event listeners. AbstractConfiguration extends this class, and all methods that modify the configuration call the inherited fireEvent() method accordingly. However I faced a problem with the clearProperty() method. Being abstract the base class cannot provide event support for this method, so it would have to be implemented in all sub classes - which certainly is no good solution. Does anybody have an idea how to deal with this problem? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38929] - [configuration] Support event listeners for configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38929. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 --- Additional Comments From [EMAIL PROTECTED] 2006-03-16 13:18 --- (In reply to comment #3) And another use case: An easy way of implementing a read-only configuration could be to register a change listener that would throw a ConfigurationRuntimeException for every change. This is a bit unorthodox, but efficient: we would not have to bother with decorators. This is similar to the vetoable change mechanism of the javabeans. We may reuse the same interfaces and listeners, or extend them (PropertyChangeEvent, VetoableChangeListener, etc) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38929] - [configuration] Support event listeners for configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38929. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 --- Additional Comments From [EMAIL PROTECTED] 2006-03-15 20:11 --- Sounds good! My use case was a kind of a view configuration: a configuration that depends on a set of source configurations and provides a logic view of the properties of those, e.g. a union or an override configuration. (The goal is to have a fully hierarchical replacement for CompositeConfiguration.) Whenever one of the source configurations is changed, the view needs to be notified so that it can invalidate itself. And another use case: An easy way of implementing a read-only configuration could be to register a change listener that would throw a ConfigurationRuntimeException for every change. This is a bit unorthodox, but efficient: we would not have to bother with decorators. From the terms of events these are rather simple use cases - all kinds of change events are of interest. Maybe we can have two layers: - A basic layer providing raw events. Listeners of this type are notified for every change of a configuration. - A higher level providing more semantics like the property changed events mentioned earlier. This level could be implemented by specialized listeners receiving raw events and performing some transformation and filtering. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38929] - [configuration] Support event listeners for configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38929. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 --- Additional Comments From [EMAIL PROTECTED] 2006-03-16 07:08 --- Well, the higher level listener can be an implementation of the raw listener :) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38929] - [configuration] Support event listeners for configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38929. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 --- Additional Comments From [EMAIL PROTECTED] 2006-03-13 08:53 --- Nice, I thought about this also for some time. The listener/monitor concept can be applied for other events: - property not found (instead of ignoring or throwing an exception - the registered listener can do this then - and we can get rid of the method in AbstractConfiguration and all this special handling) setProperty-Problem: Maybe we have a bulkChangeStart/bulkChangeEnd event, so that a listener implementation may optimize the configurationChanged events inbetween ? And yes, reload should raise an event. It is up to the listener implementation to do soemthing useful about it. And it could also make usage of the bulk change. - Jörg -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38929] - [configuration] Support event listeners for configurations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38929. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 --- Additional Comments From [EMAIL PROTECTED] 2006-03-13 18:14 --- What are the functional requirements for this feature? A set of real use cases would help us in specifying this properly. Notifications are useful when complex objects are initialised from the configuration and need to be destroyed and rebuilt from scratch whenever a property changes. A JDBC connection pool is a good example. It could be configured with the following set of properties in a config.properties file: database.driver=oracle.jdbc.driver.OracleDriver database.url=jdbc:oracle:thin:@127.0.0.1:1525:JAKARTA database.username=scott database.password=tiger If one of these properties changes, the pool has to be reinitialised. Monitoring all the properties individually is not very practical. It would lead to a code like this: conf.addPropertyListener(database.driver, this); conf.addPropertyListener(database.url, this); conf.addPropertyListener(database.username, this); conf.addPropertyListener(database.password, this); With the risk of receiving 4 notifications when the configuration file changes, leading to 4 consecutive reinitialisations of the pool, this is clearly not desirable. This shows the need to monitor a set of properties. I have 3 types of syntax in mind for this: conf.addPropertyListener(database.*, this); or conf.subset(database).addPropertyListener(*, this); or conf.subset(database).addConfigurationListener(this); (a ConfigurationListener would listen for configuration wide events like reload and clear, a PropertyListener would listen for changes specific to a given property, or a set of properties). This raises the issue of the notifications for subsets or sub nodes, this may be fun to implement :) More use cases would be helpful. It might also be worth looking at the notification mechanisms of JMX and java.util.prefs. The Preferences API has node level notifications. JMX has a concept of error notification similar to Jorg's idea (MonitorNotification.OBSERVED_ATTRIBUTE_ERROR), it also tracks in the event fired the old value and the class of the property changed. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
