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)
-Tim
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
