Hi Jeff,
We are using xsl:import and xsl:include in our templates with the
getResource() mods without any problems. Fortunately, it didn't require
writing any custom URI resolvers.
In the newTemplates() method of the Transformer factory instance we pass in
a StreamSource constructed from the URL input stream *and* the (optional)
second argument is the stringified URL. It's this second arugment which
means (for us at least) that relative URIs in xsl:import and xsl:include
work OK :-
TransformerFactory tFactory = TransformerFactory.newInstance();
info.templates = tFactory.newTemplates(new
StreamSource(conn.getInputStream(), url.toString()));
This was in the patch that I sent you against the 1.x code; is it possible
that you missed this mod when you updated the 2.x code?
Cheers
Guy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: 29 January 2002 15:29
To: [EMAIL PROTECTED]
Subject: [Mav-user] getResource() problems
I just backed out the changes to XSLTransform.java which load XSL files
with getResourceAsStream(). Basic XSLs work, but xsl:import,
xsl:include, and document() become hideously broken.
Basically, without setting a custom URIResolver which feeds back into
the container getResourceAsStream(), the XSLT processor will try to
resolve imports et al from tomcat/bin/ (or orion/). How to make a
custom URIResolver work with getResourceAsStream() is not immediately
obvious. If anyone would like to take a stab at it, I'll be happy to
accept patches, but otherwise I'm going to move on to other tasks. For
the time being, I suggest configuring your container to expand warfiles.
Jeff Schnitzer
[EMAIL PROTECTED]
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
