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
