Missing "eClass" attribute in models created by Model Server

[agonzalezgaliana]

I'm currently integrating my Model Server with the Theia Tree editor and I'm finding difficult to classify the information in my model coming from the Model Server. From what I see in the Coffee editor example, the attribute "eClass" is used in several places to know more about a node, i.e. in the label provider:

if (data.eClass) {
            switch (data.eClass) {
                case CoffeeModel.Type.Task:
                case CoffeeModel.Type.AutomaticTask:
                case CoffeeModel.Type.ManualTask:
                case CoffeeModel.Type.Machine:
                    return data.name || this.getTypeName(data.eClass);
                default:
                    // TODO query title of schema
                    return this.getTypeName(data.eClass);
            }
        }

if I take a look on one of the example models provided by the Model Server project (SuperBrewer3000.json) I can see that the "eClass" is provided almost everywhere for each object:

{
  "eClass" : "http://www.eclipsesource.com/modelserver/example/coffeemodel#//Machine",
  "children" : [ {
    "eClass" : "http://www.eclipsesource.com/modelserver/example/coffeemodel#//BrewingUnit"
  }, {
    "eClass" : "http://www.eclipsesource.com/modelserver/example/coffeemodel#//ControlUnit",
    "processor" : {
      "clockSpeed" : 5,
      "numberOfCores" : 10,
      "socketconnectorType" : "Z51",
      "thermalDesignPower" : 100
    },
    "display" : {
      "width" : 10,
      "height" : 20
    }
  } ],
  "name" : "Super Brewer 3000",
  "workflows" : [ {
    "name" : "Simple Workflow",
    "nodes" : [ {
      "eClass" : "http://www.eclipsesource.com/modelserver/example/coffeemodel#//AutomaticTask",
      "name" : "PreHeat",
      "component" : {
        "eClass" : "http://www.eclipsesource.com/modelserver/example/coffeemodel#//BrewingUnit",
        "$ref" : "//@children.0"
      }
    } ]
  } ]
}

On my side, I created a sample instance of my model using the Java auto-generated EMF API (from *.ecore file) by means of the ModelFactory.eINSTANCE.createMyObjects() and later called the ModelServerClient API for creating a new model in my workspace:

Model m = ModelFactory.eINSTANCE.createModel();
model.set();
....

ModelServerClient client;
client.create(modelUri, m, "json");

The result, not sure why, is a file in the workspace with XMI format (?).

When retrieving the model from the Model Server, the result is correct but the "eClass" parameter only appears on the root node, even though the object contains other objects of different classes.

Is this a problem on the default Codecs used for serializing the objects? Is it expected to see the "eClass" attribute on all properties of a model?

Thanks in advance.

[vhemery]

This question is also related to Jackson serialization ( https://emfjson.github.io/projects/jackson/latest/ ) and XMI serialization.
The basic rule is that you get an "eClass" attribute when the eClass cannot be automatically deduced.
This means that you have a reference which eType is an interface or an abstract EClass, but not for a concrete EClass. (not sure exactly how it is handled when this is a concrete EClass with eventual subtypes, but IIRC the "eClass" attribute should be there only for subclasses instances)

When you create with the Java EMF API, you seem to only create a detached model (unless there is a resource you didn't mention).
The call to client.create(modelUri, m, "json"); should persist in the indicated format, unless you have configured you model server with specific format support (did you configure it elsewhere for persisting in XMI only ?).

If you want a deeper analysis of your issue, please attach :

• the ecore of your metamodel (simplified if necessary)
• the persisted model you get
• and tell us what differences you were expecting

In case you want the "eClass" attribute from a client with json (be it Java or Typescript), you will have to rely on the containing reference's EType (hence have the parent's EClass, recursively if needed, the containing reference name, and knowing its type in the schema).