Overriding Codecs in the Model Server (for id encoding)

[glsp-bot]

Hello, I am currently trying and using the EMF.Cloud Model Server on top of a broader EMF application, which uses XML uuids and CDO (hence CDOIDs). I'm currently using Model Server 0.7.0.202012181648 (for the record, in case any change occurs).

I'd like not to use path ids (like '//@commands.1/@objectsToAdd.0') but instead XML uuids or CDOIDs, which I can easily get from my framework's Resource#getURIFragment. My concern is that during encoding, we use the org.eclipse.emfcloud.modelserver.emf.common.codecs.Codecs class with static codecs which implementation is not compatible with this approach.

I could override Codecs by overriding SessionController and ModelController in the injection scope, but this does not look like the best solution and I'm afraid I might miss some usage locations, especially future calls or internal calls to modelserver.emf.common.codecs.JsonCodec.encode(Object).
Is overriding the Codecs a use case planned so far ? Has it been intentionally restricted or has the need just not presented yet ?
To me, it looks like the org.eclipse.emfcloud.modelserver.emf.common.codecs.Codecs.formatToCodec Map could be filled with an extension point with a priority attribute, allowing for greater configurability. (Of course, such PR would also require changes in handling org.eclipse.emfcloud.modelserver.client.ModelServerClient#SUPPORTED_FORMATS, and maybe other places I don't foresee).

Thank you in advance for sharing your thoughts on this subject.
Of course, I'll happily share with anyone interested the results of my experiments with the Model Server once I get to the end of it.

original thread by Vincent HEMERY

[glsp-bot]

[Vincent HEMERY]

Update : I managed to achieve what I intended (override Codecs to use ids). But my current implementation involves hacking the private attributes with reflexivity. So I would gladly consider submitting a Pull Request if anyone else thinks it is a good idea to give the possibility to override Codecs.

Here is an example of my resulting Json with ids :

``` {
  'type' : 'success',
  'data' : {
    'eClass' : 'http://www.cnes.fr/disco/data#//PackageData',
    '@id' : '_DaN-QFP6EeuFkvaB_Li0bA',
    'annotations' : [ {
      '@id' : '_DahgQFP6EeuFkvaB_Li0bA',
      'source' : 'http://www.cnes.fr/disco/check',
      'details' : {
        'code' : 'dis.code='
      }
    } ]
  }
}```

[glsp-bot]

[Martin Fleck]

Hello @vhemery(vhemery) ,

Thank you for your interest in the Model Server. Our main goal is extensibility so we are glad you brought that to our attention! There is an on-going task on our side to provide more binding methods to the ModelServerModule to increase flexibility in different areas but we did not consider Codecs yet. From just a quick glance it would probably be a good idea to have a set binder so additional codec instances could be registered with the Codec interface (extended with the extensions the codec handles) and an additional bound class (with interface) that handles the aggregation and querying of those codecs (similar to what the Codecs class does now). Then the aggregation class could be simply injected. Of course, this is just from the top of my head, so in detail maybe additional changes may be required. Nevertheless, I am sure such a functionality is definitely worth having.

I am very glad you managed to get your implementation running in the meantime! We would be happy to accept a pull request on this. Ideally it would already be aligned with our approach (DI in modules) as outlined above. Otherwise I can also offer to spend some time on that by the end of this week. Just let me know what you prefer and whether there is something else we can help you with.

[glsp-bot]

[Vincent HEMERY]

Thanks for your enthusiasm.
I think I'll try and submit my own PR in order to involve in the project.
Should I try a PR on 'Improve ModelServerLauncher for easier customization #54' or create another dedicated issue for this improvement ?

[glsp-bot]

[Martin Fleck]

@vhemery(vhemery) Great, thank you very much! I created a separate issue for you which you can reference in your PR: eclipse-emfcloud/emfcloud-modelserver#60

Just FYI, I might push a general update on the server module today or tomorrow but that should not cause too many conflicts which I can resolve later if necessary.

[glsp-bot]

[Vincent HEMERY]

I've got some of the org.eclipse.emfcloud.modelserver.emf.tests tests failing before my modifications (hence on master), and the test bundles do not look like they're part of the maven reactor...
What is the test strategy here ? Is there a way to run the tests that I have missed ? Are they part of integration platform process somewhere else ?

[glsp-bot]

[Martin Fleck]

@vhemery(vhemery) Currently we execute the tests manually (from Eclipse on the project right click > Run as > JUnit Test). We had some troubles getting that to run properly in the CI when migrating to the Eclipse infrastructure but the plan is to have them run via maven, both locally and in the CI. I estimate that we will get this done some time this or latest next month.

Regarding the test failure, what problem do you experience? There is one known issue we run into recently since we updated to the latest Javalin version. I documented it now in eclipse-emfcloud/emfcloud-modelserver#63 to make it more public. That problem seems to occur sometimes when running the test cases, so running them a few times might solve that problem for now.

[glsp-bot]

[Vincent HEMERY]

@martin-fleck(martin-fleck) I detailed it all here : eclipse-emfcloud/emfcloud-modelserver#64
After a quick look, all these failures should probably not happen on linux. But in any case, this is probably best to make tests OS-independant.

[glsp-bot]

[Martin Fleck]

@vhemery(vhemery) I was not aware of those issues on Windows, so thank you for creating an issue and providing all the details! I agree with you that the tests should be OS-independent and I cannot reproduce the problems on Linux. So there is definitely some work that needs to be done.