| ECrossReferenceAdapter ClassCastException -- global/resourceSet-spec. Package Registry? [message #496026] |
Sat, 07 November 2009 05:48  |
 Joel Greenyer
Messages: 97
Registered: July 2009 |
Member |
|
|
Hi,
in my application, I have to avoid confusions between different instances of the same model (...dynamic model instances
have to work with the instances of generated code... that was discussed some time ago in a thread "relfection model
instance problem")
I solve this problem by modifying the entries in the package registry to control that, where code is generated for a
model, these instances are used.
I tried modifying the entries in global package registry, or the package registry of the resourceSet that I use for
loading all the resources--both works, basically. Using the global package registry is not so nice, because it confuses
other editors. So, I figure that it is a good idea to use the resourceSet-specific package registry instead.
However, in this case, I get a ClassCastException in a ECrossReferenceAdapter that I add to the resourceSet. Somehow it
seems to expect a dynamic instance where it shouldn't (see exception trace below). Why is that?
I hope I could explain my problem... Thanks for helping
Joel
java.lang.ClassCastException: The value of type 'class beispiel.model.ctools.impl.ProjectImpl' must be of type
'org.eclipse.emf.ecore.impl.EClassImpl@1ace0b2 (name: Project) (instanceClassName: null) (abstract: false, interface:
false)'
at
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSe ttingDelegateSingleEObject.dynamicGet(EStructuralFeatureImpl .java:2318)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1029)
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.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:409)
at org.eclipse.emf.ecore.util.EcoreUtil$CrossReferencer.handleC rossReference(EcoreUtil.java:1692)
at org.eclipse.emf.ecore.util.ECrossReferenceAdapter$InverseCro ssReferencer.add(ECrossReferenceAdapter.java:146)
at org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:692)
at org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:674)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
at org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
at org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:718)
at org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:678)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
at org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
at org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:732)
at org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:682)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
at
de.upb.swt.qvt.tgg.interpreter.impl.TransformationProcessorI mpl.performTransformation(TransformationProcessorImpl.java:3 24)
at de.upb.swt.qvt.tgg.interpreter.impl.InterpreterImpl.performT ransformation(InterpreterImpl.java:278)
at de.upb.swt.qvt.tgg.interpreter.ui.popup.actions.StartInterpr eterAction$1.run(StartInterpreterAction.java:82)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
|
|
|
| Re: ECrossReferenceAdapter ClassCastException -- global/resourceSet-spec. Package Registry? [message #496035 is a reply to message #496026 ] |
Sat, 07 November 2009 08:10  |
Ed Merks
Messages: 15894
Registered: July 2009 |
Senior Member |
|
|
Joel,
If you look at it in the debugger, no doubt you'll find you have a
generated instance where a dynamic one is expected. I can't guess why,
but it ought to have been impossible for the objects to get into this
state in the first place. Modifying generating models could certainly
lead to this...
Joel Greenyer wrote:
> Hi,
> in my application, I have to avoid confusions between different
> instances of the same model (...dynamic model instances have to work
> with the instances of generated code... that was discussed some time
> ago in a thread "relfection model instance problem")
>
> I solve this problem by modifying the entries in the package registry
> to control that, where code is generated for a model, these instances
> are used.
>
> I tried modifying the entries in global package registry, or the
> package registry of the resourceSet that I use for loading all the
> resources--both works, basically. Using the global package registry is
> not so nice, because it confuses other editors. So, I figure that it
> is a good idea to use the resourceSet-specific package registry instead.
>
> However, in this case, I get a ClassCastException in a
> ECrossReferenceAdapter that I add to the resourceSet. Somehow it seems
> to expect a dynamic instance where it shouldn't (see exception trace
> below). Why is that?
>
> I hope I could explain my problem... Thanks for helping
>
> Joel
>
>
>
> java.lang.ClassCastException: The value of type 'class
> beispiel.model.ctools.impl.ProjectImpl' must be of type
> 'org.eclipse.emf.ecore.impl.EClassImpl@1ace0b2 (name: Project)
> (instanceClassName: null) (abstract: false, interface: false)'
> at
> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSe ttingDelegateSingleEObject.dynamicGet(EStructuralFeatureImpl .java:2318)
>
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1029)
>
> 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.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:409)
>
> at
> org.eclipse.emf.ecore.util.EcoreUtil$CrossReferencer.handleC rossReference(EcoreUtil.java:1692)
>
> at
> org.eclipse.emf.ecore.util.ECrossReferenceAdapter$InverseCro ssReferencer.add(ECrossReferenceAdapter.java:146)
>
> at
> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:692)
>
> at
> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:674)
>
> at
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>
> at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
> at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
> at
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
>
> at
> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
>
> at
> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:718)
>
> at
> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:678)
>
> at
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>
> at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
> at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
> at
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
>
> at
> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
>
> at
> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:732)
>
> at
> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:682)
>
> at
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>
> at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
> at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
> at
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
>
> at
> de.upb.swt.qvt.tgg.interpreter.impl.TransformationProcessorI mpl.performTransformation(TransformationProcessorImpl.java:3 24)
>
> at
> de.upb.swt.qvt.tgg.interpreter.impl.InterpreterImpl.performT ransformation(InterpreterImpl.java:278)
>
> at
> de.upb.swt.qvt.tgg.interpreter.ui.popup.actions.StartInterpr eterAction$1.run(StartInterpreterAction.java:82)
>
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
|
|
|
| Re: ECrossReferenceAdapter ClassCastException -- global/resourceSet-spec. Package Registry? [message #496061 is a reply to message #496035 ] |
Sat, 07 November 2009 13:03 |
Joel Greenyer
Messages: 97
Registered: July 2009 |
Member |
|
|
Hi Ed,
comments below:
Ed Merks wrote:
> Joel,
>
> If you look at it in the debugger, no doubt you'll find you have a
> generated instance where a dynamic one is expected.
Yes, that's what the Exception says, right?
> I can't guess why,
> but it ought to have been impossible for the objects to get into this
> state in the first place.
Impossible... what do you mean?
The problem the following: I have a model which stores the configuration of a model transformation (m2m, like QVT-R).
This configuration consists of
(a) references to the (instance) model(s) to be transformed
(b) references to a set of transformation rules, which again reference the (meta) models of the instance models that
ought to be transformed
When I specify a transformation, I import the plug-ins of the source and target (meta) models into the workspace, such
that the transformation rules and a trace (meta) model reference the .ecore model files in those plug-ins (in the XMI, I
have references like "../../some.source.model.plugin/model/sourcemodel.ecore"). That is important in case that I want to
generate code from the trace model once the transformation is ready to be deployed.
That means that, because the transformation rules + trace model reference the ecore model files in the local workspace,
dynamic instances of the classes in these models are created by default when I load the transformation rules and the
trace model. On the other hand, when I load the instance models that ought to be transformed, the generated classes are
instantiated.
To overcome this inconsistency, I add entries in the resourceSet's package registry as you suggested in your (very
helpful) post "Re: relfection model instance problem" (06.04.2006)
That worked for some time, but now I introduced the ECrossReferenceAdapter, that apparently is not impressed by the
additional entries in the resourceSet's package registry. The ECrossReferenceAdapter is happy, however, when I modify
the entries in the global package registry. Using the global registry is just not so cool, because the modification are
valid not only for the transformation run. That is a problem when I want to edit the transformation rules after a
transformation run: then the reference to the copies of the source/target (meta) model .ecore files in the local
workspace are changed, for example, from "../../some.source.model.plugin/model/sourcemodel.ecore" to
"http://some.source.model.plugin.sourcemodel".
Any idea why adding entries in the resourceSet's package registry is not enough? Or what I should watch out for when
debugging?
Thanks
Joel
> Modifying generating models could certainly
> lead to this...
>
>
> Joel Greenyer wrote:
>> Hi,
>> in my application, I have to avoid confusions between different
>> instances of the same model (...dynamic model instances have to work
>> with the instances of generated code... that was discussed some time
>> ago in a thread "relfection model instance problem")
>>
>> I solve this problem by modifying the entries in the package registry
>> to control that, where code is generated for a model, these instances
>> are used.
>>
>> I tried modifying the entries in global package registry, or the
>> package registry of the resourceSet that I use for loading all the
>> resources--both works, basically. Using the global package registry is
>> not so nice, because it confuses other editors. So, I figure that it
>> is a good idea to use the resourceSet-specific package registry instead.
>>
>> However, in this case, I get a ClassCastException in a
>> ECrossReferenceAdapter that I add to the resourceSet. Somehow it seems
>> to expect a dynamic instance where it shouldn't (see exception trace
>> below). Why is that?
>>
>> I hope I could explain my problem... Thanks for helping
>>
>> Joel
>>
>>
>>
>> java.lang.ClassCastException: The value of type 'class
>> beispiel.model.ctools.impl.ProjectImpl' must be of type
>> 'org.eclipse.emf.ecore.impl.EClassImpl@1ace0b2 (name: Project)
>> (instanceClassName: null) (abstract: false, interface: false)'
>> at
>> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSe ttingDelegateSingleEObject.dynamicGet(EStructuralFeatureImpl .java:2318)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1029)
>>
>> 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.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:409)
>>
>> at
>> org.eclipse.emf.ecore.util.EcoreUtil$CrossReferencer.handleC rossReference(EcoreUtil.java:1692)
>>
>> at
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter$InverseCro ssReferencer.add(ECrossReferenceAdapter.java:146)
>>
>> at
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:692)
>>
>> at
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:674)
>>
>> at
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>>
>> at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
>> at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
>> at
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
>>
>> at
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
>>
>> at
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:718)
>>
>> at
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:678)
>>
>> at
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>>
>> at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
>> at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
>> at
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
>>
>> at
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
>>
>> at
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:732)
>>
>> at
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:682)
>>
>> at
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>>
>> at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
>> at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
>> at
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
>>
>> at
>> de.upb.swt.qvt.tgg.interpreter.impl.TransformationProcessorI mpl.performTransformation(TransformationProcessorImpl.java:3 24)
>>
>> at
>> de.upb.swt.qvt.tgg.interpreter.impl.InterpreterImpl.performT ransformation(InterpreterImpl.java:278)
>>
>> at
>> de.upb.swt.qvt.tgg.interpreter.ui.popup.actions.StartInterpr eterAction$1.run(StartInterpreterAction.java:82)
>>
>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
|
|
|
| Re: ECrossReferenceAdapter ClassCastException -- global/resourceSet-spec. Package Registry? [message #496076 is a reply to message #496061 ] |
Sat, 07 November 2009 21:30 |
Ed Merks
Messages: 15894
Registered: July 2009 |
Senior Member |
|
|
Joel,
Comments below.
Joel Greenyer wrote:
> Hi Ed,
> comments below:
>
> Ed Merks wrote:
>> Joel,
>>
>> If you look at it in the debugger, no doubt you'll find you have a
>> generated instance where a dynamic one is expected.
>
> Yes, that's what the Exception says, right?
Yep.
>
>> I can't guess why, but it ought to have been impossible for the
>> objects to get into this state in the first place.
>
> Impossible... what do you mean?
One would expect a class cast exception when the value is set, not just
when the value is fetched...
> The problem the following: I have a model which stores the
> configuration of a model transformation (m2m, like QVT-R). This
> configuration consists of
> (a) references to the (instance) model(s) to be transformed
> (b) references to a set of transformation rules, which again reference
> the (meta) models of the instance models that ought to be transformed
>
> When I specify a transformation, I import the plug-ins of the source
> and target (meta) models into the workspace, such that the
> transformation rules and a trace (meta) model reference the .ecore
> model files in those plug-ins (in the XMI, I have references like
> "../../some.source.model.plugin/model/sourcemodel.ecore").
References to the serialized development time instance...
> That is important in case that I want to generate code from the trace
> model once the transformation is ready to be deployed.
> That means that, because the transformation rules + trace model
> reference the ecore model files in the local workspace, dynamic
> instances of the classes in these models are created by default when I
> load the transformation rules and the trace model. On the other hand,
> when I load the instance models that ought to be transformed, the
> generated classes are instantiated.
>
> To overcome this inconsistency, I add entries in the resourceSet's
> package registry as you suggested in your (very helpful) post "Re:
> relfection model instance problem" (06.04.2006)
>
> That worked for some time, but now I introduced the
> ECrossReferenceAdapter, that apparently is not impressed by the
> additional entries in the resourceSet's package registry.
The ECrossReferenceAdapter makes no use of the package registry. It's
unimpressed by the state of the instance, not by the the entries in the
resource set's package registry.
> The ECrossReferenceAdapter is happy, however, when I modify the
> entries in the global package registry.
Most likely this influences the transformation engine...
> Using the global registry is just not so cool, because the
> modification are valid not only for the transformation run.
Sounds like a transformation issue...
> That is a problem when I want to edit the transformation rules after a
> transformation run: then the reference to the copies of the
> source/target (meta) model .ecore files in the local workspace are
> changed, for example, from
> "../../some.source.model.plugin/model/sourcemodel.ecore" to
> "http://some.source.model.plugin.sourcemodel".
>
> Any idea why adding entries in the resourceSet's package registry is
> not enough?
It sounds like a transformation question.
> Or what I should watch out for when debugging?
I'm not sure what to suggest...
>
> Thanks
>
> Joel
>
>
>> Modifying generating models could certainly lead to this...
>>
>>
>> Joel Greenyer wrote:
>>> Hi,
>>> in my application, I have to avoid confusions between different
>>> instances of the same model (...dynamic model instances have to work
>>> with the instances of generated code... that was discussed some time
>>> ago in a thread "relfection model instance problem")
>>>
>>> I solve this problem by modifying the entries in the package
>>> registry to control that, where code is generated for a model, these
>>> instances are used.
>>>
>>> I tried modifying the entries in global package registry, or the
>>> package registry of the resourceSet that I use for loading all the
>>> resources--both works, basically. Using the global package registry
>>> is not so nice, because it confuses other editors. So, I figure that
>>> it is a good idea to use the resourceSet-specific package registry
>>> instead.
>>>
>>> However, in this case, I get a ClassCastException in a
>>> ECrossReferenceAdapter that I add to the resourceSet. Somehow it
>>> seems to expect a dynamic instance where it shouldn't (see exception
>>> trace below). Why is that?
>>>
>>> I hope I could explain my problem... Thanks for helping
>>>
>>> Joel
>>>
>>>
>>>
>>> java.lang.ClassCastException: The value of type 'class
>>> beispiel.model.ctools.impl.ProjectImpl' must be of type
>>> 'org.eclipse.emf.ecore.impl.EClassImpl@1ace0b2 (name: Project)
>>> (instanceClassName: null) (abstract: false, interface: false)'
>>> at
>>> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSe ttingDelegateSingleEObject.dynamicGet(EStructuralFeatureImpl .java:2318)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1029)
>>>
>>> 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.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:409)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.EcoreUtil$CrossReferencer.handleC rossReference(EcoreUtil.java:1692)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter$InverseCro ssReferencer.add(ECrossReferenceAdapter.java:146)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:692)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:674)
>>>
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>>>
>>> at
>>> org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
>>> at
>>> org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:718)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:678)
>>>
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>>>
>>> at
>>> org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
>>> at
>>> org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:732)
>>>
>>> at
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:682)
>>>
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>>>
>>> at
>>> org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:425)
>>> at
>>> org.eclipse.emf.common.util.AbstractEList.add(AbstractEList. java:307)
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:142)
>>>
>>> at
>>> de.upb.swt.qvt.tgg.interpreter.impl.TransformationProcessorI mpl.performTransformation(TransformationProcessorImpl.java:3 24)
>>>
>>> at
>>> de.upb.swt.qvt.tgg.interpreter.impl.InterpreterImpl.performT ransformation(InterpreterImpl.java:278)
>>>
>>> at
>>> de.upb.swt.qvt.tgg.interpreter.ui.popup.actions.StartInterpr eterAction$1.run(StartInterpreterAction.java:82)
>>>
>>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
|
|
|
Help
Login
Home
