| Re: Cannot modify resource set when changing a reference to another model in the platform [message #667972] |
Tue, 03 May 2011 07:29 |
 Jevon 
Messages: 164
Registered: July 2009 |
Senior Member |
|
|
Hi all,
Thanks for your advice Ed. After much debugging I have finally managed
to put together a solution to this problem. Essentially, I disable proxy
resolving while a diagram is loading:
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public XSDSimpleTypeDefinition getDefinition() {
if (definition != null && definition.eIsProxy() &&
!EXSDDataTypeTransactionHandler.getInstance().isLoadingDiagr am())
return definition;
// ...
}
EXSDDataTypeTransactionHandler is a singleton class, which is toggled
within the generated XXXDocumentProvider by GMF. Once the diagram has
been loaded, it is necessary to resolve all of the outstanding
references, which has to be done within the Command stack of the
TransactionalEditingDomain for the diagram:
final EObject diagramObject = diagramDocument.getDiagram().getElement();
Command command = new RecordingCommand(domain,
"Resolve all outstanding cross-references") {
@Override
protected void doExecute() {
EcoreUtil.resolveAll(diagramObject.eResource()
.getResourceSet());
}
};
domain.getCommandStack().execute(command);
Like all of my other modifications to generated EMF and GMF code, these
modifications can be achieved using dynamic templates:
http://code.google.com/p/iaml/source/detail?r=2784
Hope this helps someone else, I'm glad to have finally come up with a
solution. Any thoughts or feedback would be appreciated.
Jevon
Ed Merks wrote:
> Jevon,
>
> Comments below.
>
> Jevon Wright wrote:
>> Hi,
>>
>> I am having difficulty in getting a GMF editor to use references from
>> another EMF model in platform:/plugin/. I posted this question on the
>> GMF newsgroup but I think it is more an EMF question instead.
>>
>> I've modified the editor to replace bundleentry://../ with
>> platform:/plugin, so that the serialised model instances are portable.
>> This has worked before for models defined in my own bundles, but isn't
>> working with the Eclipse XSD bundle.
>>
>> The diagram editor can create and save models fine, but when I try to
>> re-open an existing diagram (or initialise a new diagram) and try to
>> change the reference (using the dropdown box in 'Properties'), the
>> editor crashes with a "Cannot modify resource set without a write
>> transaction" (stacktrace below).
>>
>> It looks like GMF/EMF is trying to modify the XSD model outside the
>> scope of a transaction. Do I need to initialise the XSD model first?
>> How am I supposed to do this? It seems that EMF is designed to load
>> the model on-demand.
>>
>> Thanks
>> Jevon
>>
>> ---
>> Stacktrace:
>>
>> java.lang.IllegalStateException: Cannot modify resource set without a
>> write transaction
>> at
>> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.a ssertWriting(TransactionChangeRecorder.java:348)
>>
>> at
>> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.a ppendNotification(TransactionChangeRecorder.java:302)
>>
>> at
>> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.p rocessObjectNotification(TransactionChangeRecorder.java:284)
>>
>> at
>> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.n otifyChanged(TransactionChangeRecorder.java:240)
>>
>> at
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:280)
>>
>> at
>> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1159)
>>
>> at
>> org.eclipse.emf.ecore.util.EcoreEList.dispatchNotification(E coreEList.java:255)
>>
>> at
>> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllU nique(NotifyingListImpl.java:463)
>>
>> at
>> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllU nique(NotifyingListImpl.java:406)
>>
>> at
>> org.eclipse.emf.common.util.AbstractEList.addAll(AbstractELi st.java:374)
>> at
>> org.eclipse.xsd.impl.XSDSimpleTypeDefinitionImpl.createFunda mentalFacets(XSDSimpleTypeDefinitionImpl.java:3019)
>>
> These are derived features that are computed on demand and that
> computation *stores the result* in a way that produces a change
> notification, so for the transaction framework, it will look like a
> write transaction.
>
> protected XSDCardinalityFacet cardinalityFacet;
> public XSDCardinalityFacet getCardinalityFacet()
> {
> if (cardinalityFacet == null)
> {
> createFundamentalFacets();
> }
> return cardinalityFacet;
> }
>
> protected void createFundamentalFacets()
> {
> List<XSDFundamentalFacet> theFundamentalFacets = getFundamentalFacets();
> boundedFacet = getXSDFactory().createXSDBoundedFacet();
> cardinalityFacet = getXSDFactory().createXSDCardinalityFacet();
> numericFacet = getXSDFactory().createXSDNumericFacet();
> orderedFacet = getXSDFactory().createXSDOrderedFacet();
> List<XSDFundamentalFacet> list = new ArrayList<XSDFundamentalFacet>(4);
> list.add(boundedFacet);
> list.add(cardinalityFacet);
> list.add(numericFacet);
> list.add(orderedFacet);
> * theFundamentalFacets.addAll(list);*
> }
>
> I'm not sure what to suggest to avoid this problem. You could traverse
> the whole model (Resource.getAllContents() and using
> EObject.eCrossReferences()) when it's first loaded to avoid this problem
> later).
>> at
>> org.eclipse.xsd.impl.XSDSimpleTypeDefinitionImpl.getCardinal ityFacet(XSDSimpleTypeDefinitionImpl.java:2982)
>>
>> at
>> org.eclipse.xsd.impl.XSDSimpleTypeDefinitionImpl.eGet(XSDSim pleTypeDefinitionImpl.java:2581)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1013)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1005)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1000)
>>
>> at
>> org.eclipse.emf.edit.provider.ItemPropertyDescriptor.collect ReachableObjectsOfType(ItemPropertyDescriptor.java:940)
>>
>> at
>> org.eclipse.emf.edit.provider.ItemPropertyDescriptor.getReac hableObjectsOfType(ItemPropertyDescriptor.java:883)
>>
>> at
>> org.eclipse.emf.edit.provider.ItemPropertyDescriptor.getComb oBoxObjects(ItemPropertyDescriptor.java:806)
>>
>> at
>> org.eclipse.emf.edit.provider.ItemPropertyDescriptor.getChoi ceOfValues(ItemPropertyDescriptor.java:1473)
>>
>> at
>> org.eclipse.emf.edit.ui.provider.PropertyDescriptor.createPr opertyEditor(PropertyDescriptor.java:428)
>>
>> at
>> org.openiaml.model.diagram.sheet.IamlPropertySection$IamlCus tomPropertyDescriptor.createPropertyEditor(IamlPropertySecti on.java:148)
>>
>> at
>> org.eclipse.gmf.runtime.emf.ui.properties.sections.PropertyS heetEntry.getEditor(PropertySheetEntry.java:365)
>>
>> at
>> org.eclipse.ui.views.properties.PropertySheetViewer.activate CellEditor(PropertySheetViewer.java:163)
>>
>> at
>> org.eclipse.ui.views.properties.PropertySheetViewer.handleSe lect(PropertySheetViewer.java:727)
>>
>> at
>> org.eclipse.ui.views.properties.PropertySheetViewer.access$8 (PropertySheetViewer.java:707)
>>
>> at
>> org.eclipse.ui.views.properties.PropertySheetViewer$6.mouseD own(PropertySheetViewer.java:816)
>>
>> at
>> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:179)
>> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :84)
>> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
>> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3910)
>> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3503)
>> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2405)
>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
>> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 21)
>> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
>> at
>> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:332)
>>
>> at
>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:493)
>>
>> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>> at
>> org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:113)
>>
>> at
>> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:194)
>>
>> 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(EclipseS tarter.java:368)
>>
>> at
>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
>>
>> 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: 559)
>> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
>> at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
>> at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
|
|
|
Powered by
FUDForum. Page generated in 0.03683 seconds
] 
Search
Help
Register
Login
Home
