tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Lall" <>
Subject Fw: please read -- need to specify current working directory
Date Sat, 08 Jul 2000 23:25:18 GMT

Make Unlimited phone calls from your PC to ANY phone in the World!
----- Original Message -----
From: Victor Wynnytsky <>
To: <>
Sent: Sunday, July 08, 2001 4:55 PM
Subject: please read -- need to specify current working directory

> Hello, my name is Victor Wynnytsky
> 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).
> 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=""
> 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
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail

View raw message