Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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)
[Edapt] Proxy related issues on deserialization [message #1729268] Tue, 12 April 2016 13:20 Go to next message
Ian Price is currently offline Ian PriceFriend
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.
Re: [Edapt] Proxy related issues on deserialization [message #1729390 is a reply to message #1729268] Wed, 13 April 2016 15:55 Go to previous message
Johannes Faltermeier is currently offline Johannes FaltermeierFriend
Messages: 70
Registered: December 2013
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/
Previous Topic:[EMF Forms 1.7.2] Reference fields is not shown
Next Topic:[Teneo,Texo] Migrate from Teneo to Texo
Goto Forum:
  


Current Time: Sat Nov 18 23:42:40 GMT 2017

Powered by FUDForum. Page generated in 0.01916 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software