|
|
| Re: How to copy EObjects from one Resource to another [message #505814 is a reply to message #505725] |
Tue, 05 January 2010 08:59   |
 Daniel Rippel
Messages: 29
Registered: July 2009 |
Junior Member |
|
|
Hi Ed,
thank you for your suggestions, but I still have the same problem...
I removed all calls of "copy" and instead move the constructed model
directly into the resource. Unfortunately it still remains the same problem:
The template file constains all entries (all containment)
<MODEL xmi:id="_PU9mkeMxEd6pZ6tfMeq-ww">
<SUBDIAGRAM1 xmi:type="SUBDIAGRAM_TYPE"
xmi:id="_QGcG0OMxEd6pZ6tfMeq-ww" name="Structure Diagram">
<packagedElement xmi:type="uml:Class"
xmi:id="_QksJEOMxEd6pZ6tfMeq-ww" name="Class1"/>
<packagedElement xmi:type="uml:Class"
xmi:id="_SfUpwOMxEd6pZ6tfMeq-ww" name="Class2">
<generalization xmi:type="uml:Generalization"
xmi:id="_WvHrAOMxEd6pZ6tfMeq-ww" general="_QksJEOMxEd6pZ6tfMeq-ww"/>
</packagedElement>
....
</SUBDIAGRAM1>
<SUBDIAGRAM2 xmi:type="SUBDIAGRAM_TYPE2"
xmi:id="_nC8e0OMxEd6pZ6tfMeq-ww" name="Knowledge Diagram">
<packagedElement xmi:type="uml:Class"
xmi:id="_rJp1gOMxEd6pZ6tfMeq-ww" name="Class3">
<ownedAttribute xmi:type="uml:Property"
xmi:id="_sd_yQOMxEd6pZ6tfMeq-ww" name="Property1" aggregation="composite"/>
and so on...
After constructuing the new Diagram and saving the resource I end up with:
<MODEL xmi:id="_AaUgEfnWEd6ukN-HoOMqxQ">
<SUBDIAGRAM1 xmi:type="SUBDIAGRAM_TYPE"
href="file:/PATH#_QGcG0OMxEd6pZ6tfMeq-ww"/>
<SUBDIAGRAM2 xmi:type="SUBDIAGRAM_TYPE2"
href="file:/PATH#_nC8e0OMxEd6pZ6tfMeq-ww"/>
....
I want the same (complete) information which is stored in the template
to be in the constructed file too. (And not just href links)
For subdiagrams which are constructed programatically this all works
fine (creating the diagram via a command and the factory classes).
I use the following code to load the templates:
URI uri = URI.createFileURI(fPath);
Resource resource = resourceSet.createResource(uri);
resource.load(Collections.EMPTY_MAP);
EList<EObject> contents = resource.getContents();
Model mdl = null;
for (EObject eObject : contents) {
if (eObject instanceof Model) {
mdl = (Model) eObject;
break;
}
}
and then select present subdiagrams by using (getXXXX() != null)
querries to determine if a sub diagram is contained in this template.
After selecting the desired sub diagrams I create an empty model and use
setXXXXX(SUBDIAGRAM) to include the selected ones. This construct is
then passed to the wizards createDiagram(URI diagramURI,
IProgressMonitor progressMonitor) method which is altered to use the
construct instead of creating a new empty model.
As you can see from the XML above all information should be stored in
the file as they all are containment references.
Ed Merks schrieb:
> Daniel,
>
> Comments below.
>
> Daniel Rippel wrote:
>> Hi all,
>>
>> I have a problem concering the storage (files) of eObjects.
>>
>> SETTING:
>> I have a Model which is composed of different sub-diagrams. I'm
>> actually trying to implement a "new model wizard" which allows to
>> create a model from several predefined models by selecting and
>> combining sub-diagrams.
>>
>> Actually I
>> 1) Scan a specified directory for exsiting model files (templates) and
>> load them.
>> (works fine)
>> 2) The wizard displays all sub-diagrams and the user can select the
>> desired combination
>> (works fine)
>> 3) I use ECoreUtil.copy(SUBDIAGRAM) to create copies of the
>> subdiagrams and insert them into a newly created model object (created
>> using the eFactory.INSTANCE of the model).
>> (Here is where the problems occur)
> I suspect if you're calling copy multiple times you should really be
> calling copyAll just once...
>> 4) I create a resource and use default wizard code to save the model
>> in its own file.
>>
>> PROBLEMS:
>> The problem I encounter is that the sub-diagrams are only stored as
>> proxies with the "template file" as eStorage().
> You're saying there are unresolved proxies when you load the new result,
> or when you're loading the thing to be copied?
>> Thus all modifications to the diagrams affect the template (The models
>> relations to the subdiagrams are set to containment). Moreover, in
>> some cases the CannonicalEditPolicy fails to update the newly created
>> file on opening it. The app freezes and crashes with a "Java Heap
>> Space Overflow" Exception. (The application is set to 1gb Memory and
>> it takes close to a minute until the error is thrown)
>>
>> I use ECoreUtil to copy the eObjects (sub-diagrams), but they still
>> refer to the template file and are only stored as references (href) in
>> the created model file.
>> (Modelfile entry:
>> <SUBDIAGRAM xmi:type="DIAGRAM_TYPE"
>> href="file:/PATH_TO_THE_TEMPLATEFILE#_QGcG0OMxEd6pZ6tfMeq-ww "/>
>> )
> Only containment references are copied recursively. Non-containment
> references will refer to a copy only if the referenced object has also
> been copied at the same time.
>>
>>
>> MY QUESTION:
>> Is there any easy way to create a real copy of an eObject (in a way
>> that it will be contained in the new file) or is it possible to
>> somehow clear the link to the template file?
> Do you want this reference to end up null in the copy even though it's
> non-null in the original? You'd have to do that manually... Or is the
> problem that the template file should also be copied?
>> I already tried to "resolveAll(eObject)" but this makes no difference
>> :) In my understanding this only surpresses the load on demand
>> behavior of distributed models.
> Yes, it forces early resolves.
>>
>>
>> Sorry for the long text and thank you for your answers and hints in
>> advance!
> One question I would ask is why even make copies? Why not just move the
> original objects. Moving them out of their containing resource will
> have no externally visible effect on that resource unless you save it in
> that modified state.
>>
>> With Regards,
>> Daniel
|
|
|
| Re: How to copy EObjects from one Resource to another [message #505861 is a reply to message #505814] |
Tue, 05 January 2010 11:39 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Daniel,
Comments below.
Daniel Rippel wrote:
> Hi Ed,
>
> thank you for your suggestions, but I still have the same problem...
> I removed all calls of "copy" and instead move the constructed model
> directly into the resource. Unfortunately it still remains the same
> problem:
So it's not a copy problem.
>
> The template file constains all entries (all containment)
> <MODEL xmi:id="_PU9mkeMxEd6pZ6tfMeq-ww">
> <SUBDIAGRAM1 xmi:type="SUBDIAGRAM_TYPE"
> xmi:id="_QGcG0OMxEd6pZ6tfMeq-ww" name="Structure Diagram">
> <packagedElement xmi:type="uml:Class"
> xmi:id="_QksJEOMxEd6pZ6tfMeq-ww" name="Class1"/>
> <packagedElement xmi:type="uml:Class"
> xmi:id="_SfUpwOMxEd6pZ6tfMeq-ww" name="Class2">
> <generalization xmi:type="uml:Generalization"
> xmi:id="_WvHrAOMxEd6pZ6tfMeq-ww" general="_QksJEOMxEd6pZ6tfMeq-ww"/>
> </packagedElement>
> ...
> </SUBDIAGRAM1>
> <SUBDIAGRAM2 xmi:type="SUBDIAGRAM_TYPE2"
> xmi:id="_nC8e0OMxEd6pZ6tfMeq-ww" name="Knowledge Diagram">
> <packagedElement xmi:type="uml:Class"
> xmi:id="_rJp1gOMxEd6pZ6tfMeq-ww" name="Class3">
> <ownedAttribute xmi:type="uml:Property"
> xmi:id="_sd_yQOMxEd6pZ6tfMeq-ww" name="Property1"
> aggregation="composite"/>
>
> and so on...
>
> After constructuing the new Diagram and saving the resource I end up
> with:
> <MODEL xmi:id="_AaUgEfnWEd6ukN-HoOMqxQ">
> <SUBDIAGRAM1 xmi:type="SUBDIAGRAM_TYPE"
> href="file:/PATH#_QGcG0OMxEd6pZ6tfMeq-ww"/>
> <SUBDIAGRAM2 xmi:type="SUBDIAGRAM_TYPE2"
> href="file:/PATH#_nC8e0OMxEd6pZ6tfMeq-ww"/>
> ...
Is the containment reference a proxy resolving one? In that case cross
resource containment is supported so it will be neccessary to explicitly
remove the subdiagrams from their resource, i.e., using
resource.getContents().remove or clear.
>
>
> I want the same (complete) information which is stored in the template
> to be in the constructed file too. (And not just href links)
>
> For subdiagrams which are constructed programatically this all works
> fine (creating the diagram via a command and the factory classes).
>
> I use the following code to load the templates:
>
> URI uri = URI.createFileURI(fPath);
> Resource resource = resourceSet.createResource(uri);
>
> resource.load(Collections.EMPTY_MAP);
> EList<EObject> contents = resource.getContents();
> Model mdl = null;
> for (EObject eObject : contents) {
> if (eObject instanceof Model) {
> mdl = (Model) eObject;
> break;
> }
> }
>
> and then select present subdiagrams by using (getXXXX() != null)
> querries to determine if a sub diagram is contained in this template.
>
> After selecting the desired sub diagrams I create an empty model and
> use setXXXXX(SUBDIAGRAM) to include the selected ones. This construct
> is then passed to the wizards createDiagram(URI diagramURI,
> IProgressMonitor progressMonitor) method which is altered to use the
> construct instead of creating a new empty model.
>
> As you can see from the XML above all information should be stored in
> the file as they all are containment references.
It sounds likely that the containment reference is proxy resolving and
that you'll have to explicitly remove the referenced objects from their
containing resource.
>
> Ed Merks schrieb:
>> Daniel,
>>
>> Comments below.
>>
>> Daniel Rippel wrote:
>>> Hi all,
>>>
>>> I have a problem concering the storage (files) of eObjects.
>>>
>>> SETTING:
>>> I have a Model which is composed of different sub-diagrams. I'm
>>> actually trying to implement a "new model wizard" which allows to
>>> create a model from several predefined models by selecting and
>>> combining sub-diagrams.
>>>
>>> Actually I
>>> 1) Scan a specified directory for exsiting model files (templates)
>>> and load them.
>>> (works fine)
>>> 2) The wizard displays all sub-diagrams and the user can select the
>>> desired combination
>>> (works fine)
>>> 3) I use ECoreUtil.copy(SUBDIAGRAM) to create copies of the
>>> subdiagrams and insert them into a newly created model object
>>> (created using the eFactory.INSTANCE of the model).
>>> (Here is where the problems occur)
>> I suspect if you're calling copy multiple times you should really be
>> calling copyAll just once...
>>> 4) I create a resource and use default wizard code to save the model
>>> in its own file.
>>>
>>> PROBLEMS:
>>> The problem I encounter is that the sub-diagrams are only stored as
>>> proxies with the "template file" as eStorage().
>> You're saying there are unresolved proxies when you load the new
>> result, or when you're loading the thing to be copied?
>>> Thus all modifications to the diagrams affect the template (The
>>> models relations to the subdiagrams are set to containment).
>>> Moreover, in some cases the CannonicalEditPolicy fails to update the
>>> newly created file on opening it. The app freezes and crashes with a
>>> "Java Heap Space Overflow" Exception. (The application is set to 1gb
>>> Memory and it takes close to a minute until the error is thrown)
>>>
>>> I use ECoreUtil to copy the eObjects (sub-diagrams), but they still
>>> refer to the template file and are only stored as references (href)
>>> in the created model file.
>>> (Modelfile entry:
>>> <SUBDIAGRAM xmi:type="DIAGRAM_TYPE"
>>> href="file:/PATH_TO_THE_TEMPLATEFILE#_QGcG0OMxEd6pZ6tfMeq-ww "/>
>>> )
>> Only containment references are copied recursively. Non-containment
>> references will refer to a copy only if the referenced object has
>> also been copied at the same time.
>>>
>>>
>>> MY QUESTION:
>>> Is there any easy way to create a real copy of an eObject (in a way
>>> that it will be contained in the new file) or is it possible to
>>> somehow clear the link to the template file?
>> Do you want this reference to end up null in the copy even though
>> it's non-null in the original? You'd have to do that manually... Or
>> is the problem that the template file should also be copied?
>>> I already tried to "resolveAll(eObject)" but this makes no
>>> difference :) In my understanding this only surpresses the load on
>>> demand behavior of distributed models.
>> Yes, it forces early resolves.
>>>
>>>
>>> Sorry for the long text and thank you for your answers and hints in
>>> advance!
>> One question I would ask is why even make copies? Why not just move
>> the original objects. Moving them out of their containing resource
>> will have no externally visible effect on that resource unless you
>> save it in that modified state.
>>>
>>> With Regards,
>>> Daniel
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.03177 seconds
] 
Search
Help
Register
Login
Home
