Community
Participate
Working Groups
Created attachment 175911 [details] Demo project Attached project demonstrates a problem whereby model/Referer.ecore has a proxy to model/Refered.ecore, whose relative path in model/Referer.ecore is minimised to Refered.ecore#... model/Referer.ecore is loaded using a relative URI. Proxies are then resolved and fail due to a failure to load .../RelativeProxies/Refered.ecore rather than .../RelativeProxies/model/Refered.ecore. The problem is that the first resource provides the relative URI as its resourceURI and that relative-against-relative URI resolution is not supported. Bug fix in next message.
Created attachment 175913 [details] Allow relative-against-relative URI resolution Patch a) configures XMLHandler to resolve for relative base URIs b) removes URI's prohibition on relative base URIs c) computes a relative-against-relative resolution --- Observation: the exception arguments are not internationalized and have no NLS warning suppression. Is this intended? Observation: the original proxy resolution shows up only as an error in the refered resource. Shouldn't there also be a 'proxy-resolution failed error' in the refering resource?
Don't use relative URIs to load resources. I've been telling people that for years. It's just bad news and we really don't need to make changes that encourage people to use such an approach. Better it fail and they fix their code. You're also assuming that no one relies on the current behavior but I'm pretty sure WTP relies on using /project/path/file.extension resolving to the workspace when running in Eclipse and also expects to get all URI references to be of that form. Also, Dave implemented URI to conform to the RFC which is quite explicit about URI resolution being undefined for relative URIs. You'll find most exceptions in the SDK are not internationalized.
My solution may not be right, and I'm always strongly inclined to conform to specifications so a URI change is not the right way to go. If relative URIs are discouraged this should be more obvious; it's news to me. Allowing a self contained file to load correctly but a file with proxies to fail very obscurely is an unpleasant confusion for users. I feel that either relative URIs should work consistently or they should fail consistently. Changing behaviour to make them fail consistently seems a sure way to have numerous compatibility complaints, so I think we have to find a way to make it work. Changing Resource.uri so that it is resolved rather than relative could solve the problem but probably has numerous other compatibility issues. Perhaps the solution is for XMLHandler to resolve its resourceURI so that there is a proper base for the proxies to resolve against.
I'm just not inclined to make any changes to behavior. It's just bound to break someone and while we might argue they're doing something poorly, it's been working this poor way for close to a decade. Part of the issue is that path/file.extension behaves differently when running with an Eclipse workspace, it's workspace relative in that case, verses when running stand alone or without a workspace, then it's relative to the current working directory. But that fact is hidden in the bowls of the URI converter, i.e., calling normalize will not turn a relative URI into an absolute URI to reveal this detail, only createInputStream and createOutputStream do the job of returning an "appropriate" stream. I'd have been happier to have such non-absolute URIs fail completely, but that's not what the clients wanted 10 years ago, despite my objections and despite better solutions.
