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

Hey Jesper!

Your second approach using two resolvers (one for putting the project into a specific URI and the other to extract that information again) looks very promising. Will need to do a lot more testing on this, but up to now this looks great.

Thank you very very very much for your help and this great idea!!!
Much appreciated!!!


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

 > 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

resolve(baseLocation, publicId, systemId) would return

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

publicId, <nextLevelSystemId>") would return

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
<mailto: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
        <mailto: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@xxxxxxxxxxx <mailto:wtp-dev@xxxxxxxxxxx>

        wtp-dev mailing list
        wtp-dev@xxxxxxxxxxx <mailto:wtp-dev@xxxxxxxxxxx>

    wtp-dev mailing list
    wtp-dev@xxxxxxxxxxx <mailto:wtp-dev@xxxxxxxxxxx>

wtp-dev mailing list

Back to the top