- From: Michael Sokolov <sokolov@ifactory.com>
- Date: Tue, 28 Jul 2009 18:31:51 -0400
- To: "'David A. Lee'" <dlee@calldei.com>, "'Florent Georges'" <fgeorges@gmail.com>
- Cc: <Toman_Vojtech@emc.com>, <xproc-dev@w3.org>
- Message-Id: <200907282206.n6SM6sdN001481@hades.falutin.net>
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... -Mike _____ 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 block". 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 dlee@calldei.com http://www.calldei.com http://www.xmlsh.org 812-482-5224 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