W3C home > Mailing lists > Public > xproc-dev@w3.org > July 2009

RE: Calumet and relative URIs

From: Michael Sokolov <sokolov@ifactory.com>
Date: Tue, 28 Jul 2009 18:31:51 -0400
Message-Id: <200907282206.n6SM6sdN001481@hades.falutin.net>
To: "'David A. Lee'" <dlee@calldei.com>, "'Florent Georges'" <fgeorges@gmail.com>
Cc: <Toman_Vojtech@emc.com>, <xproc-dev@w3.org>
Wouldn't it be more Java-friendly to resolve uris against the classpath in a
JVM context?  I think that in the case you are running on the command line
against a jar in the same folder as your working directory, this could
amount to the same thing as CWD while surviving threads attempts to alter
the working directory.  The benefit is that it becomes possible to bundle
resources (like pipelines, documents, and so on) with your java class in an
EE context and have them loaded from the context.  This can mean loading
from within a jar (or war), or from an exploded war in a J2EE container.
Just a thought...


From: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] On Behalf
Of David A. Lee
Sent: Thursday, July 23, 2009 10:22 AM
To: Florent Georges
Cc: Toman_Vojtech@emc.com; xproc-dev@w3.org
Subject: Re: Calumet and relative URIs

Ignoreing JVM's where CWD is simply not implemented ...

CWD is "vague" IMHO in Java because its process-wide not thread specific. 
If you run multi-threads there is no way to set the CWD differently within
each thread.
Depending on your program that can be "just fine" or "a total stumbling

An example.
In xmlsh, for example, 'sub shells' are run as seperate threads.  These
seperate threads can "cd" to different directories
then run other programs such as xslt or calabash or whatever.
so you can do like this

( cd /foo ; xslt < file.xml ) &
( cd /bar ; xslt < file.xml ) &

In a 'normal unix shell' the implementation is obvious, you simply do a
chdir() and the OS takes over.  Its process-wide and settable.

In Java, there is no such thing as 'chdir()' that can operate on a thread
basis.  There's actually no 'chdir' at all.
I have largely faked this out by creating a thread specific version of the
System properties ... this *mostly* works.
That is any code entirely in java which uses the system properties for the
CWD as they are supposed to works, but *SOME* Internal java code,
especially in the File API's dont do this, they go directly to the OS for
the CWD.  which hasnt changed, and even if I wrote a JNI to change it,
cant be per-thread.   I've been fortunate and have been able to work around
this ugly thing in all cases I've found so far, but it is very very tricky,
and whenever I add a new library I discover new ways it can break.

Thats why I say CWD is  'vague' in Java.

David A. Lee





Florent Georges wrote: 

2009/7/23 David A. Lee wrote:


Now there's always room for a "third way"


  Of course ;-)  And the idea to allow an explicit base URI to resolve

all input documents could be useful I guess, even from within Java

(while I do not really agree that CWD is a vague concept in Java, I

agree though it is vague in Java EE environments, where I expect XProc

to be widely used.)

Received on Tuesday, 28 July 2009 22:32:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:16:48 UTC