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]
