Home » Modeling » EMF » XML Resource resolving problems
| XML Resource resolving problems [message #429768] |
Thu, 30 April 2009 21:55  |
Eclipse User |
|
|
|
Originally posted by: wesendon.in.tum.de
Hi,
I've got a quite confusing problem with emf xml files. What I'm doing is
to load a bunch of xml resources and do some validation and then, for
test purposes, I write the elements back to files and compare them with
the original files. My expectation is them to be similar, but for some
reasons they aren't, expect I use EcoreUtil.copy();
(All elements distributed on multiple files are in one big containment tree)
So, again, if I load the elements and then just save them, there are
some resolving issues?! But if I use the ecore copy method on the
elements and then save them, they are similar and there is no problem.
Here's an example:
If I load the elements, copy them and save them, they look like this (as
the original file):
<modelElements xsi:type="org.unicase.model.meeting:Meeting"
identifier="_sfct0J-7Ed2Mf6xmMnysAw" name="1. Teamtreffen"
creator="helming" creationDate="2008-10-22T00:00:38.445+0200"
location="Terrarium" starttime="2008-10-20T00:00:38.005+0200"
endtime="2008-10-20T00:00:38.650+0200"
facilitator="_jM-KoZ6vEd2YUekMfIrcIA"
minutetaker="_jQL2sZ6vEd2YUekMfIrcIA"
timekeeper="_jM-KoZ6vEd2YUekMfIrcIA"
identifiedIssuesSection="_sfdU5Z-7Ed2Mf6xmMnysAw"
identifiedWorkItemsSection="_sfdU55-7Ed2Mf6xmMnysAw">
If I load the elements and then immediately save them again, they look
like this:
<modelElements xsi:type="org.unicase.model.meeting:Meeting"
identifier="_sfct0J-7Ed2Mf6xmMnysAw" name="1. Teamtreffen"
creator="helming" creationDate="2008-10-22T00:00:38.445+0200"
location="Terrarium" starttime="2008-10-20T00:00:38.005+0200"
endtime="2008-10-20T00:00:38.650+0200"
facilitator="_jM-KoZ6vEd2YUekMfIrcIA"
minutetaker="_jQL2sZ6vEd2YUekMfIrcIA" timekeeper="_jM-KoZ6vEd2YUekMfIrcIA">
[...]
<identifiedIssuesSection
href=" file:/C:/Users/Otto/.unicase.dev/emfstore/project-_vJNjlI-jE d2NxKsJ-WbHVA/changepackage-60.ucp#_sfdU5Z-7Ed2Mf6xmMnysAw "/>
<identifiedWorkItemsSection
href=" file:/C:/Users/Otto/.unicase.dev/emfstore/project-_vJNjlI-jE d2NxKsJ-WbHVA/changepackage-60.ucp#_sfdU55-7Ed2Mf6xmMnysAw "/>
</modelElements>
As you can see, the attributes identifiedIssueSection and
identifiedWorkItemSection aren't resolved correctly.
What's confusing me even more, that it's not happening everywhere. I
don't know why, of all things, this element is so corrupted. And why
does it work if I do a copy?
I hope you can help me to resolve this issue. If you need any more
informations, let me know.
Greetings,
Otto
|
|
|
| Re: XML Resource resolving problems [message #429770 is a reply to message #429768] |
Thu, 30 April 2009 23:05  |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Otto,
Comments below.
Otto wrote:
> Hi,
>
> I've got a quite confusing problem with emf xml files. What I'm doing is
> to load a bunch of xml resources and do some validation and then, for
> test purposes, I write the elements back to files
Just any old files? Or back to the original ones?
> and compare them with
> the original files.
I take it you save to new files. You've said nothing about how you go
about renaming all the files so that all the new saves files refer to
other new saved files...
> My expectation is them to be similar, but for some
> reasons they aren't, expect I use EcoreUtil.copy();
>
You use copy, but how?
> (All elements distributed on multiple files are in one big containment tree)
>
> So, again, if I load the elements and then just save them, there are
> some resolving issues?!
Resolving meaning?
> But if I use the ecore copy method on the
> elements and then save them, they are similar and there is no problem.
>
Similar but not the same. Using copy how?
> Here's an example:
>
> If I load the elements, copy them and save them, they look like this (as
> the original file):
>
Copy them how?
> <modelElements xsi:type="org.unicase.model.meeting:Meeting"
> identifier="_sfct0J-7Ed2Mf6xmMnysAw" name="1. Teamtreffen"
> creator="helming" creationDate="2008-10-22T00:00:38.445+0200"
> location="Terrarium" starttime="2008-10-20T00:00:38.005+0200"
> endtime="2008-10-20T00:00:38.650+0200"
> facilitator="_jM-KoZ6vEd2YUekMfIrcIA"
> minutetaker="_jQL2sZ6vEd2YUekMfIrcIA"
> timekeeper="_jM-KoZ6vEd2YUekMfIrcIA"
> identifiedIssuesSection="_sfdU5Z-7Ed2Mf6xmMnysAw"
> identifiedWorkItemsSection="_sfdU55-7Ed2Mf6xmMnysAw">
>
> If I load the elements and then immediately save them again, they look
> like this:
>
> <modelElements xsi:type="org.unicase.model.meeting:Meeting"
> identifier="_sfct0J-7Ed2Mf6xmMnysAw" name="1. Teamtreffen"
> creator="helming" creationDate="2008-10-22T00:00:38.445+0200"
> location="Terrarium" starttime="2008-10-20T00:00:38.005+0200"
> endtime="2008-10-20T00:00:38.650+0200"
> facilitator="_jM-KoZ6vEd2YUekMfIrcIA"
> minutetaker="_jQL2sZ6vEd2YUekMfIrcIA" timekeeper="_jM-KoZ6vEd2YUekMfIrcIA">
> [...]
>
It's pretty much an eye chart to me... I've heard that UUIDs can cause
blindness.
> <identifiedIssuesSection
> href=" file:/C:/Users/Otto/.unicase.dev/emfstore/project-_vJNjlI-jE d2NxKsJ-WbHVA/changepackage-60.ucp#_sfdU5Z-7Ed2Mf6xmMnysAw "/>
> <identifiedWorkItemsSection
> href=" file:/C:/Users/Otto/.unicase.dev/emfstore/project-_vJNjlI-jE d2NxKsJ-WbHVA/changepackage-60.ucp#_sfdU55-7Ed2Mf6xmMnysAw "/>
> </modelElements>
>
>
> As you can see,
It's hard to see after loss of vision.
> the attributes identifiedIssueSection and
> identifiedWorkItemSection aren't resolved correctly.
>
So no, not so much. Eye problems...
> What's confusing me even more, that it's not happening everywhere. I
> don't know why, of all things, this element is so corrupted. And why
> does it work if I do a copy?
>
I'm at a loss for words. Ouch my eyes hurt....
> I hope you can help me to resolve this issue. If you need any more
> informations, let me know.
>
If you load something, make no changes, and save it, I'd expect it to
save just like the last time you saved... If you save to different
URIs, you'd better rename all the resources before you save any one of
them. The copy part I'm in the dark about...
> Greetings,
> Otto
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: XML Resource resolving problems [message #429777 is a reply to message #429770] |
Fri, 01 May 2009 01:13 |
| Eclipse User |
|
|
|
Originally posted by: wesendon.in.tum.de
Hi Ed,
I tried to abstract from what I'm actually doing, because I thought it
would be easier to understand. Now let me explain the whole thing and
hopefully this won't confuse you even more and makes you blind in long
terms ;)
I'm working on a server which allows you to save a versionhistory of
your model with emf - quite similar to svn (it's changebased instead of
statebased). You might heard of it: unicase/emfstore.
Here is the emf/resource structure: I have a projectHistory element
which contains several version elements. Each version has a
changepackage, which contains the changes from one version to the next.
Every 50th version contains a projectstate in which the whole state of
the modelelments is saved (for safety reasons).
The main projectHistory file, versions, changepackes and projecstates
are all in their own resource file and are connected in a big tree via
cross containment with the projectHistory file as the root element.
So what I did is to load the resources, take the first projecstate and
then apply these changepackages on this initial projecstate until I
reach the next version which has a projecstate. With all these changes
applied the initial projecstate should be similar to the next saved
projecstate. In order to check this, I serialized both projectstates,
the saved and the "calculated" one, and saved them in random files on my
desktop and just did a file/string compare.
And now the "copy"/emf magic problem i stumbled upon:
I loaded the root history element directly from the resource (all other
resources are loaded automatically thanks to emf), copied it (One simple
line: ProjectHistory history = (ProjectHistory)
EcoreUtil.copy(projectHistory)) and runed the explained procedure on
this history element. And the resulting projecstates were similar (after
fixing some changerecording issues) and I was happy ;).
Then, while refactoring, I removed the copy line, did the exact same
test and suddenly the projecstate weren't similar anymore.
The differences on some elements in the projecstate were like the eye
cancer stuff I posted before, simplified:
It should look like this: <element attr1="value1" attri2="value2" />
but it looked like:
<element attr1="value1">
<attri2 href="../../somefile" />
<element/>
And the only difference is the EcoreUtil.copy. Now while writing this,
the thought came, that it could be about pulling out the element out the
resource set by copying. But actually, it doesn't really explain the
problem.
What am I missing - and sorry for this epic post
Greetings,
Otto
Ed Merks schrieb:
> Otto,
>
> Comments below.
>
> Otto wrote:
>> Hi,
>>
>> I've got a quite confusing problem with emf xml files. What I'm doing is
>> to load a bunch of xml resources and do some validation and then, for
>> test purposes, I write the elements back to files
> Just any old files? Or back to the original ones?
>> and compare them with
>> the original files.
> I take it you save to new files. You've said nothing about how you go
> about renaming all the files so that all the new saves files refer to
> other new saved files...
>> My expectation is them to be similar, but for some
>> reasons they aren't, expect I use EcoreUtil.copy();
>>
> You use copy, but how?
>> (All elements distributed on multiple files are in one big containment
>> tree)
>>
>> So, again, if I load the elements and then just save them, there are
>> some resolving issues?!
> Resolving meaning?
>> But if I use the ecore copy method on the
>> elements and then save them, they are similar and there is no problem.
>>
> Similar but not the same. Using copy how?
>> Here's an example:
>>
>> If I load the elements, copy them and save them, they look like this (as
>> the original file):
>>
> Copy them how?
>> <modelElements xsi:type="org.unicase.model.meeting:Meeting"
>> identifier="_sfct0J-7Ed2Mf6xmMnysAw" name="1. Teamtreffen"
>> creator="helming" creationDate="2008-10-22T00:00:38.445+0200"
>> location="Terrarium" starttime="2008-10-20T00:00:38.005+0200"
>> endtime="2008-10-20T00:00:38.650+0200"
>> facilitator="_jM-KoZ6vEd2YUekMfIrcIA"
>> minutetaker="_jQL2sZ6vEd2YUekMfIrcIA"
>> timekeeper="_jM-KoZ6vEd2YUekMfIrcIA"
>> identifiedIssuesSection="_sfdU5Z-7Ed2Mf6xmMnysAw"
>> identifiedWorkItemsSection="_sfdU55-7Ed2Mf6xmMnysAw">
>>
>> If I load the elements and then immediately save them again, they look
>> like this:
>>
>> <modelElements xsi:type="org.unicase.model.meeting:Meeting"
>> identifier="_sfct0J-7Ed2Mf6xmMnysAw" name="1. Teamtreffen"
>> creator="helming" creationDate="2008-10-22T00:00:38.445+0200"
>> location="Terrarium" starttime="2008-10-20T00:00:38.005+0200"
>> endtime="2008-10-20T00:00:38.650+0200"
>> facilitator="_jM-KoZ6vEd2YUekMfIrcIA"
>> minutetaker="_jQL2sZ6vEd2YUekMfIrcIA"
>> timekeeper="_jM-KoZ6vEd2YUekMfIrcIA">
>> [...]
>>
> It's pretty much an eye chart to me... I've heard that UUIDs can cause
> blindness.
>> <identifiedIssuesSection
>> href=" file:/C:/Users/Otto/.unicase.dev/emfstore/project-_vJNjlI-jE d2NxKsJ-WbHVA/changepackage-60.ucp#_sfdU5Z-7Ed2Mf6xmMnysAw "/>
>>
>> <identifiedWorkItemsSection
>> href=" file:/C:/Users/Otto/.unicase.dev/emfstore/project-_vJNjlI-jE d2NxKsJ-WbHVA/changepackage-60.ucp#_sfdU55-7Ed2Mf6xmMnysAw "/>
>>
>> </modelElements>
>>
>>
>> As you can see,
> It's hard to see after loss of vision.
>> the attributes identifiedIssueSection and
>> identifiedWorkItemSection aren't resolved correctly.
>>
> So no, not so much. Eye problems...
>> What's confusing me even more, that it's not happening everywhere. I
>> don't know why, of all things, this element is so corrupted. And why
>> does it work if I do a copy?
>>
> I'm at a loss for words. Ouch my eyes hurt....
>> I hope you can help me to resolve this issue. If you need any more
>> informations, let me know.
>>
> If you load something, make no changes, and save it, I'd expect it to
> save just like the last time you saved... If you save to different
> URIs, you'd better rename all the resources before you save any one of
> them. The copy part I'm in the dark about...
>> Greetings,
>> Otto
>>
|
|
|
| Re: XML Resource resolving problems [message #429790 is a reply to message #429777] |
Fri, 01 May 2009 09:27 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Otto,
Comments below.
Otto wrote:
> Hi Ed,
>
> I tried to abstract from what I'm actually doing, because I thought it
> would be easier to understand. Now let me explain the whole thing and
> hopefully this won't confuse you even more and makes you blind in long
> terms ;)
>
Hehehe.
> I'm working on a server which allows you to save a versionhistory of
> your model with emf - quite similar to svn (it's changebased instead of
> statebased). You might heard of it: unicase/emfstore.
>
I wonder if CDO already does something like that at a finer level of
granularity...
> Here is the emf/resource structure: I have a projectHistory element
> which contains several version elements. Each version has a
> changepackage, which contains the changes from one version to the next.
> Every 50th version contains a projectstate in which the whole state of
> the modelelments is saved (for safety reasons).
> The main projectHistory file, versions, changepackes and projecstates
> are all in their own resource file and are connected in a big tree via
> cross containment with the projectHistory file as the root element.
>
I see.
> So what I did is to load the resources, take the first projecstate and
> then apply these changepackages on this initial projecstate until I
> reach the next version which has a projecstate. With all these changes
> applied the initial projecstate should be similar to the next saved
> projecstate. In order to check this, I serialized both projectstates,
> the saved and the "calculated" one, and saved them in random files on my
> desktop and just did a file/string compare.
>
Of course the cross file references will tend to look different, unless
you store them into relatively the same file structure... I.e., if you
keep the file names the same and just use a different root folder...
> And now the "copy"/emf magic problem i stumbled upon:
> I loaded the root history element directly from the resource (all other
> resources are loaded automatically thanks to emf), copied it (One simple
> line: ProjectHistory history = (ProjectHistory)
> EcoreUtil.copy(projectHistory)) and runed the explained procedure on
> this history element. And the resulting projecstates were similar (after
> fixing some changerecording issues) and I was happy ;).
>
So the copy will be of the entire containment tree, including the ones
from other resources. You'd have to split that back into separate
resources again to mirror the original ones...
> Then, while refactoring, I removed the copy line, did the exact same
> test and suddenly the projecstate weren't similar anymore.
>
An outstanding question here is what did you do with the copy? Did you
partition it into multiple resources again?
> The differences on some elements in the projecstate were like the eye
> cancer stuff I posted before, simplified:
>
> It should look like this: <element attr1="value1" attri2="value2" />
> but it looked like:
> <element attr1="value1">
> <attri2 href="../../somefile" />
> <element/>
>
Sounds like the difference between a cross resource references verses a
same resource reference...
> And the only difference is the EcoreUtil.copy. Now while writing this,
> the thought came, that it could be about pulling out the element out the
> resource set by copying. But actually, it doesn't really explain the
> problem.
>
> What am I missing - and sorry for this epic post
>
No problem. Here's what I'd suggest. Look carefully at your resource
set of the original instance, i.e., what resources are there and what
are their URIs. When you make a copy, put that into a new resource set
and again, consider carefully how the resources in the "copied" resource
set relate to the originals.
Other things to consider. If you rename a resource (change the URI of a
Resource) but there are unresolved proxies that use the old URI, those
will be saved using that old URI because saving does not resolve
proxies. So EcoreUtil.resolveAll might be useful and be sure to rename
all Resources before saving any of them. If you rename then by
changing only a root folder, the relative references should hopefully
produce identical results to what you loaded. Of course if you use
generated UUIDs, those will be different in the copy...
> Greetings,
> Otto
>
> Ed Merks schrieb:
>
>> Otto,
>>
>> Comments below.
>>
>> Otto wrote:
>>
>>> Hi,
>>>
>>> I've got a quite confusing problem with emf xml files. What I'm doing is
>>> to load a bunch of xml resources and do some validation and then, for
>>> test purposes, I write the elements back to files
>>>
>> Just any old files? Or back to the original ones?
>>
>>> and compare them with
>>> the original files.
>>>
>> I take it you save to new files. You've said nothing about how you go
>> about renaming all the files so that all the new saves files refer to
>> other new saved files...
>>
>>> My expectation is them to be similar, but for some
>>> reasons they aren't, expect I use EcoreUtil.copy();
>>>
>>>
>> You use copy, but how?
>>
>>> (All elements distributed on multiple files are in one big containment
>>> tree)
>>>
>>> So, again, if I load the elements and then just save them, there are
>>> some resolving issues?!
>>>
>> Resolving meaning?
>>
>>> But if I use the ecore copy method on the
>>> elements and then save them, they are similar and there is no problem.
>>>
>>>
>> Similar but not the same. Using copy how?
>>
>>> Here's an example:
>>>
>>> If I load the elements, copy them and save them, they look like this (as
>>> the original file):
>>>
>>>
>> Copy them how?
>>
>>> <modelElements xsi:type="org.unicase.model.meeting:Meeting"
>>> identifier="_sfct0J-7Ed2Mf6xmMnysAw" name="1. Teamtreffen"
>>> creator="helming" creationDate="2008-10-22T00:00:38.445+0200"
>>> location="Terrarium" starttime="2008-10-20T00:00:38.005+0200"
>>> endtime="2008-10-20T00:00:38.650+0200"
>>> facilitator="_jM-KoZ6vEd2YUekMfIrcIA"
>>> minutetaker="_jQL2sZ6vEd2YUekMfIrcIA"
>>> timekeeper="_jM-KoZ6vEd2YUekMfIrcIA"
>>> identifiedIssuesSection="_sfdU5Z-7Ed2Mf6xmMnysAw"
>>> identifiedWorkItemsSection="_sfdU55-7Ed2Mf6xmMnysAw">
>>>
>>> If I load the elements and then immediately save them again, they look
>>> like this:
>>>
>>> <modelElements xsi:type="org.unicase.model.meeting:Meeting"
>>> identifier="_sfct0J-7Ed2Mf6xmMnysAw" name="1. Teamtreffen"
>>> creator="helming" creationDate="2008-10-22T00:00:38.445+0200"
>>> location="Terrarium" starttime="2008-10-20T00:00:38.005+0200"
>>> endtime="2008-10-20T00:00:38.650+0200"
>>> facilitator="_jM-KoZ6vEd2YUekMfIrcIA"
>>> minutetaker="_jQL2sZ6vEd2YUekMfIrcIA"
>>> timekeeper="_jM-KoZ6vEd2YUekMfIrcIA">
>>> [...]
>>>
>>>
>> It's pretty much an eye chart to me... I've heard that UUIDs can cause
>> blindness.
>>
>>> <identifiedIssuesSection
>>> href=" file:/C:/Users/Otto/.unicase.dev/emfstore/project-_vJNjlI-jE d2NxKsJ-WbHVA/changepackage-60.ucp#_sfdU5Z-7Ed2Mf6xmMnysAw "/>
>>>
>>> <identifiedWorkItemsSection
>>> href=" file:/C:/Users/Otto/.unicase.dev/emfstore/project-_vJNjlI-jE d2NxKsJ-WbHVA/changepackage-60.ucp#_sfdU55-7Ed2Mf6xmMnysAw "/>
>>>
>>> </modelElements>
>>>
>>>
>>> As you can see,
>>>
>> It's hard to see after loss of vision.
>>
>>> the attributes identifiedIssueSection and
>>> identifiedWorkItemSection aren't resolved correctly.
>>>
>>>
>> So no, not so much. Eye problems...
>>
>>> What's confusing me even more, that it's not happening everywhere. I
>>> don't know why, of all things, this element is so corrupted. And why
>>> does it work if I do a copy?
>>>
>>>
>> I'm at a loss for words. Ouch my eyes hurt....
>>
>>> I hope you can help me to resolve this issue. If you need any more
>>> informations, let me know.
>>>
>>>
>> If you load something, make no changes, and save it, I'd expect it to
>> save just like the last time you saved... If you save to different
>> URIs, you'd better rename all the resources before you save any one of
>> them. The copy part I'm in the dark about...
>>
>>> Greetings,
>>> Otto
>>>
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 27 00:15:41 GMT 2024
Powered by FUDForum. Page generated in 0.03212 seconds |
] 
Search
Help
Register
Login
Home
