please read -- need to specify current working directory

[Victor Wynnytsky <wy...@yahoo.com>]

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/

Re: please read -- need to specify current working directory

["Craig R. McClanahan" <cr...@apache.org>]

On Sun, 8 Jul 2001, Donald Ball wrote:

> On Sun, 8 Jul 2001, Victor Wynnytsky wrote:
> 
> > [ 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).
> 
> you should check out the javax.xml.transform.URIResolver interface. you
> can have trax transformers call one of your methods to resolve uris.
> 

You should really do as Donald suggests.  One of the flaws to your current
approach is that "user.dir" is global to all webapps, so as soon as you
have your apps processing multiple requests at the same time, you're going
to run into race conditions.

> - donald
> 
> 

Craig McClanahan

Re: please read -- need to specify current working directory

[Donald Ball <ba...@webslingerZ.com>]

On Sun, 8 Jul 2001, Victor Wynnytsky wrote:

> [ 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).

you should check out the javax.xml.transform.URIResolver interface. you
can have trax transformers call one of your methods to resolve uris.

- donald