Andrus wrote:
> The event package looks very good. I hope we will find lots of other uses
> for it in the future.
Happy to hear that! thanks!
> 1. Do you have plans to make ObserverManager send distributed notifications?
Sure, but if you want to lead the way don't let me hold you back.. :)
> 2. Since DataContextTransactionEventHandler and DataObjectTransactionEvents
> specifically deal with DataContext events, maybe they should be a part of
> "access" package, making "event" a generic event notification framework?
done, moved them into ..access.event. I guess some more interfaces will
pop up there in the future.
> >- the dependency between DataContext and the DCEventHandler is dubious but
> >looks unavoidable.
>
> 3. How about DataContext.setTransactionEventsEnabled() triggering this?
> What I am suggesting is moving static initialization block from DataContext
> to the handler itself, but making sure that it is invoked every time
> setTransactionEventsEnabled is called in the code. Does it make sense?
yes, perfectly. done.
Besides looking into distributed events I'd like to:
- extend/implement the standard java.util event interfaces, e.g. make
ObserverEvent extend EventObject etc.
- think about thread safety before people start using this 'for real' e.g.
in a container
One more question (more for Dirk): currently the handler collects
new/deleted/modified objects for willCommit() and messages the same set of
objects again for didCommit(). Isn't that somewhat wrong? I would have
expected that all registered objects - whether they have been modified or
not - would get this event so that e.g. they can update themselves. It
would certainly be a lot slower; I'm not sure if it makes sense?
Holger
This archive was generated by hypermail 2.0.0 : Sun Jan 19 2003 - 07:12:51 EST