Stack Overflow during Serialization

[Franz-Ritter]

Hello,

I try to read a xtext sysml file and afterward write it back using the Xtext serializer . The serializer is initialized as follow:

Injector injector = new SysMLStandaloneSetup().createInjectorAndDoEMFRegistration();
Serializer serializer = injector.getInstance(Serializer.class);

However, once I try to serialize the root Element of my resource I receive a stack overflow, which seems to appear during the org.eclipse.xtext.serializer.analysis.GrammarConstraintProvider.Constraint#computeUpperBound operation`:

java.lang.StackOverflowError
    at java.base/java.util.HashMap.hash(HashMap.java:338)
    at java.base/java.util.HashMap.getNode(HashMap.java:568)
    at java.base/java.util.HashMap.get(HashMap.java:556)
    at org.eclipse.xtext.serializer.analysis.GrammarConstraintProvider$Constraint.computeUpperBound(GrammarConstraintProvider.java:193)
    at org.eclipse.xtext.serializer.analysis.GrammarConstraintProvider$Constraint.computeUpperBound(GrammarConstraintProvider.java:218)
    at org.eclipse.xtext.serializer.analysis.GrammarConstraintProvider$Constraint.computeUpperBound(GrammarConstraintProvider.java:204)
    at org.eclipse.xtext.serializer.analysis.GrammarConstraintProvider$Constraint.computeUpperBound(GrammarConstraintProvider.java:218)
    at org.eclipse.xtext.serializer.analysis.GrammarConstraintProvider$Constraint.computeUpperBound(GrammarConstraintProvider.java:204)
    at org.eclipse.xtext.serializer.analysis.GrammarConstraintProvider$Constraint.computeUpperBound(GrammarConstraintProvider.java:218)
    at org.eclipse.xtext.serializer.analysis.GrammarConstraintProvider$Constraint.computeUpperBound(GrammarConstraintProvider.java:204)
    at org.eclipse.xtext.serializer.analysis.GrammarConstraintProvider$Constraint.computeUpperBound(GrammarConstraintProvider.java:218)
    at org.eclipse.xtext.serializer.analysis.GrammarConstraintProvider$Constraint.computeUpperBound(GrammarConstraintProvider.java:204)
    at org.eclipse.xtext.serializer.analysis.GrammarConstraintProvider$Constraint.computeUpperBound(GrammarConstraintProvider.java:218)

More precisely, this seems to happen during the resolvement of the multiplicity.

The example sysml model I use looks as follows:

library package Core {

    package Base {

        item def Bar  {

         }

         item def Foo  {
             ref externalItemMappings: Bar [0..1];
         }

    }
}

This is my test code:

File  metaModelAsFile = getFile(FILE_NAME);
        ResourceSet rs = new ResourceSetImpl();
        Resource resource = rs.getResource(URI.createURI(metaModelAsFile.toURI().toString()), true);
        Element rootElement = (Element) resource.getContents().get(0);

        Injector injector = new SysMLStandaloneSetup().createInjectorAndDoEMFRegistration();
        Serializer serializer = injector.getInstance(Serializer.class);
        String serialize = serializer.serialize(rootElement);

Is this a known issue? Do I miss something during the initialization of the serializer? Do you have any example code or test which tries to achieve something similar? The overall use case we have, is that we try to export our sysmlv2 model to a xtext file for different usages.

Thanks and Cheers

[seidewitz]

Xtext serialization is not supported in the Pilot Implementation. There are separate efforts on-going to implement the generation of textual notation from KerML and SysML v2 XMI, but they are not ready for public release yet.

[Franz-Ritter]

@seidewitz Thanks for the info. Can you tell me how you manage the serialization with the "SysML v2 Feature" Plugin for eclipse where I am able to edit and safe sysml files? Could you maybe even point me to the code, which manages that part? My current workaround to safe a sysml Resource to a file would be to safe it as .xmi file, which seems to work fine.

However, this serves only as a workaround, because we would also be interested to edit the saved file in the sysml editor of eclipse to have the syntax check available.

Any tips in this regard would be appreciated.

[Franz-Ritter]

@seidewitz is there any roadmap, which points out when the proof of concept implementation may be available?