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.
-Jesper
On Wed, Jan 30, 2013 at 11:39 AM, Martin Lippert <lipp...@acm.org> 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!
> -Martin
>
>
>
>
>
>
>
>
>> -Jesper
>>
>> On 21/11/2012, at 17.04, Martin Lippert <lipp...@acm.org> wrote:
>>
>> Hey!
>>>
>>> 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!
>>>
>>> Thanks!
>>> -Martin
>>>
>>>
>>>
>>> On 15.06.12 15:51, Martin Lippert wrote:
>>>
>>>> Hey!
>>>>
>>>> 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:
>>>> org.eclipse.wst.common.**uriresolver.resolverExtensions
>>>>
>>>> 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!
>>>> -Martin
>>>>
>>> ______________________________**_________________
>>> wtp-dev mailing list
>>> wtp-dev@eclipse.org
>>> https://dev.eclipse.org/**mailman/listinfo/wtp-dev<https://dev.eclipse.org/mailman/listinfo/wtp-dev>
>>>
>> ______________________________**_________________
>> wtp-dev mailing list
>> wtp-dev@eclipse.org
>> https://dev.eclipse.org/**mailman/listinfo/wtp-dev<https://dev.eclipse.org/mailman/listinfo/wtp-dev>
>>
>> ______________________________**_________________
> wtp-dev mailing list
> wtp-dev@eclipse.org
> https://dev.eclipse.org/**mailman/listinfo/wtp-dev<https://dev.eclipse.org/mailman/listinfo/wtp-dev>
>
_______________________________________________
wtp-dev mailing list
wtp-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/wtp-dev
