Home » Modeling » EMF » [CDO] CDOEditor has two command stacks registered ?
[CDO] CDOEditor has two command stacks registered ? [message #428710] |
Fri, 27 March 2009 04:33  |
Eclipse User |
|
|
|
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 07:14   |
Eclipse User |
|
|
|
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 #428715 is a reply to message #428713] |
Fri, 27 March 2009 08:55   |
Eclipse User |
|
|
|
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 #428750 is a reply to message #428715] |
Sun, 29 March 2009 06:12   |
Eclipse User |
|
|
|
>> 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 03:45   |
Eclipse User |
|
|
|
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 06:25   |
Eclipse User |
|
|
|
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 06:28   |
Eclipse User |
|
|
|
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 07:14   |
Eclipse User |
|
|
|
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 10:48   |
Eclipse User |
|
|
|
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 01:04   |
Eclipse User |
|
|
|
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 06:51  |
Eclipse User |
|
|
|
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...
>>
>>
|
|
|
Goto Forum:
Current Time: Sun Jul 13 21:21:41 EDT 2025
Powered by FUDForum. Page generated in 0.12777 seconds
|