modelserver-glsp-integration: Issue with Model URIs on Windows

[BeniBianchi]

Hi,
as a start I decided to go with https://github.com/eclipse-emfcloud/modelserver-glsp-integration on Windows (I tried the main branch as well as the 0.8.0.RC05 branch).
I managed to build and start the three server processes (client, glsp, model) - so far so good.

The moment I tried to open the file 'example.tasklist' the model server complained 'Model not found!'.

If I look at the details of the request message in the log, it looks like this:
"INFO ProviderDefaults - GET /api/v2/models?modeluri=c%3A%255CUsers%255C..."

And in the error message in the same log it says:
"ERROR ContextResponse - Model 'file:/c:/%5CUsers%5C...' not found!"

If I play around with the model server by manually using/sending different styles of percent-encodings of the model URI, then it looks like the model server

• does not like the '%255C' double-encoding, but
• has no problems with the '%5C' encoding, and properly opens the file.

I found the cause of the problem in the following file of the modelserver-glsp-integration:
plugins/org.eclipse.emfcloud.modelserver.glsp.integration/src/org/eclipse/emfcloud/modelserver/glsp/EMSModelServerAccess.java

If I replace line 69:

this.baseSourceUri = URI.createURI(sourceURI, true).trimFileExtension();

by

this.baseSourceUri = URI.createURI(sourceURI).trimFileExtension();

then createURI does not do any percent-encoding (which is done anyway later by the okhttp3 library), and the model server properly opens the file.

But that workaround just led me to the next problem: it looks like the methods

trimFileExtension(), and
appendFileExtension()

of the class

org.eclipse.emf.common.util.URI

do not (properly) work on Windows at all.

So I did two more dirty workarounds:
First, I replaced the already mentioned line 69 by

sourceURI = sourceURI.replaceAll("\.\w+","");
this.baseSourceUri = URI.createURI(sourceURI);

AND replaced line 73

return baseSourceUri.appendFileExtension(this.semanticFileExtension).toString();

by

return baseSourceUri.toString() + "." + this.semanticFileExtension;

Second, I replaced line 57 of the file

plugins/org.eclipse.emfcloud.modelserver.glsp.integration/src/org/eclipse/emfcloud/modelserver/glsp/notation/integration/EMSNotationModelServerAccess.java

from

public String getNotationURI() { return baseSourceUri.appendFileExtension(this.notationFileExtension).toString(); }

to

public String getNotationURI() { return baseSourceUri.toString() + "." + this.notationFileExtension; }

After those changes I could finally open the diagram in Theia.
I am not sure where the real causes of the problems lie. I hope those workarounds give some hints.

Thanks,
Beni

[ndoschek]

Hi @BeniBianchi!
Thanks for your interest! 🎉
I will have a look into the matter in the next days!
Thanks and BR,
Nina

[ndoschek]

Hi @BeniBianchi,
Sorry for the delay!
I had a look on my Windows VM but I could not reproduce the double encoding issue unfortunately.
Do you know "what's the cause" of the double encoding? You are simply testing the project-template example of the modelserver-glsp-integration repo, right?
Thanks and BR, Nina

[BeniBianchi]

Hi Nina,
thank you for your response.

Yes, I am simply testing the project-template example of the modelserver-glsp-integration.
I wish I could give you a good hint on how to reproduce the problem on a Windows VM.
Does your Windows VM produce model paths with backslashes?

In my opinion, the main cause is the incorrect handling of paths containing backslashes as separators.

The function setClientOptions() in the file
modelserver-glsp-integration/plugins/org.eclipse.emfcloud.modelserver.glsp.integration/src/org/eclipse/emfcloud/modelserver/glsp/EMSModelServerAccess.java
is IMHO unable to properly deal with paths containing backslashes.

I presume that is the reason why the same function in the coffee-editor (see the following file) is dealing with the same situation slightly different:
coffee-editor/backend/plugins/org.eclipse.emfcloud.coffee.workflow.glsp.server/src/org/eclipse/emfcloud/coffee/workflow/glsp/server/WorkflowModelServerAccess.java

If I change the code of that function in the modelserver-glsp-integration according to the coffee-editor, then the modelserver-glsp-integration also properly works on (my) Windows. :-)

What do you think?

Thanks,
Beni

[ndoschek]

Hi Beni,

I hope this message finds you well. Firstly, I must apologize for the delayed response; your message somehow slipped through my inbox.

Yes, I agree with your proposal regarding the handling of paths in the setClientOptions() function within modelserver-glsp-integration. It seems like a sensible approach to align it with the method used in the coffee-editor's equivalent function to ensure compatibility across different operating systems, especially Windows.

Currently, the project is in maintenance mode and won't be actively developed further. However, we are still very much open to contributions from the community. If you're interested in implementing the changes you've suggested, we would be more than happy to review and integrate them.

Looking forward to hearing from you and once again, apologies for the late reply.

Best regards,
Nina