|Re: URI mapping and proxy resolution [message #1433896 is a reply to message #1433832]
||Mon, 29 September 2014 11:39
| Ed Merks
Registered: July 2009
On 29/09/2014 11:49 AM, scott@xxxxxxxx wrote:
> My client application is capturing and sending forward
> ChangeDescriptions across the wire and applying them to a model on the
> server. These are created using ChangeDescription.copyAndReverse().
> For simple ChangeDesriptions (one's that don't include
> 'objectsToAttach'), my URI mapping works great, proxies resolve and
> the apply() works fine on the server.
I see. Note that there is also support for directly producing a reverse
description. You can see how
org.eclipse.emf.test.core.change.ChangeDescriptionReverseTest tests that...
> But proxy resolution is only partially working when the
> ChangeDescription includes 'objectsToAttach' that themselves have
> proxies to resolve. Here's a serialized example of a ChangeDescription
> that is not working.
> <?xml version="1.0" encoding="ASCII"?>
> <change:ChangeDescription xmi:version="2.0"
> <key href="simulated-regatta.rml#_0GftdTQqEeSfEe7w4GdblA"/>
> <value featureName="results" referenceValue="//@objectsToAttach.0"/>
> <objectsToAttach xsi:type="rml:Results">
> <split time="08:12:24.030">
I see they're both relative URIs, so that looks good. Note that upon
deserializing these are likely absolute URIs in the eProxyURI.
> The first proxy in <objectChanges> get mapped and resolves just fine.
> This allows the apply() to properly attach the objects to the target
> model, except it doesn't resolve the proxy within the
> 'objectsToAttach' that points to the very same resource, but
> references a different object in the fragment.
> I thought that maybe the uuid for the unresolved object didn't exist,
> but it does. Here it is:
> <timingMilestone xmi:id="_0GfsozQqEeSfEe7w4GdblA" name="Starting Line"
> Here's a snippet of what the model looks like after the apply().
> <racingCrew xmi:id="_0GftdTQqEeSfEe7w4GdblA"
> crew="_0GftaTQqEeSfEe7w4GdblA" laneNumber="1" bowNumber="27">
> <results xmi:id="_CNigQEc5EeS-B7w8xwh6GQ">
> <split xmi:id="_CNigQUc5EeS-B7w8xwh6GQ" time="08:12:24.030">
> What could cause one proxy URI to be converted, while another with the
> same URI in the same ChangeDescription does not?
Is the resource into which it's added in the same resource set as the
change description? (A brute force solution might be to call
EcoreUtil.resolveAll on the change description first). If all else
fails, set a conditional breakpoint in
but given the URIs look correct, it's most likely that the object is
moved to a resource that's not in a resource set and hence is not able
to resolve proxies...
> Do I need to do something special to get the inner (timingMilestone
> href in my particular case) proxy to resolve during the
> ChangeDescription.apply() process?
Powered by FUDForum
. Page generated in 0.01775 seconds