Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] How to import XMI resource in an empty repository
[CDO] How to import XMI resource in an empty repository [message #1219548] Wed, 04 December 2013 15:18 Go to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi all,

I currently try to develop a repository migration tool.
I first export the source repository content in XMI resource files.

Now, I want to load these files in a distinct and empty destination repository.
I basically copy each XMI resource content to the corresponding resource created in the destination repository :

// Import each XMI resource file in the destination repository
output.println(importDialog.getFileNames().length + " files selected");
ResourceSet rs = new ResourceSetImpl();
rs.getResourceFactoryRegistry().getExtensionToFactoryMap().put("*.xmi", new XMIResourceFactoryImpl());
for (String fileName : importDialog.getFileNames()) {
	output.print("Import resource '" + fileName.substring(0, fileName.length()-4) + "' : ");
	CDOResource cdoRes = transaction.createResource(fileName.substring(0, fileName.length()-4));
	File xmiFile = new File(importDialog.getFilterPath() + "/" + fileName);
	Resource xmiRes = rs.getResource(URI.createURI(xmiFile.toURI().toString()), true);
	cdoRes.getContents().addAll(xmiRes.getContents());
	output.println("done");
}
output.print("Commit import : ");
try {
	transaction.commit();
	output.println("done");
} catch (ConcurrentAccessException e) {
	// TODO Auto-generated catch block
	e.printStackTrace();
} catch (CommitException e) {
	// TODO Auto-generated catch block
	e.printStackTrace();
}


The result is a 'DanglingReferenceException' at commit :
org.eclipse.emf.cdo.util.DanglingReferenceException: The object "PictogramLink[TRANSIENT](org.eclipse.graphiti.mm.pictograms.impl.PictogramLinkImpl)" is not contained in a resource


Reading another topic, I changed my cdo-server.xml configuration to generate CDO IDs on client side so that the ones created in the source repository could be reused in the empty destination repository...

<property name="idGenerationLocation" value="CLIENT"/>
<property name="idColumnLength" value="34"/>


But I now get a 'FileNotFoundException' on the first XMI resource to import when I invoke transaction#createResource in the destination repository :
org.eclipse.e4.core.di.InjectionException: org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException: java.io.FileNotFoundException: 1 (Le fichier spécifié est introuvable)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:63)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:243)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:224)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
	at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:167)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:213)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:285)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:504)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:555)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:376)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:322)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:84)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1056)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1081)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1066)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1108)
	at org.eclipse.swt.widgets.Shell.sendKeyEvent(Shell.java:1384)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
	at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1525)
	at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4723)
	at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:344)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4611)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:340)
	at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1627)
	at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2075)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:4977)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2549)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
	at repositorymigration.Application.start(Application.java:20)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
Caused by: org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException: java.io.FileNotFoundException: 1 (Le fichier spécifié est introuvable)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.handleDemandLoadException(ResourceSetImpl.java:319)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:278)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:406)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:220)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:970)
	at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.getObject(CDOTransactionImpl.java:1152)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:940)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getRootResource(AbstractCDOView.java:319)
	at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.attachNewResourceNode(CDOTransactionImpl.java:1022)
	at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.attachNewResource(CDOTransactionImpl.java:952)
	at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.attachResource(CDOTransactionImpl.java:941)
	at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.basicSetResourceSet(CDOResourceImpl.java:1554)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$ResourcesEList.inverseAdd(ResourceSetImpl.java:586)
	at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:286)
	at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:301)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.createResource(ResourceSetImpl.java:435)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.createResource(ResourceSetImpl.java:423)
	at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.createResource(CDOTransactionImpl.java:852)
	at repositorymigration.handlers.ImportHandler.execute(ImportHandler.java:71)
	at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:290)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	... 54 more
Caused by: java.io.FileNotFoundException: 1 (Le fichier spécifié est introuvable)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(Unknown Source)
	at org.eclipse.emf.ecore.resource.impl.FileURIHandlerImpl.createInputStream(FileURIHandlerImpl.java:99)
	at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.createInputStream(ExtensibleURIConverterImpl.java:360)
	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1269)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:259)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274)
	... 78 more


The file name '1' is strange and I don't understand why the resource creation in the repository would trigger an exception related to a file...

Any idea, what's wrong ?

Kind regards,

Laurent

Report message to a moderator

Re: [CDO] How to import XMI resource in an empty repository [message #1219732 is a reply to message #1219548] Thu, 05 December 2013 15:19 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi again,

I got confused with ID generation. It has nothing to do with my problem.
So, I'm back to the dangling reference exception...

org.eclipse.emf.cdo.util.DanglingReferenceException: The object "PictogramLink[TRANSIENT](org.eclipse.graphiti.mm.pictograms.impl.PictogramLinkImpl)" is not contained in a resource


The considered ecore model is the Graphiti one (not mine !).
I studied it and it seems that the PictogramLink object is correctly defined with a containment reference in a PictogramElement object (see attached ecore file).

So, unless I'm wrong, it is contained in the resource (see attached file) ?
(<PictogramLinks> tags at the end of the XMI file reference above <Link> tags contained in the resource)

Moreover, the XMI resource is an unmodified export of a source CDO repository with no problem about its content. How could an import in an empty CDO repository be a problem ?
Or maybe my migration approach is wrong ?

Regards
  • Attachment: graphiti.ecore
    (Size: 30.62KB, Downloaded 302 times)
  • Attachment: example.xmi
    (Size: 6.76KB, Downloaded 224 times)

Report message to a moderator

Re: [CDO] How to import XMI resource in an empty repository [message #1219759 is a reply to message #1219732] Thu, 05 December 2013 16:45 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Importing an object without its associated Graphiti diagram works fine.
So, the migration approach seems to be Ok.

I then changed several containment property to 'true' in graphiti.ecore.
The result is now that the object described by its associated diagram is not imported (anymore)...

org.eclipse.emf.cdo.util.DanglingReferenceException: The object "org.eclipse.emf.ecore.impl.EObjectImpl@111f5f1 (eProxyURI: file:/D:/Mes%20documents/tmp/L11)(org.eclipse.emf.ecore.impl.EObjectImpl)" is not contained in a resource
  • Attachment: test.xmi
    (Size: 3.77KB, Downloaded 234 times)

Report message to a moderator

Re: [CDO] How to import XMI resource in an empty repository [message #1219851 is a reply to message #1219759] Fri, 06 December 2013 09:29 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi again,

Using a "CDO compliant" transactional editing domain, I tried the EMF CopyCommand to make a copy of my CDO objects before adding them in the created CDO resource and in the empty destination repository.

I still get exactly the same dangling reference exception at commit... Sad

I'm really stuckked. Does anyone have an idea of what happens with my destination repository ?
I really don't understand why I can create my objects in the source repository and I'm not able to simply re-import them in the destination one after an XMI export.
Why do I have this dangling reference exception in one case and not the other ?
Is there a way to "force" the commit by - for instance - setting a property in cdo-server.xml ?

Regards,

Laurent

Report message to a moderator

Re: [CDO] How to import XMI resource in an empty repository [message #1219858 is a reply to message #1219548] Fri, 06 December 2013 10:04 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Hi Laurent,

Comments below...


Am 04.12.2013 16:18, schrieb Laurent Le Moux:
> Hi all,
>
> I currently try to develop a repository migration tool.
> I first export the source repository content in XMI resource files.
How exactly?

>
> Now, I want to load these files in a distinct and empty destination repository.
> I basically copy each XMI resource content to the corresponding resource created in the destination repository :
No, your code below suggests that you *move*, not copy.

>
>
> // Import each XMI resource file in the destination repository
> output.println(importDialog.getFileNames().length + " files selected");
> ResourceSet rs = new ResourceSetImpl();
It's probably better to use the target resource set instead of creating a separate new one:

ResourceSet rs = transaction.getResourceSet();

Cross references are only resolved within a single resource set. This might already solve your DanglingReferenceException.

> rs.getResourceFactoryRegistry().getExtensionToFactoryMap().put("*.xmi", new XMIResourceFactoryImpl());
The map keys are not filename patterns but filename *extensions*. Please use just "xmi":

rs.getResourceFactoryRegistry().getExtensionToFactoryMap().put("xmi", new XMIResourceFactoryImpl());

I think the global resource factory registry maps "xmi" by default.

> for (String fileName : importDialog.getFileNames()) {
> output.print("Import resource '" + fileName.substring(0, fileName.length()-4) + "' : ");
> CDOResource cdoRes = transaction.createResource(fileName.substring(0, fileName.length()-4));
> File xmiFile = new File(importDialog.getFilterPath() + "/" + fileName);
> Resource xmiRes = rs.getResource(URI.createURI(xmiFile.toURI().toString()), true);
> cdoRes.getContents().addAll(xmiRes.getContents());
> output.println("done");
> }
This approach might not scale very well. You may want to consider using CDO's server export/import, which uses a
scalable XML format (not EMF compatible, though).

> output.print("Commit import : ");
> try {
> transaction.commit();
> output.println("done");
> } catch (ConcurrentAccessException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (CommitException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
>
> The result is a 'DanglingReferenceException' at commit :
>
> org.eclipse.emf.cdo.util.DanglingReferenceException: The object
> "PictogramLink[TRANSIENT](org.eclipse.graphiti.mm.pictograms.impl.PictogramLinkImpl)" is not contained in a resource
Would your example work properly if you moved the loaded contents to another XMIResource instead of the CDOResource?

> Reading another topic, I changed my cdo-server.xml configuration to generate CDO IDs on client side so that the ones
> created in the source repository could be reused in the empty destination repository...
>
>
> <property name="idGenerationLocation" value="CLIENT"/>
> <property name="idColumnLength" value="34"/>
>
>
> But I now get a 'FileNotFoundException' on the first XMI resource to import when I invoke transaction#createResource
> in the destination repository :
>
> org.eclipse.e4.core.di.InjectionException:
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException: java.io.FileNotFoundException: 1 (Le
> fichier spécifié est introuvable)
> at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:63)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:243)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:224)
> at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
> at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:167)
> at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
> at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
> at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:213)
> at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:285)
> at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:504)
> at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:555)
> at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:376)
> at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:322)
> at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:84)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1056)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1081)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1066)
> at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1108)
> at org.eclipse.swt.widgets.Shell.sendKeyEvent(Shell.java:1384)
> at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
> at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1525)
> at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4723)
> at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:344)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:4611)
> at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:340)
> at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1627)
> at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2075)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:4977)
> at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
> at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2549)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at repositorymigration.Application.start(Application.java:20)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
> Caused by: org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException:
> java.io.FileNotFoundException: 1 (Le fichier spécifié est introuvable)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.handleDemandLoadException(ResourceSetImpl.java:319)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:278)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:406)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:220)
> at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:970)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.getObject(CDOTransactionImpl.java:1152)
> at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:940)
> at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getRootResource(AbstractCDOView.java:319)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.attachNewResourceNode(CDOTransactionImpl.java:1022)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.attachNewResource(CDOTransactionImpl.java:952)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.attachResource(CDOTransactionImpl.java:941)
> at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.basicSetResourceSet(CDOResourceImpl.java:1554)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$ResourcesEList.inverseAdd(ResourceSetImpl.java:586)
> at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:286)
> at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:301)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.createResource(ResourceSetImpl.java:435)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.createResource(ResourceSetImpl.java:423)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.createResource(CDOTransactionImpl.java:852)
> at repositorymigration.handlers.ImportHandler.execute(ImportHandler.java:71)
> at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:290)
> at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
> ... 54 more
> Caused by: java.io.FileNotFoundException: 1 (Le fichier spécifié est introuvable)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.<init>(Unknown Source)
> at org.eclipse.emf.ecore.resource.impl.FileURIHandlerImpl.createInputStream(FileURIHandlerImpl.java:99)
> at
> org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.createInputStream(ExtensibleURIConverterImpl.java:360)
> at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1269)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:259)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274)
> ... 78 more
>
>
> The file name '1' is strange and I don't understand why the resource creation in the repository would trigger an
> exception related to a file...
>
> Any idea, what's wrong ?
Did you change the idGenerationLocation after the first start of the repository?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: [CDO] How to import XMI resource in an empty repository [message #1219880 is a reply to message #1219858] Fri, 06 December 2013 14:07 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi Eike,

Thank you for your interest. Here some answers to your questions.
My goal is to export a source repository content, process it and import the modified result in an empty destination repository.
This "process step", I'll try to implement later on, is the reason why I choose not to use CDO's server export/import.

Concerning scaling, the idea was for the migration tool to import small groups of XMI resources / files at a time, providing there's no unresolved references at commit.

Concerning export, I did the following :
// Export each source repository resource to an XMI file
output.println("Found " + transaction.getElements().length + " resource(s)");
for (CDOResourceNode node : transaction.getElements()) {
	CDOResource r = transaction.getResource(node.getName());
	try {
		output.print("Export resource '" + ((CDOResource)r).getName() + "' : ");
		r.save(new FileOutputStream(dir + "/" + ((CDOResource)r).getName() + ".xmi"), null);
		output.println("done");
	} catch (IOException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	};
}


For import, I initially tried some kind of "reversed" operation :
// Import each XMI resource file in the destination repository
output.println(importDialog.getFileNames().length + " files selected");
for (String fileName : importDialog.getFileNames()) {
	output.print("Import resource '" + fileName.substring(0, fileName.length()-4) + "' : ");
	CDOResource r = transaction.createResource(fileName.substring(0, fileName.length()-4));
	try {
		r.load(new FileInputStream(importDialog.getFilterPath() + "/" + fileName), null);
		output.println("done");
	} catch (FileNotFoundException e) {
		output.println(e.getMessage());
		e.printStackTrace();
	} catch (IOException e) {
		output.println(e.getMessage());
		e.printStackTrace();
	}
}
output.print("Commit import : ");
try {
	transaction.commit();
...


But it leads to the following exception :
java.lang.UnsupportedOperationException
	at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.load(CDOResourceImpl.java:1058)
	at repositorymigration.handlers.ImportHandler.execute(ImportHandler.java:69)


Besides, Resource#load(inputStream, options) javadoc says load(options) is usually called directly.
So, even if this is not clear to me, I guess the method is not expected to be used the way I try to... Wink

Trying now to apply your recommandations, I just did the following :
ResourceSet rs = transaction.getResourceSet();
rs.getResourceFactoryRegistry().getExtensionToFactoryMap().put("xmi", new XMIResourceFactoryImpl()); // Just in case...
for (String fileName : importDialog.getFileNames()) {
	output.print("Import resource '" + fileName.substring(0, fileName.length()-4) + "' : ");
	File xmiFile = new File(importDialog.getFilterPath() + "/" + fileName);
	rs.getResources().add(rs.getResource(URI.createURI(xmiFile.toURI().toString()), true));
	output.println("done");
}

output.print("Commit import : ");
try {
	transaction.commit();
...


I don't get the exception anymore but nothing is commited. The destination repository remains empty...

Report message to a moderator

Re: [CDO] How to import XMI resource in an empty repository [message #1219918 is a reply to message #1219880] Fri, 06 December 2013 18:14 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 06.12.2013 15:07, schrieb Laurent Le Moux:
> Hi Eike,
>
> Thank you for your interest. Here some answers to your questions.
> My goal is to export a source repository content, process it and import the modified result in an empty destination
> repository.
> This "process step", I'll try to implement later on, is the reason why I choose not to use CDO's server export/import.
>
> Concerning scaling, the idea was for the migration tool to import small groups of XMI resources / files at a time,
> providing there's no unresolved references at commit.
Please note that you might commit objects to CDO that still have cross references to objects in an XMI resource. Even if
these cross referenced objects get "imported" later the references to them might not get adjusted later. Import is a
tricky problem. You can have a look at our resource transfer framework to get an impression. Try to drag files from the
package explorer and drop them on a COTransaction or a folder under it).

>
> Concerning export, I did the following :
>
> // Export each source repository resource to an XMI file
> output.println("Found " + transaction.getElements().length + " resource(s)");
> for (CDOResourceNode node : transaction.getElements()) {
> CDOResource r = transaction.getResource(node.getName());
> try {
> output.print("Export resource '" + ((CDOResource)r).getName() + "' : ");
> r.save(new FileOutputStream(dir + "/" + ((CDOResource)r).getName() + ".xmi"), null);
That's our own, rarely used, XMI save() method. Would be interesting whether it produces the exact same result as
copying the contents of that resource into a separate, real XMI resource.

> output.println("done");
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> };
> }
>
>
> For import, I initially tried some kind of "reversed" operation :
>
> // Import each XMI resource file in the destination repository
> output.println(importDialog.getFileNames().length + " files selected");
> for (String fileName : importDialog.getFileNames()) {
> output.print("Import resource '" + fileName.substring(0, fileName.length()-4) + "' : ");
> CDOResource r = transaction.createResource(fileName.substring(0, fileName.length()-4));
> try {
> r.load(new FileInputStream(importDialog.getFilterPath() + "/" + fileName), null);
We've only implemented the save(stream) method for our EFS implementations. CDOResource.load() is not supported.

> output.println("done");
> } catch (FileNotFoundException e) {
> output.println(e.getMessage());
> e.printStackTrace();
> } catch (IOException e) {
> output.println(e.getMessage());
> e.printStackTrace();
> }
> }
> output.print("Commit import : ");
> try {
> transaction.commit();
> ..
>
>
> But it leads to the following exception :
>
> java.lang.UnsupportedOperationException
> at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.load(CDOResourceImpl.java:1058)
> at repositorymigration.handlers.ImportHandler.execute(ImportHandler.java:69)
>
>
> Besides, Resource#load(inputStream, options) javadoc says load(options) is usually called directly.
> So, even if this is not clear to me, I guess the method is not expected to be used the way I try to... ;)
Good ;-)

>
> Trying now to apply your recommandations, I just did the following :
>
> ResourceSet rs = transaction.getResourceSet();
> rs.getResourceFactoryRegistry().getExtensionToFactoryMap().put("xmi", new XMIResourceFactoryImpl()); // Just in case...
> for (String fileName : importDialog.getFileNames()) {
> output.print("Import resource '" + fileName.substring(0, fileName.length()-4) + "' : ");
> File xmiFile = new File(importDialog.getFilterPath() + "/" + fileName);
> rs.getResources().add(rs.getResource(URI.createURI(xmiFile.toURI().toString()), true));
Better:

Resource xmiResource = rs.getResource(URI.createFileURI(xmiFile.getAbsolutePath()), true);
Resource cdoResource = transaction.createResource(fileName);
cdoResource.getContents().addAll(xmiResource.getContents());


> output.println("done");
> }
>
> output.print("Commit import : ");
> try {
> transaction.commit();
> ..
>
>
> I don't get the exception anymore but nothing is commited. The destination repository remains empty...
Try the code above.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: [CDO] How to import XMI resource in an empty repository [message #1219996 is a reply to message #1219918] Sun, 08 December 2013 19:58 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi Eike,

My comments (and questions...) below...

> Hi Eike,
>
> Thank you for your interest. Here some answers to your questions.
> My goal is to export a source repository content, process it and import the modified result in an empty destination
> repository.
> This "process step", I'll try to implement later on, is the reason why I choose not to use CDO's server export/import.
>
> Concerning scaling, the idea was for the migration tool to import small groups of XMI resources / files at a time,
> providing there's no unresolved references at commit.
>Please note that you might commit objects to CDO that still have cross references to objects in an XMI resource. Even if
>these cross referenced objects get "imported" later the references to them might not get adjusted later. Import is a
>tricky problem. You can have a look at our resource transfer framework to get an >impression. Try to drag files from the
>package explorer and drop them on a COTransaction or a folder under it).

To avoid CDO objects having cross references to objects in an XMI resource, my idea was to import first the objects with references only inside the same containing resource. Then, I could import other objects / resources with cross references to these previously imported objects.
Let's imagine a situation where two objects in distinct resources would have a cross reference to each other (some kind circular dependency), I would have to import and commit both resources at once.

Do you suggest such an approach would fail ? If so, would the reason be that there's no guarantee the import will preserve the objects « order » in the resource ?
I mean, let's assume res1#/0 (first object in res1) has a href to res2#/1 (second object in res2).
If the import of res2 in CDO could cause the object to become the first one in the resource then, of course, res1#/0 href would become invalid...

I had a quick look to your resource transfert framework but I'm not sure whether it can help in my case. Actually, I plan to use Edapt between export and import, and the idea of working on intermediate XMI resources came from reading the topic « CDO model evolution strategy ».

>
> Concerning export, I did the following :
>
> // Export each source repository resource to an XMI file
> output.println("Found " + transaction.getElements().length + " resource(s)");
> for (CDOResourceNode node : transaction.getElements()) {
> CDOResource r = transaction.getResource(node.getName());
> try {
> output.print("Export resource '" + ((CDOResource)r).getName() + "' : ");
> r.save(new FileOutputStream(dir + "/" + ((CDOResource)r).getName() + ".xmi"), null);
>That's our own, rarely used, XMI save() method. Would be interesting whether it >produces the exact same result as
>copying the contents of that resource into a separate, real XMI resource.

To answer your question, CDOResource#save method doesn't produce the same result as a copy in a separate XMI resource. The main difference appears to be that CDO uses explicit generated IDs (<invokes href="Service_OID11#L27"/>) while XMI uses relative positionning from within the resource (<invokes href="Service_OID11#/1/@defines.0"/>).
However, both fail during import with a dangling reference exception, but not on the same object...

> output.println("done");
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> };
> }
>
>
> For import, I initially tried some kind of "reversed" operation :
>
> // Import each XMI resource file in the destination repository
> output.println(importDialog.getFileNames().length + " files selected");
> for (String fileName : importDialog.getFileNames()) {
> output.print("Import resource '" + fileName.substring(0, fileName.length()-4) + "' : ");
> CDOResource r = transaction.createResource(fileName.substring(0, fileName.length()-4));
> try {
> r.load(new FileInputStream(importDialog.getFilterPath() + "/" + fileName), null);
>We've only implemented the save(stream) method for our EFS implementations. >CDOResource.load() is not supported.

> output.println("done");
> } catch (FileNotFoundException e) {
> output.println(e.getMessage());
> e.printStackTrace();
> } catch (IOException e) {
> output.println(e.getMessage());
> e.printStackTrace();
> }
> }
> output.print("Commit import : ");
> try {
> transaction.commit();
> ..
>
>
> But it leads to the following exception :
>
> java.lang.UnsupportedOperationException
> at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.load(CDOResourceImpl.java:1058)
> at repositorymigration.handlers.ImportHandler.execute(ImportHandler.java:69)
>
>
> Besides, Resource#load(inputStream, options) javadoc says load(options) is usually called directly.
> So, even if this is not clear to me, I guess the method is not expected to be used the way I try to... Wink
>Good Wink

>
> Trying now to apply your recommandations, I just did the following :
>
> ResourceSet rs = transaction.getResourceSet();
> rs.getResourceFactoryRegistry().getExtensionToFactoryMap().put("xmi", new XMIResourceFactoryImpl()); // Just in case...
> for (String fileName : importDialog.getFileNames()) {
> output.print("Import resource '" + fileName.substring(0, fileName.length()-4) + "' : ");
> File xmiFile = new File(importDialog.getFilterPath() + "/" + fileName);
> rs.getResources().add(rs.getResource(URI.createURI(xmiFile.toURI().toString()), true));
>Better:
>
> Resource xmiResource = >rs.getResource(URI.createFileURI(xmiFile.getAbsolutePath()), true);
> Resource cdoResource = transaction.createResource(fileName);
> cdoResource.getContents().addAll(xmiResource.getContents());


> output.println("done");
> }
>
> output.print("Commit import : ");
> try {
> transaction.commit();
> ..
>
>
> I don't get the exception anymore but nothing is commited. The destination repository remains empty...
>Try the code above.

I tried but I still get the dangling reference exception.
I get confused because I tried to load only one XMI resource file with no cross reference to another resource.
Moreover, my resource contains an object and its associated Graphiti diagram. If I remove the diagram, the remaining object o1 is imported without problem...
But, if I then try to import another resource containing an object o2 with a cross reference to the previously imported and commited o1, I get the dangling reference exception that says the referenced o1 is not contained in a resource... !?
This brings me back to my first asumption about object ordering in resources...
Could then the problem be qualified as an « Invalid reference exception » ?

>Cheers
>/Eike
>
>----
>http://www.esc-net.de
>http://thegordian.blogspot.com
>http://twitter.com/eikestepper

Cheers,

Laurent

Report message to a moderator

Re: [CDO] How to import XMI resource in an empty repository [message #1220933 is a reply to message #1219996] Mon, 16 December 2013 08:41 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi again,

Just a message to close this topic. I finally found a way to migrate my CDO resources.

I first migrate the ones with no reference outside the scope of each processed resource. I create the destination resource, the new target objects (especially if the migration is due to an ecore model evolution) and map the source objects to the target ones.

If an object is to be referenced in another not yet migrated resource, I also create a "migration meta data" object to store the source object CDO ID (as a string) and a reference to the newly created target object.

Each created destination resource is commited in order for the solution to scale well Smile

Then, I'm ready to migrate the other kind of resources, the ones with references outside the scope of the processed resource. At this point, there should only be references to already migrated resources.

Basically, the same processing takes place except that, when such a reference occurs, it must be reconciliated with the corresponding target object in the destination repository.
One must look for the previously created meta data with the store CDO ID corresponding to the referenced object and update the reference with the corresponding and also stored target object one.

After all resources have been successfully migrated, we can get rid of the useless meta data that happens to be stored in a dedicated resource Wink by simply deleting this temporary resource.

Kind regards,

Laurent

Report message to a moderator

Re: [CDO] How to import XMI resource in an empty repository [message #1220936 is a reply to message #1220933] Mon, 16 December 2013 08:54 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 16.12.2013 09:41, schrieb Laurent Le Moux:
> Hi again,
>
> Just a message to close this topic. I finally found a way to migrate my CDO resources.
>
> I first migrate the ones with no reference outside the scope of each processed resource. I create the destination
> resource, the new target objects (especially if the migration is due to an ecore model evolution) and map the source
> objects to the target ones.
>
> If an object is to be referenced in another not yet migrated resource, I also create a "migration meta data" object to
> store the source object CDO ID (as a string) and a reference to the newly created target object.
>
> Each created destination resource is commited in order for the solution to scale well :)
> Then, I'm ready to migrate the other kind of resources, the ones with references outside the scope of the processed
> resource. At this point, there should only be references to already migrated resources.
>
> Basically, the same processing takes place except that, when such a reference occurs, it must be reconciliated with
> the corresponding target object in the destination repository.
> One must look for the previously created meta data with the store CDO ID corresponding to the referenced object and
> update the reference with the corresponding and also stored target object one.
>
> After all resources have been successfully migrated, we can get rid of the useless meta data that happens to be stored
> in a dedicated resource ;) by simply deleting this temporary resource.
That's a good description of areasonable approach. Thanks ;-)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Previous Topic:[Xcore] Data type create and convert access in code?
Next Topic:Automatically generate EMF, Help!
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Apr 25 16:08:30 GMT 2024

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

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

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly