Home » Modeling » EMF » StackOverflowError when saving resource
| |
Re: StackOverflowError when saving resource [message #1736952 is a reply to message #1736919] |
Mon, 04 July 2016 14:40 |
Vlad Acretoaie Messages: 95 Registered: April 2014 |
Member |
|
|
Thank you for the very quick reply. After considering your suggestion and digging into the problem a bit deeper, I am now even more confused as to what is going on.
The MyClassImpl.eIsSet method does indeed contain implementation code. It looks like this:
@Override
public boolean eIsSet(int featureID) {
switch (featureID) {
case IMyPackage.A:
return ....;
case IMyPackage.B:
return ...;
}
return super.eIsSet(featureID);
}
Even though the classes in my code have been regenerated, featureID does not match any of the case branches in the above switch statement. The superclass whose eISet method is invoked is BasicEObjectImpl, a platform class.
Interestingly, I can check by looking at my Ecore model and at the generated code, including the generated instance of EPackageImpl, that all features declared in the Ecore model also appear in the generated code. I can also see when tracing that the feature identified by featureID exists in the generated code, but simply has a different ID than the one passed to the method above as featureID.
It appears as though the culprit is the saveFeatures method in the XMLSaveImpl class, which is responsible for generating the ID passed to the eIsSet method shown above. Somehow the generated ID does not correspond to the ID stored in the IMyPackage.A constant. One of the IDs is 10, and the other is 11.
I agree that this looks exactly as though the generated code is not up to date. However, I have re-generated it multiple times today.
|
|
|
Re: StackOverflowError when saving resource [message #1736959 is a reply to message #1736952] |
Mon, 04 July 2016 15:30 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Vlad,
Comments below.
On 04.07.2016 10:40, Vlad Acretoaie wrote:
> Thank you for the very quick reply. After considering your suggestion
> and digging into the problem a bit deeper, I am now even more confused
> as to what is going on.
>
> The MyClassImpl.eIsSet method does indeed contain implementation code.
> It looks like this:
>
>
> @Override
> public boolean eIsSet(int featureID) {
> switch (featureID) {
> case IMyPackage.A:
> return ....;
> case IMyPackage.B:
> return ...;
> }
> return super.eIsSet(featureID);
> }
>
>
> Even though the classes in my code have been regenerated, featureID
> does not match any of the case branches in the above switch statement.
> The superclass whose eISet method is invoked is BasicEObjectImpl, a
> platform class.
> Interestingly, I can check by looking at my Ecore model and at the
> generated code, including the generated instance of EPackageImpl, that
> all features declared in the Ecore model also appear in the generated
> code. I can also see when tracing that the feature identified by
> featureID exists in the generated code, but simply has a different ID
> than the one passed to the method above as featureID.
>
> It appears as though the culprit is the saveFeatures method in the
> XMLSaveImpl class, which is responsible for generating the ID passed
> to the eIsSet method shown above.
The ID of a feature is just its position in the list of
eAllStructuralFeatures, so not much room for this to go wrong.
> Somehow the generated ID does not correspond to the ID stored in the
> IMyPackage.A constant. One of the IDs is 10, and the other is 11.
Something has not been regenerated or not recompiled.
>
> I agree that this looks exactly as though the generated code is not up
> to date. However, I have re-generated it multiple times today.
Something didn't end up being @generated NOT or missing the @generated
such that it's not being regenerated? You mention IDs like 10 and 11,
but show code with only two features...
If this is a class with no base classes, which looks to be the case for
above, where the eIsSet of BasicEObjectImpl is being called. Look at how
many features are actually in the EClass at runtime. What are all their
names? Does the generated eIsSet for that class (and the base classes)
cover all those cases?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: StackOverflowError when saving resource [message #1737060 is a reply to message #1737048] |
Tue, 05 July 2016 12:16 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Vlad,
No, I've not seen ever that a class is not regenerated, except if the
existing target class has syntax errors or the newly generated class has
syntax errors. Typically such problems would be logged in the Error log...
On 05.07.2016 06:02, Vlad Acretoaie wrote:
> Thank you once more for the suggestions. I finally solved the problem,
> and it was indeed related to code generation.
>
> Namely, a generated package class (a class extending EPackage) was not
> being regenerated at all. Therefore, some of the feature IDs it
> declared were out of sync with the Ecore model. I solved the problem
> by deleting the class from the file system, thus "forcing" it to be
> re-generated from scratch. It appeared that anything else I did (I
> tried deleting some feature IDs from the class, for instance) would
> leave the generated class untouched, as if the generator did not
> attempt (or did not have permission) to modify it.
>
> Do you have any thoughts as to what might be causing this? Could it be
> that under some circumstances (e.g. some property values set on the
> generator model) a generated class simply cannot be re-generated?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Mon Sep 23 04:30:07 GMT 2024
Powered by FUDForum. Page generated in 0.03566 seconds
|