Community
Participate
Working Groups
Build Identifier: URI of the resource [uri-of-ecore-file] does not match the nsURI [ns-of-eobject-to-create] of the top-level package java.lang.IllegalStateException: URI of the resource [uri-of-ecore-file] does not match the nsURI [ns-of-eobject-to-create] of the top-level package at org.eclipse.emf.cdo.common.model.CDOModelUtil.checkCrossResourceURIs(CDOModelUtil.java:503) at org.eclipse.emf.cdo.common.model.CDOModelUtil.writePackage(CDOModelUtil.java:433) at org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.write(CDOPackageUnitImpl.java:267) at org.eclipse.emf.cdo.internal.common.protocol.CDODataOutputImpl.writeCDOPackageUnit(CDODataOutputImpl.java:80) at org.eclipse.emf.cdo.internal.net4j.protocol.CommitTransactionRequest.requestingCommit(CommitTransactionRequest.java:183) at org.eclipse.emf.cdo.internal.net4j.protocol.CommitTransactionRequest.requesting(CommitTransactionRequest.java:154) at org.eclipse.emf.cdo.internal.net4j.protocol.CommitTransactionRequest.requesting(CommitTransactionRequest.java:129) at org.eclipse.net4j.signal.RequestWithMonitoring.requesting(RequestWithMonitoring.java:163) at org.eclipse.net4j.signal.RequestWithConfirmation.doExtendedOutput(RequestWithConfirmation.java:117) at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:286) at org.eclipse.net4j.signal.RequestWithConfirmation.doExecute(RequestWithConfirmation.java:102) at org.eclipse.net4j.signal.RequestWithMonitoring.doExecute(RequestWithMonitoring.java:233) at org.eclipse.net4j.signal.SignalActor.execute(SignalActor.java:51) at org.eclipse.net4j.signal.Signal.runSync(Signal.java:241) at org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalProtocol.java:396) at org.eclipse.net4j.signal.RequestWithConfirmation.doSend(RequestWithConfirmation.java:87) at org.eclipse.net4j.signal.RequestWithConfirmation.send(RequestWithConfirmation.java:73) at org.eclipse.net4j.signal.RequestWithMonitoring.send(RequestWithMonitoring.java:108) at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:412) at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.commitTransaction(CDOClientProtocol.java:294) at org.eclipse.emf.internal.cdo.session.DelegatingSessionProtocol.commitTransaction(DelegatingSessionProtocol.java:261) at org.eclipse.emf.internal.cdo.transaction.CDOSingleTransactionStrategyImpl.commit(CDOSingleTransactionStrategyImpl.java:77) at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1035) at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOResourceImpl.java:899) at org.eclipse.emf.cdo.internal.ui.editor.CDOEditor$19.run(CDOEditor.java:1769) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Reproducible: Always Steps to Reproduce: 1. Define two distinct packages (different namespaces) 2. Define a new type in each package 3. Let TypeA from PackageA reference TypeB from PackageB (e.g. as containment/feature reference) 4. Create new object using the CDO UI 5. Commit changes
Note: Each package is located in its own ecore file.
Caspar, since the exception comes from CDOModelUtil.checkCrossResourceURIs(), can you please have a look at this?
This isn't a bug. The check correctly identifies a problem. A dynamic package must be contained in a resource that is designated by a URI that matches the package's nsURI. (Or if the package is not a top-level package, by a URI that matches the URI of the package's containing top-level package.) By default, if you load up a resource from a file, the URI of the resource will be the file's location URI. Before you can use the package loaded in the resource with CDO, you need to set the resource's URI correctly (as specified in the preceding paragraph) by calling Resource.setURI(URI). In case you actually want to know WHY this is necessary: it is because the packages are serialized to XML using EMF's default serialization mechanism, which uses the URI of the containing resource for any cross-resource reference. But fileURI's are meaningless on the server side; only namespace URI's are meaningful. Therefore, before transmitting the packages, CDO ensures that the resource URI's match the nsURI's.
Reopening to improve exception message
Improved error message that describes the solution: URI of the resource (%s) does not match the nsURI (%s) of the top-level package; this can be fixed by calling Resource.setURI(URI) after loading the packages, or by configuring a URI mapping from nsURI's to location URI's before loading the packages, and then loading them with their nsURI's. Committed to HEAD
Does the CDO UI provides that step, i.e. setting the URI on the resource?
Though, if I use the CDO UI to create a new object, then why should I care to set the correct nsURI for that object? I.e. the CDO UI knows what nsURI to use, why does it not do it itself?
(In reply to comment #7) > Though, if I use the CDO UI to create a new object, then why should I care to > set the correct nsURI for that object? I.e. the CDO UI knows what nsURI to use, > why does it not do it itself? I tend to agree with you but want to discuss that with Caspar tomorrow...
I suppose if you use the CDO UI to load those packages, then the UI should set the URI's as needed, yes. But I never use nor develop the UI, so I'm not sure I'm the right guy to address that..
After some more internal discussion we decided to automatically adjust the resource URIs of new packages upon registration time in the core...
Created attachment 186473 [details] Patch v1 This seems to fix it. I must say I was a little surprised because I tested this with two related ecore files. I'm not yet sure how CDO has found the referenced ecore file after I replaced the resource URI of the referencing file. I guess all the resolution happens already when loading the first file, which would be okay... Caspar can you review it?
Created attachment 186474 [details] Patch v2 - adjustment at serialization time
All attempts to adjust the resource URIs lead to issues elsewhere. Note for me: see bug 303466. Erdal, are you happy for now with generated models or is it urgent to address this dynamic model issue immediately?
Created attachment 186612 [details] Patch v3
I guess I will have to redeploy the generated model each time I want to test it. This is not convenient, but OK as a workaround. Anyways, thanks for your support!
Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems. Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!!
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Nothing in patch v3 applies to master anymore. Please reopen this bug if you feel a need.
The issue is still relevant. I tried to create a model and add an OCL expression element to the created model. The OCL expression elements are contained in a subpackage of the OCL package. Even when doing this via the UI, I get the exception mentioned by Erdal. I tried to apply the patch v3 but that leads to a stack overflow. Are there any plans to fix this?
