Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » [Edapt] Proxy related issues on deserialization

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Edapt] Proxy related issues on deserialization(Discussion of Edapt proxy resolution behavior for non-containment relationships to other unserialized models)

Show: Today's Messages :: Show Polls :: Message Navigator

Tue, 12 April 2016 13:20

Ian Price

Messages: 1
Registered: April 2016

Junior Member

I have model content (call it Instance A) that, due to a perverse project, must resolve proxies (using non-containment EReferences) to a separate EMF model that can only exist in memory (Instance B). Both Instance A and Instance B use the same EMF model but Instance A is an earlier version. Before using Edapt when Instance A and Instance B were the same version, the EMF XMIResource would create stub Instance B instances for the Instance A proxies and we used separate code to replace them with the correct in-memory instances. It seems that while Edapt deserializes Instance A it also creates stub instances of the Instance B content. However, the Edapt process fails the migration with those stubs. What's worse is that I have large numbers of these instances that all have to be loadable within a reasonable timeframe (<5 minutes) and the instances are typically extremely large.

The messages that it provides are pretty much all like:

The 'validType' constraint is violated on 'Reference "pointer" of Instance of type "[Instance A Container of Proxy Reference]"'
The 'validFeature' constraint is violated on 'Reference "[Instance A Container of Proxy Reference]" of Instance of type "[Instance B type of thing being referenced]"'

And the Edapt portion of the stack trace is:

at org.eclipse.emf.edapt.spi.migration.impl.ModelImpl.checkConformance(ModelImpl.java:508)
	at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.checkConformance(MigrationReconstructor.java:174)
	at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.checkConformanceIfMoreThan(MigrationReconstructor.java:167)
	at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.loadRepository(MigrationReconstructor.java:190)
	at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.endRelease(MigrationReconstructor.java:155)
	at org.eclipse.emf.edapt.history.reconstruction.CompositeReconstructorBase.endRelease(CompositeReconstructorBase.java:179)
	at org.eclipse.emf.edapt.history.reconstruction.ForwardReconstructorBase.doReconstruct(ForwardReconstructorBase.java:81)
	at org.eclipse.emf.edapt.history.reconstruction.ForwardReconstructorBase.doReconstruct(ForwardReconstructorBase.java:57)
	at org.eclipse.emf.edapt.history.reconstruction.CompositeReconstructorBase.reconstruct(CompositeReconstructorBase.java:74)
	at org.eclipse.emf.edapt.migration.execution.Migrator.migrate(Migrator.java:265)
	at org.eclipse.emf.edapt.migration.execution.Migrator.migrateAndLoad(Migrator.java:217)

Is there a way to cause the Edapt proxies to attach correctly to the in-memory instance?

Barring that, is there any way to cause Edapt to NOT load proxies while uplifting a model? We could then use the same process to attach the correct in-memory instance by parsing out the proxy URI.

Barring that, is there a way that we could change the EMF model to a new version that could convert the proxy URIs into Strings (using any combination of volatile EReferences, new EAttributes, etc)? We could then use code similar to our old approach to attach to in-memory Instances?

I guess I'm looking for suggestions from anyone at this point.

Report message to a moderator

Re: [Edapt] Proxy related issues on deserialization [message #1729390 is a reply to message #1729268]

Wed, 13 April 2016 15:55

Johannes Faltermeier

Messages: 101
Registered: December 2013

Senior Member

Hi Ian,

Pretty wild stuff.
There is currently no way to influence the loading code of Edapt like that.
If you want to take a look at the loading code and maybe play around a bit:
org.eclipse.emf.edapt.internal.common.ResourceUtils.loadResourceSet(List<URI>, List<EPackage>, IResourceSetFactory)

Otherwise performing a "pre-migration" without edapt could be an option.
So, you get the NS-URI from your XMI file. If this is the version which still contains those proxy references, you manually replace those with a new attribute + string and update the ns uri using some kind of XMI-tool.
When you create/adjust your Ecore to be able to load this model, you can start your edapt history with the actual model refactorings from this metamodel version.

Johannes Faltermeier

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/

Report message to a moderator

Previous Topic:	[EMF Forms 1.7.2] Reference fields is not shown
Next Topic:	[Teneo,Texo] Migrate from Teneo to Texo

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 22:53:49 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter