| XSLT Custom URI Resolver Problem [message #794845] |
Thu, 09 February 2012 14:27  |
Eclipse User |
|
|
|
I'm upgrading a project from an old version of Eclipse (Weblogic Workshop) to Eclipse Indigo. Got everything to work except an XSL problem. There are several errors like the following:
Description Resource Path Location Type
Named template COMMON_FIRST is not available aCertainFile.xsl /aCertainPath line 53 XSL Problem
The template exists in another XSL file in another package that is imported. When I move the file to the same directory and make the import relative; it works.
The imported XSL file is declared using a full path name. A custom URI resolver was implemented to support full path names; whose files are searched on the classpath.
This approach works great in Weblogic server and junits; because we set all this up using the Spring container. The Spring container instantiates a custom TransformerFactoryImpl class (SaxonTransformerFactoryImpl), and injects the custom URL resolver into it.
However, the XSL validation in Eclipse Indigo does not work. I suspect that this is because the Eclipse XSLT plugin does not know about the custom URL resolver. I tried to find out if there is a way to register one with the saxon plugin; org.eclipse.wst.xsl.saxon_1.0.200.v201103081922.jar, but I couldn't find any documentation. I created a new XSL Saxon9 processor of type 'Saxon (XSLT 2.0). So I'm thinking that Eclipse is using the saxon plugin; although I could be wrong...
I tried shutting off the XSL validation (window -> Preferences -> XML -> XSL -> Validation); but the changes would not persist. However, Ideally, I would like the validation to work.
So my question is: Is there a way to configure the TransformerFactoryImpl class so that my custom URI resolver instance can be injected rather than using the default? Is there a Spring container plugin in which i could configure and instantiate the SaxonTransformerFactoryImpl class?
It would be really cool to have Eclipse tightly integrate with Spring so that Eclipse can use the same application context that is deployed with the application to the application server for testing...
|
|
|
| Re: XSLT Custom URI Resolver Problem [message #804407 is a reply to message #794845] |
Wed, 22 February 2012 10:39  |
| Eclipse User |
|
|
|
Unfortunately, the XSL Validation doesn't leverage the use of custom URI resolvers. Even if it did, it would need to use the Eclipse URI Resolver extension point and get a contribution.
You can always extend the existing XSLValidation plugin and contribute your own validator, or better yet contribute a patch back to allow the XSLValidation to make use of a URIResolver extension if available to locate the files.
Currently it relies on finding files in the filesystem and in particulare the IFile interface. If it isn't there, it won't be able to validate the projects correctly.
This makes it difficult as well to reference say the DocBook stylesheets using a HTTP url format.
I'm not sure, but there might be a bug report already open for this. Unfortunately my time is very limited right now so don't know when I'm going to get back to working on XSL plugins again.
|
|
|
Powered by
FUDForum. Page generated in 0.06120 seconds
Home