From: Christopher O. <chr...@fu...> - 2010-05-04 14:51:15
|
On Tue, 04 May 2010 10:50:22 +0200, Florian Thiel <flo...@fu...> wrote: > Hmm, I didn't think of listeners being able to trigger modifications or > I assumed that these listeners would not be allowed that might cause > recursive firing of listeners, but that's probably just my (naïve) > approach on implementing this. That we did get the concurrent modification exceptions and the warnings showed that there was a problem. > Looking at the listener implementation, everything feels fine, AFAIK, > runAsyncs never trigger firing of listener events recursively (You might > want to double-check that, judging by your debugging methods, there have > to be such instances). I guess that the concurrent modification occurs because Smack is calling us. > I stumbled on another thing: > In InvitationWizardUserSelection (rev 2002), there's refreshSarosSupport > with a runAsync block which in turn calls refreshUserList which also > contains a runAsync block. This does not make sense, does it? Why not? refreshSarosSupport is probably in SWT so the refresh needs to be forked off, then you probably forked back into SWT to update individual entries in the UI. Christopher -- Christopher Oezbek | Freie Universität Berlin | Takustr. 9, 14195 Berlin http://www.inf.fu-berlin.de/~oezbek/ | +49 30 838 75242 | Raum 008 |