Home » Modeling » GMF (Graphical Modeling Framework) » Shared editing domain -- problems with references to host edit parts in edit policies
| Shared editing domain -- problems with references to host edit parts in edit policies [message #501061] |
Mon, 30 November 2009 20:30  |
 TL
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Hi,
I am developing a GMF based editor, which enables the modification of
our models from three different perspectives (we have 3 different
diagram types). After I enabled/implemented diagram portioning, I
realized we need a shared editing domain (among 3 diagram types of which
one is a super diagram and the other two are sub diagrams on the first
one). I followed the steps pointed out in the tutorial provided at:
http://wiki.eclipse.org/GMF_Tips#Sharing_single_EditingDomai n_instance_across_several_diagrams
However the result is an editor with a shared editing domain that is not
working. The experienced serious problems could not be solved even after
1 week of extensive debugging and research. I will explain the problem
in the following paragraph. The problem is similar to what was
experienced in the threads:
http://www.eclipse.org/forums/index.php?t=tree&th=156162 &S=151307a08d312825aa706df9afc4085e#page_top,
http://dev.eclipse.org/newslists/news.eclipse.modeling.gmf/m sg19715.html,
http://www.eclipse.org/forums/index.php?t=msg&goto=48817 8&S=d3d78f9da991ec694d199d7f5e34bde9,
but these did unfortunately not provide any solution.
I am getting a NullPointerException (NPE) when trying to click on the
diagram and when trying to add (the stack trace for this scenario is
provided at [1]) an element to my sub diagram.
Here is the whole scenario:
I add a node to my super diagram, and then I add a sub diagram to that
node (with calling an action from a context menu that executes the open
diagram behavior). When I try to click on the whitespace of the open sub
diagram then I get a NPE in the getNavigatorSelection() method of the
???DiagramEditor. After I change the getNavigatorSelection() method to
be eProxy resolvable it stops throwing NPE at this point. But this does
not eliminate the problem, just one symptom! After that I try to add a
new node to my sub diagram I get also a NPE with the stack trace shown
in [1]. That is strange, because it is still possible to add node to the
super diagram.
Here is what I found out:
With debugging I found out that after the sub diagram is being created
all the edit policies (including the CreationEditPolicy, which is the
one that form which I get the notational element when creating a node)
are called to set their host element. When all these are set than it
comes to a change (I do not know where and why, but I am guessing
because the sub diagram is added to the super diagram), which cause that
the handleElementChanged() method of the ???DocumentProvider class of
the super diagram is called (however the same method of the sub diagram
is not called). This cause the references of the edit policies of the
super diagram to update their host references, but not the sub diagram
edit polices which still have references to the old hosts, which are now
eProxies, therefore a NPE is thrown.
Here are my questions:
How can I make the CreationEditPolicy (and the other EditPolicies) aware
that the host EditParts have changed (unloaded) and set their host to
the new EditParts (i.e., new objects that describe the same Edit Parts)?
I cannot change the internals of AbstractEditPolicy and
CreationEditPolicy. Would it be possible to call the
handleElementChanged() method of the sub diagram form out of the
handleElementChanged() of the super diagram? How?
Any suggestions are welcome,
Tomaz
------------------------------------------------
[1]
java.lang.NullPointerException
at
org.eclipse.emf.workspace.AbstractEMFOperation.inheritedOpti ons(AbstractEMFOperation.java:240)
at
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:149)
at
org.eclipse.gmf.runtime.diagram.ui.commands.SemanticCreateCo mmand.doExecuteWithResult(SemanticCreateCommand.java:71)
at
org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
at
org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
at
org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
at
org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
at
org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
at
org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
at
org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
at
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
... 37 more
|
|
|
| Re: Shared editing domain -- problems with references to host edit parts in edit policies [message #501690 is a reply to message #501061] |
Thu, 03 December 2009 13:51  |
TL
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Hi,
by now I am almost certain that I can fix this issue by enforcing the
execution of the handleElementChanged() of each opened editor. Which
method on a ???DiagramEditor would I have to call to achieve that the
handleElementChanged() method of his DocumentProvider will be executed?
Thanks,
Tomaz
T L pravi:
> Hi,
>
> I am developing a GMF based editor, which enables the modification of
> our models from three different perspectives (we have 3 different
> diagram types). After I enabled/implemented diagram portioning, I
> realized we need a shared editing domain (among 3 diagram types of which
> one is a super diagram and the other two are sub diagrams on the first
> one). I followed the steps pointed out in the tutorial provided at:
> http://wiki.eclipse.org/GMF_Tips#Sharing_single_EditingDomai n_instance_across_several_diagrams
> However the result is an editor with a shared editing domain that is not
> working. The experienced serious problems could not be solved even after
> 1 week of extensive debugging and research. I will explain the problem
> in the following paragraph. The problem is similar to what was
> experienced in the threads:
> http://www.eclipse.org/forums/index.php?t=tree&th=156162 &S=151307a08d312825aa706df9afc4085e#page_top,
> http://dev.eclipse.org/newslists/news.eclipse.modeling.gmf/m sg19715.html,
> http://www.eclipse.org/forums/index.php?t=msg&goto=48817 8&S=d3d78f9da991ec694d199d7f5e34bde9,
> but these did unfortunately not provide any solution.
>
> I am getting a NullPointerException (NPE) when trying to click on the
> diagram and when trying to add (the stack trace for this scenario is
> provided at [1]) an element to my sub diagram.
>
> Here is the whole scenario:
> I add a node to my super diagram, and then I add a sub diagram to that
> node (with calling an action from a context menu that executes the open
> diagram behavior). When I try to click on the whitespace of the open sub
> diagram then I get a NPE in the getNavigatorSelection() method of the
> ???DiagramEditor. After I change the getNavigatorSelection() method to
> be eProxy resolvable it stops throwing NPE at this point. But this does
> not eliminate the problem, just one symptom! After that I try to add a
> new node to my sub diagram I get also a NPE with the stack trace shown
> in [1]. That is strange, because it is still possible to add node to the
> super diagram.
>
> Here is what I found out:
> With debugging I found out that after the sub diagram is being created
> all the edit policies (including the CreationEditPolicy, which is the
> one that form which I get the notational element when creating a node)
> are called to set their host element. When all these are set than it
> comes to a change (I do not know where and why, but I am guessing
> because the sub diagram is added to the super diagram), which cause that
> the handleElementChanged() method of the ???DocumentProvider class of
> the super diagram is called (however the same method of the sub diagram
> is not called). This cause the references of the edit policies of the
> super diagram to update their host references, but not the sub diagram
> edit polices which still have references to the old hosts, which are now
> eProxies, therefore a NPE is thrown.
>
> Here are my questions:
> How can I make the CreationEditPolicy (and the other EditPolicies) aware
> that the host EditParts have changed (unloaded) and set their host to
> the new EditParts (i.e., new objects that describe the same Edit Parts)?
> I cannot change the internals of AbstractEditPolicy and
> CreationEditPolicy. Would it be possible to call the
> handleElementChanged() method of the sub diagram form out of the
> handleElementChanged() of the super diagram? How?
>
> Any suggestions are welcome,
> Tomaz
> ------------------------------------------------
>
> [1]
>
> java.lang.NullPointerException
> at
> org.eclipse.emf.workspace.AbstractEMFOperation.inheritedOpti ons(AbstractEMFOperation.java:240)
>
> at
> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:149)
>
> at
> org.eclipse.gmf.runtime.diagram.ui.commands.SemanticCreateCo mmand.doExecuteWithResult(SemanticCreateCommand.java:71)
>
> at
> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>
> at
> org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
>
> at
> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>
> at
> org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
>
> at
> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>
> at
> org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
>
> at
> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>
> at
> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>
> ... 37 more
|
|
|
| Re: Shared editing domain -- problems with references to host edit parts in edit policies [message #501736 is a reply to message #501690] |
Thu, 03 December 2009 15:34 |
Ali Koudri
Messages: 118
Registered: July 2009 |
Senior Member |
|
|
Hi,
I don't know if it could help but I had to face quite the same problem
(NPE) in a different situation. I mean I wanted to share a single
editing domain across several GMF editors. This is the way I changed GMF
generated code to solve my problem:
1. I register my shared editing domain using the
"org.eclipse.emf.transaction.editingDomain" extension point.
2. I search into the generated code all instanciations of Transactional
Editing Domain" and I replace it by a reference to my registered editing
domain (don't forget "Generated NOT"):
editingDomain =
TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "my
editing domain id");
3. I search into the generated code all "dispose()" methods and I
prevent the unloading of my editing domain, responsible to me of the NPE:
/**
* @generated NOT
*/
public void dispose() {
myWorkspaceSynchronizer.dispose();
myWorkspaceSynchronizer = null;
myViewerRefreshRunnable = null;
for (Iterator it = myEditingDomain.getResourceSet().getResources()
.iterator(); it.hasNext();) {
Resource resource = (Resource) it.next();
resource.unload();
}
//DO NOT UNLOAD EDITING DOMAIN
//((TransactionalEditingDomain) myEditingDomain).dispose();
//myEditingDomain = null;
}
Please let me know if it can help you or if you need more information.
Best regards.
T L a écrit :
> Hi,
>
> by now I am almost certain that I can fix this issue by enforcing the
> execution of the handleElementChanged() of each opened editor. Which
> method on a ???DiagramEditor would I have to call to achieve that the
> handleElementChanged() method of his DocumentProvider will be executed?
>
> Thanks,
> Tomaz
>
>
> T L pravi:
>> Hi,
>>
>> I am developing a GMF based editor, which enables the modification of
>> our models from three different perspectives (we have 3 different
>> diagram types). After I enabled/implemented diagram portioning, I
>> realized we need a shared editing domain (among 3 diagram types of
>> which one is a super diagram and the other two are sub diagrams on the
>> first one). I followed the steps pointed out in the tutorial provided
>> at:
>> http://wiki.eclipse.org/GMF_Tips#Sharing_single_EditingDomai n_instance_across_several_diagrams
>> However the result is an editor with a shared editing domain that is
>> not working. The experienced serious problems could not be solved even
>> after 1 week of extensive debugging and research. I will explain the
>> problem in the following paragraph. The problem is similar to what was
>> experienced in the threads:
>> http://www.eclipse.org/forums/index.php?t=tree&th=156162 &S=151307a08d312825aa706df9afc4085e#page_top,
>> http://dev.eclipse.org/newslists/news.eclipse.modeling.gmf/m sg19715.html,
>> http://www.eclipse.org/forums/index.php?t=msg&goto=48817 8&S=d3d78f9da991ec694d199d7f5e34bde9,
>> but these did unfortunately not provide any solution.
>>
>> I am getting a NullPointerException (NPE) when trying to click on the
>> diagram and when trying to add (the stack trace for this scenario is
>> provided at [1]) an element to my sub diagram.
>>
>> Here is the whole scenario:
>> I add a node to my super diagram, and then I add a sub diagram to that
>> node (with calling an action from a context menu that executes the
>> open diagram behavior). When I try to click on the whitespace of the
>> open sub diagram then I get a NPE in the getNavigatorSelection()
>> method of the ???DiagramEditor. After I change the
>> getNavigatorSelection() method to be eProxy resolvable it stops
>> throwing NPE at this point. But this does not eliminate the problem,
>> just one symptom! After that I try to add a new node to my sub diagram
>> I get also a NPE with the stack trace shown in [1]. That is strange,
>> because it is still possible to add node to the super diagram.
>>
>> Here is what I found out:
>> With debugging I found out that after the sub diagram is being created
>> all the edit policies (including the CreationEditPolicy, which is the
>> one that form which I get the notational element when creating a node)
>> are called to set their host element. When all these are set than it
>> comes to a change (I do not know where and why, but I am guessing
>> because the sub diagram is added to the super diagram), which cause
>> that the handleElementChanged() method of the ???DocumentProvider
>> class of the super diagram is called (however the same method of the
>> sub diagram is not called). This cause the references of the edit
>> policies of the super diagram to update their host references, but not
>> the sub diagram edit polices which still have references to the old
>> hosts, which are now eProxies, therefore a NPE is thrown.
>>
>> Here are my questions:
>> How can I make the CreationEditPolicy (and the other EditPolicies)
>> aware that the host EditParts have changed (unloaded) and set their
>> host to the new EditParts (i.e., new objects that describe the same
>> Edit Parts)?
>> I cannot change the internals of AbstractEditPolicy and
>> CreationEditPolicy. Would it be possible to call the
>> handleElementChanged() method of the sub diagram form out of the
>> handleElementChanged() of the super diagram? How?
>>
>> Any suggestions are welcome,
>> Tomaz
>> ------------------------------------------------
>>
>> [1]
>>
>> java.lang.NullPointerException
>> at
>> org.eclipse.emf.workspace.AbstractEMFOperation.inheritedOpti ons(AbstractEMFOperation.java:240)
>>
>> at
>> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:149)
>>
>> at
>> org.eclipse.gmf.runtime.diagram.ui.commands.SemanticCreateCo mmand.doExecuteWithResult(SemanticCreateCommand.java:71)
>>
>> at
>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>>
>> at
>> org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
>>
>> at
>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>>
>> at
>> org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
>>
>> at
>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>>
>> at
>> org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
>>
>> at
>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>>
>> at
>> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>>
>> ... 37 more
|
|
|
| Re: Shared editing domain -- problems with references to host edit parts in edit policies [message #501786 is a reply to message #501736] |
Thu, 03 December 2009 18:49 |
TL
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Thanks for your suggestion exquisitus.
I tried your approach and it has not solved my problem. Unfortunately I
cannot change the class
org.eclipse.gmf.runtime.emf.type.core.request.CreateElementR equest where
the editing domain is set that causes my NPE. The getEditingDomain()
method tries to get the domain from the container. Here is the method:
----------------------------------
public TransactionalEditingDomain getEditingDomain() {
TransactionalEditingDomain result = super.getEditingDomain();
EObject c = getContainer();
if (result == null && c != null) {
// get the editing domain from the container
result = TransactionUtil.getEditingDomain(c);
}
return result;
}
-----------------------------------
This of course does not succeed because the container is an eProxy since
it he was not set to the new reference. Therefore the editing domain is
set to null. The solution as already mentioned in previous mails would
be to call the handleElementChanged() method of the sub diagram.
A possible solution would be to set the editing domain of the request in
the first object that can be changed (is part of my generated code).
That would be the getSemanticCommand() of the
???BaseItemSemanticEditPolicy class. However to change this and to make
all the changes exquisitus has suggested would be hacking opposed to
just invoking the handleElementChanged() of the sub diagram. This way I
would not have bunch of generated NOT methods in my solution, which
would cause problems at model changes and regeneration.
Unfortunately I have not figured out how to invoke the
handleElementChanged() of the DocumentProveider of my sub diagram. Could
someone please help me?
Best regards,
Tomaz
exquisitus pravi:
> Hi,
>
> I don't know if it could help but I had to face quite the same problem
> (NPE) in a different situation. I mean I wanted to share a single
> editing domain across several GMF editors. This is the way I changed GMF
> generated code to solve my problem:
>
> 1. I register my shared editing domain using the
> "org.eclipse.emf.transaction.editingDomain" extension point.
>
> 2. I search into the generated code all instanciations of Transactional
> Editing Domain" and I replace it by a reference to my registered editing
> domain (don't forget "Generated NOT"):
>
> editingDomain =
> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "my
> editing domain id");
>
> 3. I search into the generated code all "dispose()" methods and I
> prevent the unloading of my editing domain, responsible to me of the NPE:
>
> /**
> * @generated NOT
> */
> public void dispose() {
> myWorkspaceSynchronizer.dispose();
> myWorkspaceSynchronizer = null;
> myViewerRefreshRunnable = null;
> for (Iterator it = myEditingDomain.getResourceSet().getResources()
> .iterator(); it.hasNext();) {
> Resource resource = (Resource) it.next();
> resource.unload();
> }
> //DO NOT UNLOAD EDITING DOMAIN
> //((TransactionalEditingDomain) myEditingDomain).dispose();
> //myEditingDomain = null;
> }
>
> Please let me know if it can help you or if you need more information.
>
> Best regards.
>
>
> T L a écrit :
>> Hi,
>>
>> by now I am almost certain that I can fix this issue by enforcing the
>> execution of the handleElementChanged() of each opened editor. Which
>> method on a ???DiagramEditor would I have to call to achieve that the
>> handleElementChanged() method of his DocumentProvider will be executed?
>>
>> Thanks,
>> Tomaz
>>
>>
>> T L pravi:
>>> Hi,
>>>
>>> I am developing a GMF based editor, which enables the modification of
>>> our models from three different perspectives (we have 3 different
>>> diagram types). After I enabled/implemented diagram portioning, I
>>> realized we need a shared editing domain (among 3 diagram types of
>>> which one is a super diagram and the other two are sub diagrams on
>>> the first one). I followed the steps pointed out in the tutorial
>>> provided at:
>>> http://wiki.eclipse.org/GMF_Tips#Sharing_single_EditingDomai n_instance_across_several_diagrams
>>> However the result is an editor with a shared editing domain that is
>>> not working. The experienced serious problems could not be solved
>>> even after 1 week of extensive debugging and research. I will explain
>>> the problem in the following paragraph. The problem is similar to
>>> what was experienced in the threads:
>>> http://www.eclipse.org/forums/index.php?t=tree&th=156162 &S=151307a08d312825aa706df9afc4085e#page_top,
>>> http://dev.eclipse.org/newslists/news.eclipse.modeling.gmf/m sg19715.html,
>>> http://www.eclipse.org/forums/index.php?t=msg&goto=48817 8&S=d3d78f9da991ec694d199d7f5e34bde9,
>>> but these did unfortunately not provide any solution.
>>>
>>> I am getting a NullPointerException (NPE) when trying to click on the
>>> diagram and when trying to add (the stack trace for this scenario is
>>> provided at [1]) an element to my sub diagram.
>>>
>>> Here is the whole scenario:
>>> I add a node to my super diagram, and then I add a sub diagram to
>>> that node (with calling an action from a context menu that executes
>>> the open diagram behavior). When I try to click on the whitespace of
>>> the open sub diagram then I get a NPE in the getNavigatorSelection()
>>> method of the ???DiagramEditor. After I change the
>>> getNavigatorSelection() method to be eProxy resolvable it stops
>>> throwing NPE at this point. But this does not eliminate the problem,
>>> just one symptom! After that I try to add a new node to my sub
>>> diagram I get also a NPE with the stack trace shown in [1]. That is
>>> strange, because it is still possible to add node to the super diagram.
>>>
>>> Here is what I found out:
>>> With debugging I found out that after the sub diagram is being
>>> created all the edit policies (including the CreationEditPolicy,
>>> which is the one that form which I get the notational element when
>>> creating a node) are called to set their host element. When all these
>>> are set than it comes to a change (I do not know where and why, but I
>>> am guessing because the sub diagram is added to the super diagram),
>>> which cause that the handleElementChanged() method of the
>>> ???DocumentProvider class of the super diagram is called (however the
>>> same method of the sub diagram is not called). This cause the
>>> references of the edit policies of the super diagram to update their
>>> host references, but not the sub diagram edit polices which still
>>> have references to the old hosts, which are now eProxies, therefore a
>>> NPE is thrown.
>>>
>>> Here are my questions:
>>> How can I make the CreationEditPolicy (and the other EditPolicies)
>>> aware that the host EditParts have changed (unloaded) and set their
>>> host to the new EditParts (i.e., new objects that describe the same
>>> Edit Parts)?
>>> I cannot change the internals of AbstractEditPolicy and
>>> CreationEditPolicy. Would it be possible to call the
>>> handleElementChanged() method of the sub diagram form out of the
>>> handleElementChanged() of the super diagram? How?
>>>
>>> Any suggestions are welcome,
>>> Tomaz
>>> ------------------------------------------------
>>>
>>> [1]
>>>
>>> java.lang.NullPointerException
>>> at
>>> org.eclipse.emf.workspace.AbstractEMFOperation.inheritedOpti ons(AbstractEMFOperation.java:240)
>>>
>>> at
>>> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:149)
>>>
>>> at
>>> org.eclipse.gmf.runtime.diagram.ui.commands.SemanticCreateCo mmand.doExecuteWithResult(SemanticCreateCommand.java:71)
>>>
>>> at
>>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>>>
>>> at
>>> org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
>>>
>>> at
>>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>>>
>>> at
>>> org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
>>>
>>> at
>>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>>>
>>> at
>>> org.eclipse.gmf.runtime.common.core.command.CompositeCommand .doExecuteWithResult(CompositeCommand.java:403)
>>>
>>> at
>>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand. execute(AbstractCommand.java:135)
>>>
>>> at
>>> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>>>
>>> ... 37 more
|
|
|
| Re: Shared editing domain -- problems with references to host edit parts in edit policies [message #753490 is a reply to message #501786] |
Thu, 27 October 2011 13:22 |
Nigel Daniels
Messages: 66
Registered: July 2009 |
Member |
|
|
On 03/12/2009 18:49, T L wrote:
> Thanks for your suggestion exquisitus.
>
> I tried your approach and it has not solved my problem. Unfortunately I
> cannot change the class
> org.eclipse.gmf.runtime.emf.type.core.request.CreateElementRequest where
> the editing domain is set that causes my NPE. The getEditingDomain()
> method tries to get the domain from the container. Here is the method:
> ----------------------------------
> public TransactionalEditingDomain getEditingDomain() {
> TransactionalEditingDomain result = super.getEditingDomain();
>
> EObject c = getContainer();
> if (result == null && c != null) {
> // get the editing domain from the container
> result = TransactionUtil.getEditingDomain(c);
> }
> return result;
> }
> -----------------------------------
>
> This of course does not succeed because the container is an eProxy since
> it he was not set to the new reference. Therefore the editing domain is
> set to null. The solution as already mentioned in previous mails would
> be to call the handleElementChanged() method of the sub diagram.
>
> A possible solution would be to set the editing domain of the request in
> the first object that can be changed (is part of my generated code).
> That would be the getSemanticCommand() of the
> ???BaseItemSemanticEditPolicy class. However to change this and to make
> all the changes exquisitus has suggested would be hacking opposed to
> just invoking the handleElementChanged() of the sub diagram. This way I
> would not have bunch of generated NOT methods in my solution, which
> would cause problems at model changes and regeneration.
>
> Unfortunately I have not figured out how to invoke the
> handleElementChanged() of the DocumentProveider of my sub diagram. Could
> someone please help me?
>
> Best regards,
> Tomaz
>
>
> exquisitus pravi:
>> Hi,
>>
>> I don't know if it could help but I had to face quite the same problem
>> (NPE) in a different situation. I mean I wanted to share a single
>> editing domain across several GMF editors. This is the way I changed
>> GMF generated code to solve my problem:
>>
>> 1. I register my shared editing domain using the
>> "org.eclipse.emf.transaction.editingDomain" extension point.
>>
>> 2. I search into the generated code all instanciations of
>> Transactional Editing Domain" and I replace it by a reference to my
>> registered editing domain (don't forget "Generated NOT"):
>>
>> editingDomain =
>> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomain("my
>> editing domain id");
>>
>> 3. I search into the generated code all "dispose()" methods and I
>> prevent the unloading of my editing domain, responsible to me of the NPE:
>>
>> /**
>> * @generated NOT
>> */
>> public void dispose() {
>> myWorkspaceSynchronizer.dispose();
>> myWorkspaceSynchronizer = null;
>> myViewerRefreshRunnable = null;
>> for (Iterator it = myEditingDomain.getResourceSet().getResources()
>> .iterator(); it.hasNext();) {
>> Resource resource = (Resource) it.next();
>> resource.unload();
>> }
>> //DO NOT UNLOAD EDITING DOMAIN
>> //((TransactionalEditingDomain) myEditingDomain).dispose();
>> //myEditingDomain = null;
>> }
>>
>> Please let me know if it can help you or if you need more information.
>>
>> Best regards.
>>
>>
>> T L a écrit :
>>> Hi,
>>>
>>> by now I am almost certain that I can fix this issue by enforcing the
>>> execution of the handleElementChanged() of each opened editor. Which
>>> method on a ???DiagramEditor would I have to call to achieve that the
>>> handleElementChanged() method of his DocumentProvider will be executed?
>>>
>>> Thanks,
>>> Tomaz
>>>
>>>
>>> T L pravi:
>>>> Hi,
>>>>
>>>> I am developing a GMF based editor, which enables the modification
>>>> of our models from three different perspectives (we have 3 different
>>>> diagram types). After I enabled/implemented diagram portioning, I
>>>> realized we need a shared editing domain (among 3 diagram types of
>>>> which one is a super diagram and the other two are sub diagrams on
>>>> the first one). I followed the steps pointed out in the tutorial
>>>> provided at:
>>>> http://wiki.eclipse.org/GMF_Tips#Sharing_single_EditingDomain_instance_across_several_diagrams.
>>>> However the result is an editor with a shared editing domain that is
>>>> not working. The experienced serious problems could not be solved
>>>> even after 1 week of extensive debugging and research. I will
>>>> explain the problem in the following paragraph. The problem is
>>>> similar to what was experienced in the threads:
>>>> http://www.eclipse.org/forums/index.php?t=tree&th=156162&S=151307a08d312825aa706df9afc4085e#page_top,
>>>> http://dev.eclipse.org/newslists/news.eclipse.modeling.gmf/msg19715.html,
>>>> http://www.eclipse.org/forums/index.php?t=msg&goto=488178&S=d3d78f9da991ec694d199d7f5e34bde9,
>>>> but these did unfortunately not provide any solution.
>>>>
>>>> I am getting a NullPointerException (NPE) when trying to click on
>>>> the diagram and when trying to add (the stack trace for this
>>>> scenario is provided at [1]) an element to my sub diagram.
>>>>
>>>> Here is the whole scenario:
>>>> I add a node to my super diagram, and then I add a sub diagram to
>>>> that node (with calling an action from a context menu that executes
>>>> the open diagram behavior). When I try to click on the whitespace of
>>>> the open sub diagram then I get a NPE in the getNavigatorSelection()
>>>> method of the ???DiagramEditor. After I change the
>>>> getNavigatorSelection() method to be eProxy resolvable it stops
>>>> throwing NPE at this point. But this does not eliminate the problem,
>>>> just one symptom! After that I try to add a new node to my sub
>>>> diagram I get also a NPE with the stack trace shown in [1]. That is
>>>> strange, because it is still possible to add node to the super diagram.
>>>>
>>>> Here is what I found out:
>>>> With debugging I found out that after the sub diagram is being
>>>> created all the edit policies (including the CreationEditPolicy,
>>>> which is the one that form which I get the notational element when
>>>> creating a node) are called to set their host element. When all
>>>> these are set than it comes to a change (I do not know where and
>>>> why, but I am guessing because the sub diagram is added to the super
>>>> diagram), which cause that the handleElementChanged() method of the
>>>> ???DocumentProvider class of the super diagram is called (however
>>>> the same method of the sub diagram is not called). This cause the
>>>> references of the edit policies of the super diagram to update their
>>>> host references, but not the sub diagram edit polices which still
>>>> have references to the old hosts, which are now eProxies, therefore
>>>> a NPE is thrown.
>>>>
>>>> Here are my questions:
>>>> How can I make the CreationEditPolicy (and the other EditPolicies)
>>>> aware that the host EditParts have changed (unloaded) and set their
>>>> host to the new EditParts (i.e., new objects that describe the same
>>>> Edit Parts)?
>>>> I cannot change the internals of AbstractEditPolicy and
>>>> CreationEditPolicy. Would it be possible to call the
>>>> handleElementChanged() method of the sub diagram form out of the
>>>> handleElementChanged() of the super diagram? How?
>>>>
>>>> Any suggestions are welcome,
>>>> Tomaz
>>>> ------------------------------------------------
>>>>
>>>> [1]
>>>>
>>>> java.lang.NullPointerException
>>>> at
>>>> org.eclipse.emf.workspace.AbstractEMFOperation.inheritedOptions(AbstractEMFOperation.java:240)
>>>>
>>>> at
>>>> org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:149)
>>>>
>>>> at
>>>> org.eclipse.gmf.runtime.diagram.ui.commands.SemanticCreateCommand.doExecuteWithResult(SemanticCreateCommand.java:71)
>>>>
>>>> at
>>>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand.execute(AbstractCommand.java:135)
>>>>
>>>> at
>>>> org.eclipse.gmf.runtime.common.core.command.CompositeCommand.doExecuteWithResult(CompositeCommand.java:403)
>>>>
>>>> at
>>>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand.execute(AbstractCommand.java:135)
>>>>
>>>> at
>>>> org.eclipse.gmf.runtime.common.core.command.CompositeCommand.doExecuteWithResult(CompositeCommand.java:403)
>>>>
>>>> at
>>>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand.execute(AbstractCommand.java:135)
>>>>
>>>> at
>>>> org.eclipse.gmf.runtime.common.core.command.CompositeCommand.doExecuteWithResult(CompositeCommand.java:403)
>>>>
>>>> at
>>>> org.eclipse.gmf.runtime.common.core.command.AbstractCommand.execute(AbstractCommand.java:135)
>>>>
>>>> at
>>>> org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:511)
>>>>
>>>> ... 37 more
Hi Tomaz,
did you ever get an answer to this, I think I may have the same problem.
My post: http://www.eclipse.org/forums/index.php/m/743256/
Thanks.
|
|
|
Goto Forum:
Current Time: Thu Apr 25 16:09:06 GMT 2024
Powered by FUDForum. Page generated in 0.03094 seconds |
] 
Search
Help
Register
Login
Home
