Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » Problem with some event notification...
Problem with some event notification... [message #176810] Tue, 12 April 2005 07:43 Go to next message
Rudolf Hornig is currently offline Rudolf HornigFriend
Messages: 12
Registered: July 2009
Junior Member
I don't have an account for bugzilla so i'm reporting it here. Would
someone be so kind to put it in... Thanks.

It seems that some fireXXX methods in GEF and Draw2D has some issue with
sending out notification IF the notified object manipulates the listener
list during a notification. For example as a response to an
ancestorRemoved notification it tries to remove itself (or any other
listener added before itself) from the ancestorListener list. This is
caused because AncestorHelper.fireAncestorRemoved is iterating over the
listener list using a for loop instead using an iterator. This causes
that after it removed itself from the list, the next listener on the
list will not be called by the fireAncestorRemoved action (as the whole
array will be shifted down by one). Please check and change the
implementation to use iterators.

Affected classes with similar problems:
Draw2d: AncestorHelper, ButtonGroup, UpdateManager
GEF: PaletteViewer, AbstractEditPartViwer

Thanks, Rudolf
Re: Problem with some event notification... [message #176835 is a reply to message #176810] Tue, 12 April 2005 09:48 Go to previous messageGo to next message
Pratik Shah is currently offline Pratik ShahFriend
Messages: 1077
Registered: July 2009
Senior Member
Wouldn't the iterator have the same problem? You can only invoke the
iterator's remove method to guarantte anything.

What do other frameworks do? I believe SWT loops through using an index as
well. So does PropertyChangeSupport.

"Rudolf Hornig" <rudolf.hornig@freemail.hu> wrote in message
news:d3fuis$ck0$1@news.eclipse.org...
> I don't have an account for bugzilla so i'm reporting it here. Would
> someone be so kind to put it in... Thanks.
>
> It seems that some fireXXX methods in GEF and Draw2D has some issue with
> sending out notification IF the notified object manipulates the listener
> list during a notification. For example as a response to an
> ancestorRemoved notification it tries to remove itself (or any other
> listener added before itself) from the ancestorListener list. This is
> caused because AncestorHelper.fireAncestorRemoved is iterating over the
> listener list using a for loop instead using an iterator. This causes
> that after it removed itself from the list, the next listener on the
> list will not be called by the fireAncestorRemoved action (as the whole
> array will be shifted down by one). Please check and change the
> implementation to use iterators.
>
> Affected classes with similar problems:
> Draw2d: AncestorHelper, ButtonGroup, UpdateManager
> GEF: PaletteViewer, AbstractEditPartViwer
>
> Thanks, Rudolf
Re: Problem with some event notification... [message #177088 is a reply to message #176835] Tue, 12 April 2005 19:26 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: none.us.ibm.com

> Wouldn't the iterator have the same problem? You can only invoke the

Right, you'd get a ConcurrentModificationException.

> iterator's remove method to guarantte anything.
>
> What do other frameworks do? I believe SWT loops through using an index
> as
> well. So does PropertyChangeSupport.

SWT leaves holes (null) in its arrays to prevent the index from getting off.
AWT uses a special binary tree. JFace and others use copy-on-modify.

I like AWT's implementation the best, but someone would have to re-implement
the datastructure in a clean-room style.
Re: Problem with some event notification... [message #177127 is a reply to message #176810] Tue, 12 April 2005 20:26 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: christian.sell.netcologne.de

the iterator would only help if it was used to remove the current
element via iterator.remove().

Rudolf Hornig wrote:
> I don't have an account for bugzilla so i'm reporting it here. Would
> someone be so kind to put it in... Thanks.
>
> It seems that some fireXXX methods in GEF and Draw2D has some issue with
> sending out notification IF the notified object manipulates the listener
> list during a notification. For example as a response to an
> ancestorRemoved notification it tries to remove itself (or any other
> listener added before itself) from the ancestorListener list. This is
> caused because AncestorHelper.fireAncestorRemoved is iterating over the
> listener list using a for loop instead using an iterator. This causes
> that after it removed itself from the list, the next listener on the
> list will not be called by the fireAncestorRemoved action (as the whole
> array will be shifted down by one). Please check and change the
> implementation to use iterators.
>
> Affected classes with similar problems:
> Draw2d: AncestorHelper, ButtonGroup, UpdateManager
> GEF: PaletteViewer, AbstractEditPartViwer
>
> Thanks, Rudolf
Re: Problem with some event notification... [message #177210 is a reply to message #177127] Wed, 13 April 2005 03:27 Go to previous messageGo to next message
Rudolf Hornig is currently offline Rudolf HornigFriend
Messages: 12
Registered: July 2009
Junior Member
Christian Sell wrote:
> the iterator would only help if it was used to remove the current
> element via iterator.remove().
This would be ok. I just wanted to avoid a situation when an event is
not sent to a listener who is actually on the list. But his is highly
implementation dependent, so (as others pointed out very cleverly, any
manipulation of event listener may throw a
ConcurrentModificationException. Which is also bad. So it's all the same
whether using iterator or index, it's the underlying datastructure which
causes the problem.
>
> Rudolf Hornig wrote:
>
>> I don't have an account for bugzilla so i'm reporting it here. Would
>> someone be so kind to put it in... Thanks.
>>
>> It seems that some fireXXX methods in GEF and Draw2D has some issue
>> with sending out notification IF the notified object manipulates the
>> listener list during a notification. For example as a response to an
>> ancestorRemoved notification it tries to remove itself (or any other
>> listener added before itself) from the ancestorListener list. This is
>> caused because AncestorHelper.fireAncestorRemoved is iterating over
>> the listener list using a for loop instead using an iterator. This
>> causes that after it removed itself from the list, the next listener
>> on the list will not be called by the fireAncestorRemoved action (as
>> the whole array will be shifted down by one). Please check and change
>> the implementation to use iterators.
>>
>> Affected classes with similar problems:
>> Draw2d: AncestorHelper, ButtonGroup, UpdateManager
>> GEF: PaletteViewer, AbstractEditPartViwer
>>
>> Thanks, Rudolf
Re: Problem with some event notification... [message #177218 is a reply to message #177088] Wed, 13 April 2005 03:36 Go to previous message
Rudolf Hornig is currently offline Rudolf HornigFriend
Messages: 12
Registered: July 2009
Junior Member
Randy Hudson wrote:
>>Wouldn't the iterator have the same problem? You can only invoke the
>
>
> Right, you'd get a ConcurrentModificationException.
>
>
>>iterator's remove method to guarantte anything.
>>
>>What do other frameworks do? I believe SWT loops through using an index
>>as
>>well. So does PropertyChangeSupport.
>
>
> SWT leaves holes (null) in its arrays to prevent the index from getting off.
> AWT uses a special binary tree. JFace and others use copy-on-modify.
>
> I like AWT's implementation the best, but someone would have to re-implement
> the datastructure in a clean-room style.
>
>
You guys are right. I just checked a little deeper and it seems that
PropertyChangeSupport is using a copyOnModify too (and iterates with
indexes). So the problem is not really how the iteration is done, but
rather the underlying data structure. The cleanest way would be to have
an immutable data structure to store the listener list. I think a simple
copyOnModify would do here...
Previous Topic:Editing the same instance of a model in two editors.
Next Topic:Why GEF uses its own GEFMessages, not the WorkbenchMessage?
Goto Forum:
  


Current Time: Mon Jan 30 19:10:09 GMT 2023

Powered by FUDForum. Page generated in 0.02756 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top