Eclipse Community Forums: GEF » Problem with some event notification...

Help

Home

Home » Eclipse Projects » GEF » Problem with some event notification...

Show: Today's Messages :: Show Polls :: Message Navigator

Problem with some event notification... [message #176810]

Tue, 12 April 2005 07:43

Rudolf Hornig

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

Report message to a moderator

Re: Problem with some event notification... [message #176835 is a reply to message #176810]

Tue, 12 April 2005 09:48

Pratik Shah

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

Report message to a moderator

Re: Problem with some event notification... [message #177088 is a reply to message #176835]

Tue, 12 April 2005 19:26

Eclipse User

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.

Report message to a moderator

Re: Problem with some event notification... [message #177127 is a reply to message #176810]

Tue, 12 April 2005 20:26

Eclipse User

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

Report message to a moderator

Re: Problem with some event notification... [message #177210 is a reply to message #177127]

Wed, 13 April 2005 03:27

Rudolf Hornig

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

Report message to a moderator

Re: Problem with some event notification... [message #177218 is a reply to message #177088]

Wed, 13 April 2005 03:36

Rudolf Hornig

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...

Report message to a moderator

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:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

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

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter