OK. I have opened a bug in Jira and attached a simple test case. The transformation runs as expected when simply run.
The bug occurs when you try to pre-compile the XSL. When you do this, the xsl:import cannot be found. It does not enter the custom URIResolver (TemplatesResolver) best, -Rob On Tue, 2007-09-18 at 10:57 -0400, Santiago Pericas-Geertsen wrote: > On Sep 18, 2007, at 10:27 AM, Robert Koberg wrote: > > > But it is pretty simple to reproduce: > > > > - create an XSL file the either imports or includes another XSL, and > > uses the document function to bring in an XML. The files should not be > > relative to the XSL > > - create two URIResolvers that can resolve (perhaps in different ways) > > the files mentioned above > > > > 1. Get a a newInstance of a TransformerFactory > > 2. Set one resolver on the factory > > 3. Get a Templates object > > 4. Get a Transformer object from the Templates object > > 5. Set the other resolver on the Transformer > > 6. Run the transformation > > > > I will try to get a test case later, but it is a bug, has been for a > > while... For what it is worth Caucho' Resin XSLT compiler does the > > same > > thing (or at least it did). > > I see. Looking at the source code, it isn't obvious why it wouldn't > work as designed (the _uriResolver variable is clearly overwritten > when calling setURIResolver() on the Transformer). If you can provide > a test case, I'll look at it. > > Thanks. > > -- Santiago > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
