This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: include statement
- From: Joerg Pietschmann <joerg dot pietschmann at zkb dot ch>
- To: XSL List <xsl-list at lists dot mulberrytech dot com>
- Date: Tue, 05 Mar 2002 09:49:43 +0100
- Subject: Re: [xsl] include statement
- Organization: ZKB
- Reply-to: xsl-list at lists dot mulberrytech dot com
Kevin.Gutch@mapinfo.com wrote:
> From within a servlet I have an XSL file that uses an <xsl:include>
> statement.
...
> - -I grab my principal.xsl from as a .getSystemResourceAsStream because it
> is within a jar File.
This appears to be the problem.
You have to get familiar with the mechanics behind URI handling.
The xsl:include statement takes an URL. In your old configuration,
the name you supplied was interpreted as relative URI, which was
in turn resolved against the URI of the style sheet (roughly the
same way a browser resolves relative URIs). This made it an
absolute file URL pointing exactly where you wanted.
In your new setup, the processor environment is apparently no
longer able to correctly discover the URI of the style sheet
and uses the current working directory instead (often the most
"intuitive" value).
You can try to use an absolute URI in your xsl:include statement.
This works best if its a syntactically correct file URI like
"file:///foo/bar/included.xsl" (note the triple slash) or
"file://C:/foo/bar/included.xsl" in a Windows environment.
However, the best solution for you is probably to write a custom
URIResolver. Look up this interface and the setURIResolver() method
in the TransformerFactory interface in the JAXP documentation. Look
up the source code of the default implementation in Xalan or Saxon
to get an impression what to do there. This would allow you to put
the included XSL file also into the jar and use it via
getRessourceAsStream() if you want to.
HTH
J.Pietschmann
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list