Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] project-specific XSD resolution question

Good to hear you're having progress. The real issue is that the DOM and SAX interfaces do not pass any sort of context down through the layers. Instantiating a new resolver dynamically would take care of that, but Eclipse's URIResolvers / URIResolverExtensions are statically instantiated from the extension-points. Bummer (or API improvement potential?)

Any idea how this could be solved?

Would a thread-local variable work for you? While it does make you dependent on the validator's concurrency model (in this case, the Xerces validating parser, right?), it is unlikely to change anytime soon.

Another trick would be to introduce a new URI scheme for the second-level dependencies, and use two resolvers: One resolver (I'm guessing stage="postnormalization") would work on the logical level, and extract the project from the baseLocation,and turn it into a different faux-URL:

resolve(baseLocation, publicId, systemId) would return "my-qualified-file://<project-name-from-baseLocation>/<systemId>"

Another URIResolver (stage="physical") would resolve the faux-URL into the real resource, using the mapping from the authority part of the URI:

resolve("my-qualified-file://<project-name-from-baseLocation>/<systemId>", publicId, <nextLevelSystemId>") would return "file://<wherever-you-find-the-relevant-nextLevelSystemId-on-the-project>"

This should preserve the "logical" URI as the base when getting the second-level dependencies. I'm thinking it does (as it also works for the interface for the XML catalog and cache extensions), but I can't guarantee it. :-|

Did that make sense?

One drawback I could imaging is that if there are problems in actually parsing/validating the referenced resources, you'd expose the faux-URIs to the user. Don't know if that's an issue.


On Wed, Jan 30, 2013 at 11:39 AM, Martin Lippert <lippert@xxxxxxx> wrote:
Hey Jesper!

The XSL tooling plugin uses a resolverExtension to accomplish something similar. You may be able to find pointers there.
IIRC, it is the core plugin. Mind you, they will be cases where you can't find a project, in case a resource is loaded directly from the file system, e.g. with File > Open

Firstofall, thanks for your answer and the pointer!!!
I looked into this in more detail. The problem for me seems to be:

In case an XML file is being parsed, I get the XML file from my workspace as IFile parameter into this method call:

URIResolverExtension.resolve(IFile file, String baseLocation, String publicId, String systemId);

That is great and I can identify the project this file comes from.
But if the XSD refers another XSD, the lookup of the corresponding project seems to fail in ExtensibleURIResolver:

        public String resolve(String baseLocation, String publicId, String systemId)
                String result = systemId;

                // compute the project that holds the resource
    IFile file = computeFile(baseLocation);

because the baseLocation is now pointing to the location of the XSD - and that is inside my local Maven repo, for example (so not in my workspace). Therefore this lookup (computeFile) fails and I get no information for which project this lookup should happen.

Any idea how this could be solved?

Thanks for your help!


On 21/11/2012, at 17.04, Martin Lippert <lippert@xxxxxxx> wrote:


A while ago I asked this question, which is still open on my end and I am still hoping to find some help here. Any idea? That would be really really great!


On 15.06.12 15:51, Martin Lippert wrote:

We have implemented project-specifc XSD resolution for the Spring IDE,
but are still suffering from a few cases where we don't get any
information about the project for which the XSD should be resolved. And
I would love to hear from you whether this is possible at all, and what
I maybe need to take a look at in this case.

We have implemented the extension point:

with stage=postnormalization

But that doesn't seem to always give us the necessary information to
which project this resolving belongs to. And I am not sure whether the
webtools allows us to fully implement this.

Any pointers and help highly appreciated!
wtp-dev mailing list
wtp-dev mailing list

wtp-dev mailing list

Back to the top