| Re: Profile DataType uml editor [message #626628] |
Mon, 26 May 2008 14:57 |
 Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Cam,
Comments below.
Cam Fou wrote:
> Re, thanks for so fast answer !!!
> I just try and the resolve value is always set to true during document
> loading ...
When it's true, containment proxies will resolve and that will look like
a model change to the transaction framework. So it seems bad it should
be this way during loading.
> that means the proxy resolution wasn't done correctly ?
It's being done correctly but it shouldn't be done at all during loading.
> Why trying to write ?
When a containment proxy is resolve, the proxy needs to be removed from
the container and hence the proxy's container reference needs to be
cleared, which looks like a write change.
> What is the difference with the multiple DataType attributes ?
I don't know enough about UML to understand why that's related. It
seems unrelated to the stack trace I'm seeing.
I've added the UML and GMF newsgroups to the reply, because I don't
understand who is responsible for creating the cross reference adapter
that's doing resolving...
> Thanks,
>
> Camille Foubert
> cfoubert@prophessi.com
>
> Ed Merks a écrit :
>> Cam,
>>
>> It looks to me like a cross reference adapter is causing a
>> containment proxy to be resolved. Can you debug this to see if
>> CrossReferenceAdapter.resolve is false when you get here:
>>
>> at
>> org.eclipse.gmf.runtime.emf.core.util.CrossReferenceAdapter. setTarget(CrossReferenceAdapter.java:378)
>>
>>
>>
>> Cam Fou wrote:
>>> Hello, I have a problem when I try to re-open an uml model.
>>> I have applied a profile on my model and I have set a lots of
>>> properties before to close it. Simple and arrays of PrimitiveType,
>>> simple and arrays of DataType. If I use a DataType for first level
>>> attribute it works fine, I can re-open the document and access my
>>> datas. If I use simple DataType attribute of a DataType field
>>> (higher than 1st level) I can't re-open the uml document. While with
>>> multiple DataType attribute of a DataType field it works fine. I
>>> added the Exception trace to my message. The ResourceImpl.load()
>>> method was invoked with : new HashMap() argument.
>>> Maybe somebody can explain me why the uml document loader try to
>>> write on my model when loading document. It works fine with
>>> multiples attribute, not with simples... Isn't a bug?
>>> Thanks
>>>
>>> Camille Foubert
>>>
>>> java.lang.IllegalStateException: Cannot modify resource set without
>>> a write transaction
>>> at
>>> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.a ssertWriting(TransactionChangeRecorder.java:338)
>>>
>>> at
>>> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.a ppendNotification(TransactionChangeRecorder.java:300)
>>>
>>> at
>>> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.p rocessObjectNotification(TransactionChangeRecorder.java:282)
>>>
>>> at
>>> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.n otifyChanged(TransactionChangeRecorder.java:238)
>>>
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:247)
>>>
>>> at
>>> org.eclipse.emf.common.notify.impl.NotificationChainImpl.dis patch(NotificationChainImpl.java:104)
>>>
>>> at
>>> org.eclipse.emf.common.notify.impl.NotificationChainImpl.dis patch(NotificationChainImpl.java:92)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSe ttingDelegateSingleEObject.dynamicGet(EStructuralFeatureImpl .java:2333)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1027)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1012)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1004)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:409)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:697)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:674)
>>>
>>> at
>>> org.eclipse.gmf.runtime.emf.core.util.CrossReferenceAdapter. setTarget(CrossReferenceAdapter.java:378)
>>>
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>>>
>>> at
>>> org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:646)
>>> at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:6 26)
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:129)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.selfAdapt( ECrossReferenceAdapter.java:510)
>>>
>>> at
>>> org.eclipse.gmf.runtime.emf.core.util.CrossReferenceAdapter. selfAdapt(CrossReferenceAdapter.java:92)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.notifyChan ged(ECrossReferenceAdapter.java:430)
>>>
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:247)
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1434)
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1210)
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04580 seconds
] 
Search
Help
Register
Login
Home
