Re: Calumet and relative URIs

I've done this before in custom code, and its a great idea to be able to 
bundle "script data" (say xproc, xquery, xslt) with the JAR files.  It 
was particularly useful when I had an .xquery file that needed to load a 
module but insisted on looking in the current directory instead of the 
.jar file ! ug.

But should it be the "default"? That would add yet more confusion, IMHO.




David A. Lee
dlee@calldei.com  
http://www.calldei.com
http://www.xmlsh.org
812-482-5224



Michael Sokolov wrote:
> 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.)
>>
>>       
>