Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] CDOEditor has two command stacks registered ?
[CDO] CDOEditor has two command stacks registered ? [message #428710] Fri, 27 March 2009 08:33 Go to next message
Stephane  fournier is currently offline Stephane fournierFriend
Messages: 340
Registered: July 2009
Senior Member
Hi,

I got a SWT exception with the CDOEditor due to the code in the command
stack listenerS. I can't give you the right scenario...

The problem is the getContainer() call raises a SWTException: widget is
disposed....
To handle that, it would be better to check that getContainer is not null
and not disposed.

Another "weird" problem with the command stack listener : I find 2
listeners.
One is created and registered in CDOEditor.createModel() and another one
in CDOEditor.initializeEditingDomainGen() ?

The code is almost the same, the one in initializeEditingDomainGen() fires
an IEditorPart.PROP_DIRTY event in addition.

As Eike already told me, either two command stack listeners is an error or
I just don't understand the rationale :P

Let me know if I should file a bugzilla.

Stephane.
Re: [CDO] CDOEditor has two command stacks registered ? [message #428711 is a reply to message #428710] Fri, 27 March 2009 08:41 Go to previous messageGo to next message
Stephane  fournier is currently offline Stephane fournierFriend
Messages: 340
Registered: July 2009
Senior Member
Some comments in addition:
It's not only 2 command stack listeners but 2 command stacks.
In fact, the editing domain is created twice :
in createModel() (with the resourceSet got from the CDO view) and in
initializeEditingDomainGen()

Hopefully, initializeEditingDomainGen() is never called...

Nevertheless, in createModel(), getContainer().getDisplay().asynch(..)
should be surrounded by :
if ((getContainer() != null) && (!getContainer().isDisposed()) {

}

Stephane.

Stéphane Fournier wrote:

> Hi,

> I got a SWT exception with the CDOEditor due to the code in the command
> stack listenerS. I can't give you the right scenario...

> The problem is the getContainer() call raises a SWTException: widget is
> disposed....
> To handle that, it would be better to check that getContainer is not null
> and not disposed.

> Another "weird" problem with the command stack listener : I find 2
> listeners.
> One is created and registered in CDOEditor.createModel() and another one
> in CDOEditor.initializeEditingDomainGen() ?

> The code is almost the same, the one in initializeEditingDomainGen() fires
> an IEditorPart.PROP_DIRTY event in addition.

> As Eike already told me, either two command stack listeners is an error or
> I just don't understand the rationale :P

> Let me know if I should file a bugzilla.

> Stephane.
Re: [CDO] CDOEditor has two command stacks registered ? [message #428713 is a reply to message #428710] Fri, 27 March 2009 11:14 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Stéphane,
comments below:

>> I got a SWT exception with the CDOEditor due to the code in the
>> command stack listenerS. I can't give you the right scenario...

Could you provide a stack trace?

>> The problem is the getContainer() call raises a SWTException: widget
>> is disposed....
>> To handle that, it would be better to check that getContainer is not
>> null and not disposed.

According to javadoc:

"Composite org.eclipse.ui.part.MultiPageEditorPart.getContainer()
Returns the composite control containing this multi-page editor's pages.
This should be used as the parent when creating controls for the
individual pages. That is, when calling addPage(Control), the passed
control should be a child of this container."

I which case the composite of CDOEditor is disposed, so getContainer()
returns null or a disposed object? If this is the case, something is
disposing the CDOEditor composite, and I suspect that only be
CDOEditor.dispose() method.

>> Another "weird" problem with the command stack listener : I find 2
>> listeners.
>> One is created and registered in CDOEditor.createModel() and another
>> one in CDOEditor.initializeEditingDomainGen() ?

xxxGen() methods are never called. They are left there with the default
generated code, so if we regenerate, we see changes there that can be
dump (manually) in to the non xxxGen variant. I believe its a EMF best
practice or something like that :P So you shouldn't worry about
initializeEditingDomainGen(), it should never be called. If it is, it's
a problem, so let us know.

>> The code is almost the same, the one in initializeEditingDomainGen()
>> fires an IEditorPart.PROP_DIRTY event in addition.
>
>> As Eike already told me, either two command stack listeners is an
>> error or I just don't understand the rationale :P
>
>> Let me know if I should file a bugzilla.

Please do for the SWT exception. Stack trace would be appreciated. I
think the xxxGen() is not a problem.

>
>> Stephane.
>

Cheers!
ViK
Re: [CDO] CDOEditor has two command stacks registered ? [message #428714 is a reply to message #428711] Fri, 27 March 2009 11:19 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
> Hopefully, initializeEditingDomainGen() is never called...
>
> Nevertheless, in createModel(), getContainer().getDisplay().asynch(..)
> should be surrounded by :
> if ((getContainer() != null) && (!getContainer().isDisposed()) {

I would rather determine why the container composite is getting disposed...
Re: [CDO] CDOEditor has two command stacks registered ? [message #428715 is a reply to message #428713] Fri, 27 March 2009 12:55 Go to previous messageGo to next message
Stephane  fournier is currently offline Stephane fournierFriend
Messages: 340
Registered: July 2009
Senior Member
Hi ViK,

Comments below.

Víctor Roldán Betancort wrote:

> Stéphane,
> comments below:

> >> I got a SWT exception with the CDOEditor due to the code in the
> >> command stack listenerS. I can't give you the right scenario...

> Could you provide a stack trace?

It is not a systematic bug. I didn't reproduce it this morning, next time
I will get the stack trace.

> >> The problem is the getContainer() call raises a SWTException: widget
> >> is disposed....
> >> To handle that, it would be better to check that getContainer is not
> >> null and not disposed.

> According to javadoc:

> "Composite org.eclipse.ui.part.MultiPageEditorPart.getContainer()
> Returns the composite control containing this multi-page editor's pages.
> This should be used as the parent when creating controls for the
> individual pages. That is, when calling addPage(Control), the passed
> control should be a child of this container."

> I which case the composite of CDOEditor is disposed, so getContainer()
> returns null or a disposed object? If this is the case, something is
> disposing the CDOEditor composite, and I suspect that only be
> CDOEditor.dispose() method.

I think the problem occurred at editor close time. Perhaps, something
notifies the command stack listener while the container is disposing...
As I told you, I don't have a clear scenario, sorry for that.

> >> Another "weird" problem with the command stack listener : I find 2
> >> listeners.
> >> One is created and registered in CDOEditor.createModel() and another
> >> one in CDOEditor.initializeEditingDomainGen() ?

> xxxGen() methods are never called. They are left there with the default
> generated code, so if we regenerate, we see changes there that can be
> dump (manually) in to the non xxxGen variant. I believe its a EMF best
> practice or something like that :P So you shouldn't worry about
> initializeEditingDomainGen(), it should never be called. If it is, it's
> a problem, so let us know.

I agree with you, but an EMF-based editor contains a big set of inner
classes, methods and so on... "Dead code" increases the difficulty to read
the "real code". Anyway, as you mentioned it, the problem is not there.


> >> The code is almost the same, the one in initializeEditingDomainGen()
> >> fires an IEditorPart.PROP_DIRTY event in addition.
> >
> >> As Eike already told me, either two command stack listeners is an
> >> error or I just don't understand the rationale :P
> >
> >> Let me know if I should file a bugzilla.

> Please do for the SWT exception. Stack trace would be appreciated. I
> think the xxxGen() is not a problem.

My suggestion is just an advice, I agree it's better to understand what
happened.
But with UI code and multi-threading, the scenario can be complexed to
identify, that's why I'd prefer to add some code guards if possible.

> >
> >> Stephane.
> >

> Cheers!
> ViK
Re: [CDO] CDOEditor has two command stacks registered ? [message #428748 is a reply to message #428714] Sun, 29 March 2009 10:05 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Guys,

I agree with Stéphane. Listener calls can be triggered by the network
and result in client side race conditions. Code inside should check UI
availability *plus* ignore respective exceptions.

Cheers
/Eike

----
http://thegordian.blogspot.com



Víctor Roldán Betancort schrieb:
>> Hopefully, initializeEditingDomainGen() is never called...
>>
>> Nevertheless, in createModel(),
>> getContainer().getDisplay().asynch(..) should be surrounded by :
>> if ((getContainer() != null) && (!getContainer().isDisposed()) {
>
> I would rather determine why the container composite is getting
> disposed...


Re: [CDO] CDOEditor has two command stacks registered ? [message #428749 is a reply to message #428713] Sun, 29 March 2009 10:09 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Guys,

Comments below...


Víctor Roldán Betancort schrieb:
> Stéphane,
> comments below:
>
> >> I got a SWT exception with the CDOEditor due to the code in the
> >> command stack listenerS. I can't give you the right scenario...
>
> Could you provide a stack trace?
>
> >> The problem is the getContainer() call raises a SWTException: widget
> >> is disposed....
> >> To handle that, it would be better to check that getContainer is not
> >> null and not disposed.
>
> According to javadoc:
>
> "Composite org.eclipse.ui.part.MultiPageEditorPart.getContainer()
> Returns the composite control containing this multi-page editor's
> pages. This should be used as the parent when creating controls for
> the individual pages. That is, when calling addPage(Control), the
> passed control should be a child of this container."
>
> I which case the composite of CDOEditor is disposed, so getContainer()
> returns null or a disposed object? If this is the case, something is
> disposing the CDOEditor composite, and I suspect that only be
> CDOEditor.dispose() method.
Active closing of the editor (or other gadgets) can coincident with
remote events. Handler code triggered by such events must catch
exceptions related with closed or closing UI elements.

Cheers
/Eike

----
http://thegordian.blogspot.com


Re: [CDO] CDOEditor has two command stacks registered ? [message #428750 is a reply to message #428715] Sun, 29 March 2009 10:12 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
>> xxxGen() methods are never called. They are left there with the
>> default generated code, so if we regenerate, we see changes there
>> that can be dump (manually) in to the non xxxGen variant. I believe
>> its a EMF best practice or something like that :P So you shouldn't
>> worry about initializeEditingDomainGen(), it should never be called.
>> If it is, it's a problem, so let us know.
>
> I agree with you, but an EMF-based editor contains a big set of inner
> classes, methods and so on... "Dead code" increases the difficulty to
> read the "real code". Anyway, as you mentioned it, the problem is not
> there.
Yes, I also wish the editors were never generated. Generating them from
models wrongly suggests that they're model specific! And fundamental
changes to them can lead to dead code after regeneration...

Cheers
/Eike

----
http://thegordian.blogspot.com


Re: [CDO] CDOEditor has two command stacks registered ? [message #428766 is a reply to message #428749] Mon, 30 March 2009 07:45 Go to previous messageGo to next message
Stephane  fournier is currently offline Stephane fournierFriend
Messages: 340
Registered: July 2009
Senior Member
Hi guys,
Should I file a bugzilla ?

Stéphane.

Eike Stepper wrote:

> Guys,

> Comments below...


> Víctor Roldán Betancort schrieb:
>> Stéphane,
>> comments below:
>>
>> >> I got a SWT exception with the CDOEditor due to the code in the
>> >> command stack listenerS. I can't give you the right scenario...
>>
>> Could you provide a stack trace?
>>
>> >> The problem is the getContainer() call raises a SWTException: widget
>> >> is disposed....
>> >> To handle that, it would be better to check that getContainer is not
>> >> null and not disposed.
>>
>> According to javadoc:
>>
>> "Composite org.eclipse.ui.part.MultiPageEditorPart.getContainer()
>> Returns the composite control containing this multi-page editor's
>> pages. This should be used as the parent when creating controls for
>> the individual pages. That is, when calling addPage(Control), the
>> passed control should be a child of this container."
>>
>> I which case the composite of CDOEditor is disposed, so getContainer()
>> returns null or a disposed object? If this is the case, something is
>> disposing the CDOEditor composite, and I suspect that only be
>> CDOEditor.dispose() method.
> Active closing of the editor (or other gadgets) can coincident with
> remote events. Handler code triggered by such events must catch
> exceptions related with closed or closing UI elements.

> Cheers
> /Eike

> ----
> http://thegordian.blogspot.com
Re: [CDO] CDOEditor has two command stacks registered ? [message #428774 is a reply to message #428748] Mon, 30 March 2009 10:25 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Stéphane, Eike,

I'm working on this. However, I feel ignoring these exceptions could be
dangerous. What about logging a warning, at least?

Cheers,
ViK

Eike Stepper escribió:
> Guys,
>
> I agree with Stéphane. Listener calls can be triggered by the network
> and result in client side race conditions. Code inside should check UI
> availability *plus* ignore respective exceptions.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
> Víctor Roldán Betancort schrieb:
>>> Hopefully, initializeEditingDomainGen() is never called...
>>>
>>> Nevertheless, in createModel(),
>>> getContainer().getDisplay().asynch(..) should be surrounded by :
>>> if ((getContainer() != null) && (!getContainer().isDisposed()) {
>>
>> I would rather determine why the container composite is getting
>> disposed...
Re: [CDO] CDOEditor has two command stacks registered ? [message #428775 is a reply to message #428766] Mon, 30 March 2009 10:28 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Stéphane,

please, do. I'm working on this, so I'll provide a patch soon :)

Stéphane Fournier escribió:
> Hi guys,
> Should I file a bugzilla ?
>
> Stéphane.
>
> Eike Stepper wrote:
>
>> Guys,
>
>> Comments below...
>
>
>> Víctor Roldán Betancort schrieb:
>>> Stéphane,
>>> comments below:
>>>
>>> >> I got a SWT exception with the CDOEditor due to the code in the
>>> >> command stack listenerS. I can't give you the right scenario...
>>>
>>> Could you provide a stack trace?
>>>
>>> >> The problem is the getContainer() call raises a SWTException: widget
>>> >> is disposed....
>>> >> To handle that, it would be better to check that getContainer is not
>>> >> null and not disposed.
>>>
>>> According to javadoc:
>>>
>>> "Composite org.eclipse.ui.part.MultiPageEditorPart.getContainer()
>>> Returns the composite control containing this multi-page editor's
>>> pages. This should be used as the parent when creating controls for
>>> the individual pages. That is, when calling addPage(Control), the
>>> passed control should be a child of this container."
>>>
>>> I which case the composite of CDOEditor is disposed, so
>>> getContainer() returns null or a disposed object? If this is the
>>> case, something is disposing the CDOEditor composite, and I suspect
>>> that only be CDOEditor.dispose() method.
>> Active closing of the editor (or other gadgets) can coincident with
>> remote events. Handler code triggered by such events must catch
>> exceptions related with closed or closing UI elements.
>
>> Cheers
>> /Eike
>
>> ----
>> http://thegordian.blogspot.com
>
>
Re: [CDO] CDOEditor has two command stacks registered ? [message #428780 is a reply to message #428775] Mon, 30 March 2009 11:14 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Stéphane,

forget about submitting the bug. I merged everything in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=270395. Otherwise I'll
have to create a patch, wait for review, commit, then create another
patch...

Víctor Roldán Betancort escribió:
> Stéphane,
>
> please, do. I'm working on this, so I'll provide a patch soon :)
>
> Stéphane Fournier escribió:
>> Hi guys,
>> Should I file a bugzilla ?
>>
>> Stéphane.
>>
>> Eike Stepper wrote:
>>
>>> Guys,
>>
>>> Comments below...
>>
>>
>>> Víctor Roldán Betancort schrieb:
>>>> Stéphane,
>>>> comments below:
>>>>
>>>> >> I got a SWT exception with the CDOEditor due to the code in the
>>>> >> command stack listenerS. I can't give you the right scenario...
>>>>
>>>> Could you provide a stack trace?
>>>>
>>>> >> The problem is the getContainer() call raises a SWTException: widget
>>>> >> is disposed....
>>>> >> To handle that, it would be better to check that getContainer is not
>>>> >> null and not disposed.
>>>>
>>>> According to javadoc:
>>>>
>>>> "Composite org.eclipse.ui.part.MultiPageEditorPart.getContainer()
>>>> Returns the composite control containing this multi-page editor's
>>>> pages. This should be used as the parent when creating controls for
>>>> the individual pages. That is, when calling addPage(Control), the
>>>> passed control should be a child of this container."
>>>>
>>>> I which case the composite of CDOEditor is disposed, so
>>>> getContainer() returns null or a disposed object? If this is the
>>>> case, something is disposing the CDOEditor composite, and I suspect
>>>> that only be CDOEditor.dispose() method.
>>> Active closing of the editor (or other gadgets) can coincident with
>>> remote events. Handler code triggered by such events must catch
>>> exceptions related with closed or closing UI elements.
>>
>>> Cheers
>>> /Eike
>>
>>> ----
>>> http://thegordian.blogspot.com
>>
>>
Re: [CDO] CDOEditor has two command stacks registered ? [message #428782 is a reply to message #428774] Mon, 30 March 2009 14:48 Go to previous messageGo to next message
Stephane  fournier is currently offline Stephane fournierFriend
Messages: 340
Registered: July 2009
Senior Member
Hi ViK,

You're right, logging a warning would be useful.

Stéphane.

Víctor Roldán Betancort wrote:

> Stéphane, Eike,

> I'm working on this. However, I feel ignoring these exceptions could be
> dangerous. What about logging a warning, at least?

> Cheers,
> ViK

> Eike Stepper escribió:
>> Guys,
>>
>> I agree with Stéphane. Listener calls can be triggered by the network
>> and result in client side race conditions. Code inside should check UI
>> availability *plus* ignore respective exceptions.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>
>> Víctor Roldán Betancort schrieb:
>>>> Hopefully, initializeEditingDomainGen() is never called...
>>>>
>>>> Nevertheless, in createModel(),
>>>> getContainer().getDisplay().asynch(..) should be surrounded by :
>>>> if ((getContainer() != null) && (!getContainer().isDisposed()) {
>>>
>>> I would rather determine why the container composite is getting
>>> disposed...
Re: [CDO] CDOEditor has two command stacks registered ? [message #428808 is a reply to message #428782] Tue, 31 March 2009 05:04 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Stéphane Fournier schrieb:
> Hi ViK,
>
> You're right, logging a warning would be useful.
Hmm, I tend to suppress warnings caused by race conditions in local
shutdown situations because they just clutter the log.
But we could trace them. Is that ok? Would require adjustment in various
places in the UI and places like IO close()...

Cheers
/Eike

----
http://thegordian.blogspot.com


>
> Stéphane.
>
> Víctor Roldán Betancort wrote:
>
>> Stéphane, Eike,
>
>> I'm working on this. However, I feel ignoring these exceptions could
>> be dangerous. What about logging a warning, at least?
>
>> Cheers,
>> ViK
>
>> Eike Stepper escribió:
>>> Guys,
>>>
>>> I agree with Stéphane. Listener calls can be triggered by the
>>> network and result in client side race conditions. Code inside
>>> should check UI availability *plus* ignore respective exceptions.
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>>
>>>
>>>
>>> Víctor Roldán Betancort schrieb:
>>>>> Hopefully, initializeEditingDomainGen() is never called...
>>>>>
>>>>> Nevertheless, in createModel(),
>>>>> getContainer().getDisplay().asynch(..) should be surrounded by :
>>>>> if ((getContainer() != null) && (!getContainer().isDisposed()) {
>>>>
>>>> I would rather determine why the container composite is getting
>>>> disposed...
>
>


Re: [CDO] CDOEditor has two command stacks registered ? [message #428819 is a reply to message #428808] Tue, 31 March 2009 10:51 Go to previous message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Nah, let's just ignore the error :P

Eike Stepper escribió:
> Stéphane Fournier schrieb:
>> Hi ViK,
>>
>> You're right, logging a warning would be useful.
> Hmm, I tend to suppress warnings caused by race conditions in local
> shutdown situations because they just clutter the log.
> But we could trace them. Is that ok? Would require adjustment in various
> places in the UI and places like IO close()...
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>>
>> Stéphane.
>>
>> Víctor Roldán Betancort wrote:
>>
>>> Stéphane, Eike,
>>
>>> I'm working on this. However, I feel ignoring these exceptions could
>>> be dangerous. What about logging a warning, at least?
>>
>>> Cheers,
>>> ViK
>>
>>> Eike Stepper escribió:
>>>> Guys,
>>>>
>>>> I agree with Stéphane. Listener calls can be triggered by the
>>>> network and result in client side race conditions. Code inside
>>>> should check UI availability *plus* ignore respective exceptions.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>>
>>>>
>>>>
>>>> Víctor Roldán Betancort schrieb:
>>>>>> Hopefully, initializeEditingDomainGen() is never called...
>>>>>>
>>>>>> Nevertheless, in createModel(),
>>>>>> getContainer().getDisplay().asynch(..) should be surrounded by :
>>>>>> if ((getContainer() != null) && (!getContainer().isDisposed()) {
>>>>>
>>>>> I would rather determine why the container composite is getting
>>>>> disposed...
>>
>>
Previous Topic:[CDO] Checking out a model fragment
Next Topic:XSD to Ecore / upper cased to first letter lower cased
Goto Forum:
  


Current Time: Thu Mar 28 17:30:35 GMT 2024

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

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

Back to the top