tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <>
Subject Re: Problem with the xsl:import
Date Tue, 25 Apr 2006 12:16:44 GMT
Here's the problem. xsl:import is purely an XSL thing. So it doesn't 
necessarily do anything similar to how the servlet spec does things.

So when you have <xsl:import href="cowbell.xsl" /> - cowbell is retreived in 
a relative style with respect to its context. (which could be file, or http).

Your webapp lives in a context. But xsl knows nothing about context, or 
context as defined by the servlet spec. So asking for 
http://localhost/aaem/xsl/routesummarycontent.xsl is the same as a webbrowser 
asking for it. On a multi-hosted machine - yup - this will bring you 
interesting results.

So what you probably need is your own javax.xml.transform.URIResolver. You 
probably need to write your own implementation of it and have tomcat use it. 
(A topic for which I have done neither)


BLAND, Geoff, GBM wrote:
> Marc,
> Thanks for the reply.
> We can put in an import of the form
> <xsl:import href="http://localhost/aaem/xsl/routesummarycontent.xsl" />
> and that works fine (for a single web server).
> But we have multiple web servers on the box (using different ports and
> different install paths) and they may be different versions (development,
> UAT, production) having different versions of routesummarycontent.xsl. If we
> use the import above all servers end up selecting the XSL for just one of
> the versions. 
> We don't want to have a different import for each version either as that
> will need modifying as we migrate updated versions between servers.
> What we need is a "relative" import, for example, 
> <xsl:import href="/xsl/routesummarycontent.xsl" />  <!-- doesn't work -->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message