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]

Reply via email to