Home » Modeling » EMF » [CDO] CDOEditor has two command stacks registered ?
| |
Re: [CDO] CDOEditor has two command stacks registered ? [message #428713 is a reply to message #428710] |
Fri, 27 March 2009 11:14 |
Victor Roldan Betancort 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 #428715 is a reply to message #428713] |
Fri, 27 March 2009 12:55 |
Stephane fournier 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 #428749 is a reply to message #428713] |
Sun, 29 March 2009 10:09 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] CDOEditor has two command stacks registered ? [message #428750 is a reply to message #428715] |
Sun, 29 March 2009 10:12 |
|
>> 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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] CDOEditor has two command stacks registered ? [message #428766 is a reply to message #428749] |
Mon, 30 March 2009 07:45 |
Stephane fournier 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 |
Victor Roldan Betancort 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 |
Victor Roldan Betancort 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 |
Victor Roldan Betancort 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 |
Stephane fournier 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 |
|
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...
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] CDOEditor has two command stacks registered ? [message #428819 is a reply to message #428808] |
Tue, 31 March 2009 10:51 |
Victor Roldan Betancort 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...
>>
>>
|
|
|
Goto Forum:
Current Time: Sat May 11 10:39:51 GMT 2024
Powered by FUDForum. Page generated in 0.05422 seconds
|