Eclipse Community Forums: TMF (Xtext)

Help

Home

Home » Modeling » TMF (Xtext) » Using custom URI's

Show: Today's Messages :: Show Polls :: Message Navigator

Using custom URI's [message #1855985]

Mon, 14 November 2022 14:30

Simon Cockx

Messages: 69
Registered: October 2021

Member

With Xtext 2.25, we were using custom URI's of the form `ws:/some/uri` and `scm:/some/other/uri` for which we implemented a custom way of resolving them. However, since upgrading to Xtext 2.27 and LSP4J 0.14.0, we have issues were Xtext tries to read the URI's itself.

I am guessing that our current approach (something I didn't write myself :) ) was somewhat hacky, and didn't really integrate well with Xtext. What is currently the best approach?

I have been looking at this thread:
https://www.eclipse.org/forums/index.php/t/200704/

It seems very close to what I would like to achieve. What I gathered from this, is that I should define a custom `URIHandler` for each of our custom protocols, and then somehow hook that into the `XtextResourceProvider`. However, it is an old thread, and I can't seem to find `org.eclipse.xtext.ui.resource.IResourceSetProvider` anywhere. Is there a new way of doing this?

Kind regards

Simon

[Updated on: Mon, 14 November 2022 14:36]

Report message to a moderator

Re: Using custom URI's [message #1855986 is a reply to message #1855985]

Mon, 14 November 2022 14:35

Christian Dietrich

Messages: 14738
Registered: July 2009

Senior Member

can you give a more detailed problem and error description

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Day Job: https://www.everest-systems.com

Report message to a moderator

Re: Using custom URI's [message #1855987 is a reply to message #1855986]

Mon, 14 November 2022 15:04

Simon Cockx

Messages: 69
Registered: October 2021

Member

I'll try to give you the broad lines. I'm not sure if this is all relevant though, and I fear we have some tech debt. What I basically would like to do is tell Xtext how to resolve a particular URI.
Our infrastructure high-level looks like this:

On the backend we use Xtext 2.27.0. (was 2.25.0)
On the frontend we use Monaco 0.34.1 (was 0.19.3) (https://github.com/microsoft/monaco-editor)
For communication we use LSP4J 0.14.0. (was 0.9.0)

We use URI's with custom protocols. Each protocol basically points to a different root folder on the file system.

The upgrade broke several things.
1. When calling the LSP method `initialize`, we noticed the backend now tries to build all files in the workspace. Before this, we handled the build process ourselves after LSP initialization. However, now it does so by running a file scanner on the given workspace URI (for which we have a protocol ws:/), which completely ignores the protocol and interprets the URI as a local file path.
=> our solution was to hook into `IFileSystemScanner` and translate the `ws:/` URI's to regular `file:/` URI's.
2. Our build process relies on receiving resources with a URI that uses our custom protocols. However, the `IFileSystemScanner` outputs `file:/` URI's, which then crashes the build system.
=> our hacky solution was to hook into `ResourceAwareFSAFactory` and convert these URI's back into the ones we expect.
3. The command `Search symbol across workspace` triggers a call to `XtextResourceSet::getURIConverter().createInputStream`, which also doesn't know how to handle our custom URI's.

I find my current approach somewhat dirty, and I was hoping to find a single place where I could override the behaviour of URI resolution. Hence, my original question.

[Updated on: Mon, 14 November 2022 15:12]

Report message to a moderator

Re: Using custom URI's [message #1855992 is a reply to message #1855987]

Mon, 14 November 2022 20:23

Ed Willink

Messages: 7681
Registered: July 2009

Senior Member

Hi

Most users are aware of the ResourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap() that supports a mapping from file extension to ResourceFactory.

There are actually three such local and global registries.

(The getContentTypeToFactoryMap() registry enables the internal namespace of a generic *.xml or *.uml to be directed to the appropriate 'content'-specific ResourceFactory. This is used to provide backward compatibility in the UML2 project. The content type was a later addition for which some IMHO unfortunate legacy compatibility choices result in some surprises.)

However the getProtocolToFactoryMap() registry is what you want. It takes first bite at the resource open and so you can use your custom ResourceFactory and if necessary wrap a further creation that is extension sensitive.

You should be able to register your scheme via extension point/ standalone initialization so that it works for all EMF tools; the Sample Ecore Model Editor is always a good neutral arbiter of EMF compliance. You should then find that Xtext just works without any knowledge of your special functionality.

You should make sure you understand the prioritization and delegation of ResourceFactoryRegistryImpl.getFactory before you do any significant development. Beware that you must ensure that your protocol is locally registered to avoid a local extension factory resolution occluding a global protocol registration.

Regards

Ed Willink

Report message to a moderator