What happens to a "loaded resource" when the Ecore editor is closed? [message #1398640] |
Fri, 11 July 2014 11:04 |
Emre T Messages: 119 Registered: April 2013 |
Senior Member |
|
|
Hello, I have a problem which haunts me for a while and I need to know a specific aspect of the Ecore editor.
The scenario is as follows: I have a UI which listens to a specific type of EMF model and if it find an instance of this model in an active Ecore editor, it loads some extra resources into the model instance from the workspace. Initially this setup runs as expected. But when I close the active Ecore editor holding the model resources and open it again, my listener can't find the same resources for the specific model instance. The only workaround O have right now, which isn't of course sufficient, is to reload the runtime Eclipse instance along with the the workspace after closing-opening the Ecore editor.
I have implemented a JUnit test case, where I first load the same type of resource and use some of my methods on it. It works fine. Then I unload (with unload()) the resource, but nothing changes. What I am trying to do is to realize the same scenario in the test method, where I close the Ecore editor and open it again.
So the question is, whether I am on the correct path? What I need to know is what really happens to resources holding the model instances, when the active editors are closed, so that I can recreate the same situation in my unit tests, to see if some methods used by my listener need to be adjusted? Does the resource get unloaded, or its contents are completely removed? Or maybe nothing happens?
Thanks! If my question wasn't clear, I can provide some more specific information.
[Updated on: Fri, 11 July 2014 12:09] Report message to a moderator
|
|
|
|
Re: What happens to a "loaded resource" when the Ecore editor is closed? [message #1398713 is a reply to message #1398640] |
Fri, 11 July 2014 13:16 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Emre,
Comments below.
On 11/07/2014 1:04 PM, Emre T wrote:
> Hello, I have a problem which haunts me for a while and I need to know
> a specific aspect of the Ecore editor.
> The scenario is as follows: I have a UI which listens to a specific
> type of EMF model and if it find an instance of this model in an
> active Ecore editor, it loads some extra resources into the model
> instance from the workspace. Initially this setup runs as expected.
> But when I close the active Ecore editor holding the model resources
> and open it again, my listener can't find the same resources for the
> specific model instance.
No, the editor creates a new resource set and loads the resource new
each time.
> I have implemented a JUnit test case, where I first load the same type
> of resource and use some of my methods on it. It works fine. Then I
> unload (with unload()) the resource, but nothing changes.
Unload will cause your adapters on any EObjects to be removed. The
adapter on the resource or resource set will remain though.
> What I am trying to do is to realize the same scenario in the test
> method, where I close the Ecore editor and open it again.
The editor does not unload the resources in dispose(). It expects that
the whole resource set and everything in it can be garbage collected.
Of course if you attach adapters from the outside, they will keep the
objects from being garbage collected.
> So the question is, whether I am on the correct path?
It depends on your goal.
> What I need to know is what really happens to resources holding the
> model instances, when the active editors are closed,
Nothing.
> so that I can recreate the same situation in my unit tests, to see if
> some methods used by my listener need to be adjusted?
You'd need to listen the workbench for editors being open and closed.
> Does the resource get unloaded, or its contents are completely removed?
> Thanks! If my question wasn't clear, I can provide some more specific
> information.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03424 seconds