Hi Timo, thanks for your comments.
1) You're right. But I feel that differentiating between events should be up to the framework users not the framework itself. For instance: you propose an IntegerChangeEvent, I use such things as NewCommentEvents. These are two completely different layers of abstractions that heavily depend on what you try to do with those events in your application. I only want to add components if another component receives an ajax call and maybe add the new comment to the list of comments first. I'm not sure what you use those IntegerChangeEvents for but I am sure you have very valid reasons for them However, both ways of using events may be cut down to one common thing: the event broadcasting mechanism! I feel that this is enough to be included in the framework together with some common events. (Just the way the events are used in the java beans spec: java.util.EventObject as root for all events and common events like PropertyChangeEvent that are often used)
2) I didn't spend much though on testing yet. But isn't it possible to assume (i.e. test) behavior of the sending end using a specialized receiver? This way, you would just test wheter you received the events you expected and everything should be fine.
I would really appreciate a final solution that is similar to the usage of events by the java beans spec. There you have one "root event" (java.util.EventObject), some commonly used events (e.g. PropertyChangeEvent) and a naming convention used for introspection. On first look I really, really, really didn't like your use of reflection in you EventBroadcaster. I'd also vote for using a much simpler approach as outlined by Martin above. On second look, I might like an approach that is base on java bean spec's naming convention: to handle a FooEvent one would have to implement the FooEventListener interface with a method 'void fooEvent(FooEvent e)'. I'm currently not sure though whether what I'm saying is completely correct, but it's at least close enough
Furthermore, I think that we could take the usage of events another step further (Just some raw ideas here, but maybe worth looking at): Maybe we (and some core devs) could brainstorm on another thing: Who is responsible for firing events? This could not only be the user but also the framework itself. This way, one could implement something like the VetoableChangeListeners where you can constrain (or validate) model values by dropping in another component (an event is fired for every model change). I could even imagine, that an event is fired automatically when one component of a page receives an ajax call.