Hello, my name is Victor Wynnytsky
[ WHAT I NEED ]
I need each webapp to be able to set it's default directory. This can
be observed by looking at System.getProperty( user.dir ). When I saw
Tomcat4's new Context workDir= tag in server.xml I got all excited.
Unfortunately user.dir did not budge after setting this new tag.
[ WHAT I'M UP TO ]
6 months ago I was craving to build XSL web apps (no JSPs). For
testing XSLs I thoroughly enjoyed using the MSXML3 parser which can be
easily integrated into IE5 by simply downloading and installing it. I
wrote a couple sample applications where servlets build XML (SQL=DOM
or directly from disk) and in a servlet base class I take the XML
stream and transform it with Xalan. But what makes the base class VERY
cool, is that it first sniffs the client browser for XSL support
(presently it just looks for MSXML3) and if it's there it skips Xalan
and simply returns XML!!! It's a real trip to hits these apps from
different computers and when I do a view source some computers show
only XML.
[ HOW I WORK ]
When writing XSLs, I first write a sample XML file which points to the
XSL, and after each change I make to my XSL I refresh my IE5 to see the
impact. This process is quite pleasant. And compared with writing
JSPs, this iterative process doesn't depend on any back end resources
(SQL, Tomcat, etc).
[ WHY I NEED THIS ]
It is very common for an XSL page to include another XSL page.
An XSL page called orderDetail.xsl might begin like this...
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=1.0
xsl:import href=nav.xsl/
xsl:import href=grid.xsl/
xsl:template match=/
...
The focus of my problem is on the xsl:import tag. I'm using a *web*
path there, and I'm sure everyone using Xalan is using an *file* path.
The above sample XSL shows orderDetail.xsl trying to refer to nav.xsl
in the same folder (ie: web path).
For an XSL client this is not a problem:
first it loads http://myhost/myapp/orderDetail.xsl
then it loads http://myhost/myapp/nav.xsl
But if I'm transforming with Xalan, in Java I can only specify a file
path for the outer most xsl...
/home/vic/fubar/web/orderDetail.xsl
...and then Xalan will erroneously try to process the imports relative
to the default directory...
tomcat/bin/nav.xsl
tomcat/bin/grid.xsl
So you see, the reason I need to use web paths (ie: the reason I'm
special:) is because I want to maintain one set of XSL files that will
leverage client side XSL support if available, and defer to Xalan
otherwise.
PS: the benefits of client side XSL transformation are enormous. In
terms of performance, the XSL-CSS-JS pages are cached by the browser so
only the data is transmitted every time and the CPU cycles spent
building HTML from a template is now deferred to the client. In terms
of decoupling presentation and business logic, XSL page developers can
take sample XML input files and work completely off line from all back
end resources.
[ THE WORK AROUND (embarrassed to say) ]
At EVERY page request I actually change Tomcat's default directory to
be the webapp's document root. And yes, I have multiple webapps
running in the same Tomcat instance, all changing this directory to be
what they want!!!
String root =
getServletConfig().getServletContext().getRealPath(/);
System.setProperty( user.dir, root );
Perhaps I could make this solution safe by putting my Xalan
transformation code in a method that is both static and synchronized,
but that is a looming bottleneck.
Please share this document with the Jakarta XML team. I suspect it's
not feasible to efficiently give each webapp it's own default
directory, and yet it would be a very simple task for the Xalan team to
add a mechanism to their parser allowing me to specify a relative base directory.
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
