You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@coredevelopers.net> on 2003/08/26 14:49:43 UTC

[core] Directories w/spaces

Looks like the deployment system is not very happy with directories 
with spaces in the path.  I looked into this some but I am stumped with 
how to fix this right now.

URI does not like a space in its spec, but URL is just fine with this.  
ServiceDeploymentPlanner is taking its DeployURL and turning it into a 
URI, which fails if the URL has a space.

I tried a few hacks to get around this, but then other bits of the 
system fail from the space in the URL too.

Is there a global solution to this problem, so we can translate a 
urlspec into a URL which will also work for a URI and not break reading 
content from file URLs too?

--jason


Re: [core] Directories w/spaces

Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 26, 2003, at 14:33 Europe/London, Jason Dillon wrote:

> It is a problem when someone say installs into c:\Program Files... 
> would be nice to solve.

Not only problems when Geronimo is installed into c:\Program Files, but 
it may be a problem when a library is installed in c:\Program Files and 
is referred to by a classpath (e.g. a web-app needing a driver from 
c:\Program Files\IBM\DB2\java\db2java.zip)

Alex.


Re: [core] Directories w/spaces

Posted by Jason Dillon <ja...@coredevelopers.net>.
It is a problem when someone say installs into c:\Program Files... 
would be nice to solve.

--jason


On Tuesday, August 26, 2003, at 08:24  PM, James Strachan wrote:

> Why do we need to support directories with spaces in them?
>
>
> On Tuesday, August 26, 2003, at 01:49  pm, Jason Dillon wrote:
>
>> Looks like the deployment system is not very happy with directories 
>> with spaces in the path.  I looked into this some but I am stumped 
>> with how to fix this right now.
>>
>> URI does not like a space in its spec, but URL is just fine with 
>> this.  ServiceDeploymentPlanner is taking its DeployURL and turning 
>> it into a URI, which fails if the URL has a space.
>>
>> I tried a few hacks to get around this, but then other bits of the 
>> system fail from the space in the URL too.
>>
>> Is there a global solution to this problem, so we can translate a 
>> urlspec into a URL which will also work for a URI and not break 
>> reading content from file URLs too?
>>
>> --jason
>>
>>
>
> James
> -------
> http://radio.weblogs.com/0112098/
>


Re: [core] Directories w/spaces

Posted by James Strachan <ja...@yahoo.co.uk>.
Why do we need to support directories with spaces in them?


On Tuesday, August 26, 2003, at 01:49  pm, Jason Dillon wrote:

> Looks like the deployment system is not very happy with directories 
> with spaces in the path.  I looked into this some but I am stumped 
> with how to fix this right now.
>
> URI does not like a space in its spec, but URL is just fine with this. 
>  ServiceDeploymentPlanner is taking its DeployURL and turning it into 
> a URI, which fails if the URL has a space.
>
> I tried a few hacks to get around this, but then other bits of the 
> system fail from the space in the URL too.
>
> Is there a global solution to this problem, so we can translate a 
> urlspec into a URL which will also work for a URI and not break 
> reading content from file URLs too?
>
> --jason
>
>

James
-------
http://radio.weblogs.com/0112098/


Re: [core] Directories w/spaces

Posted by "Daniel S. Haischt" <me...@daniel.stefan.haischt.name>.
Jason Dillon wrote:

>> String configFromSomewhere = ....
>> File file = new File(new URI(URLEncoder(configFromSomewhere));
> 
> 
> Can you actually read a file using this?
> 

what i just did not read while using the URLEncoder class
is that it is meant to encode HTML form field values which
will be passed to a CGI etc..

that means it will not encode complete URLs. this is the
reason why the protocol (file:///) part gets for example
encoded to

  -> file%3A%2F%2F%2F

and finally according to the doc a whitespace gets
converted to a plus sign but according RFC 2396 you
will need a %20 escape sequence.

so i am wondering how the string 'configFromSomewhere'
gets encoded accordingly if it contains the protocol
part of an URL or whitespaces.

regards

daniel s. haischt
-- 



Re: [core] Directories w/spaces

Posted by Jason Dillon <ja...@coredevelopers.net>.
Do you have a strack trace?  And are using the latest from CVS?

--jason


On Tuesday, August 26, 2003, at 11:48  PM, Ned G wrote:

> Hi, my name is Ned G I have been following this email list for about a 
> few
> weeks, and I am new to all this. However I would like to help in 
> anyway I
> can.
> I have over 7 yrs experience in graphic and web development, and about 
> 4 yrs
> with Java, J2EE and PHP development.
>
> Thank you
>
>
> Note: I have tried to compile the code below on windows XP and Windows 
> 2003
> server
> code throws ArrayIndexOutOfBoundsException exception.
>
> -----Original Message-----
> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
> Sent: Wednesday, 27 August 2003 1:17 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: [core] Directories w/spaces
>
>
> On Tuesday, Aug 26, 2003, at 15:56 Europe/London, Jason Dillon wrote:
>
>>> String configFromSomewhere = ....
>>> File file = new File(new URI(URLEncoder(configFromSomewhere));
>>
>> Can you actually read a file using this?
>
> The test code that I used allowed me to get the last modification date
> of the file, so the file clearly works in the right place. I did not
> test it using a FileInputStream or FileReader.
>
> I modified the example code pasted last time to get
>
> import java.net.*;
> import java.io.*;
> public class Test {
>    public static void main(String args[]) throws Exception {
>      String u = args[0];
>      System.out.println("\"" + u + "\"");
>      System.out.println(new URI(u));
>      System.out.println(new File(new URI(u)));
>      File file = new File(new URI(u));
>      FileInputStream fin = new FileInputStream(file);
>      byte buffer[] = new byte[1024];
>      fin.read(buffer);
>      System.out.println("Data:");
>      System.out.write(buffer);
>      System.out.println("eData");
>
>      }
>      }
>
> and it worked seamlessly at printing out the contents of the file with
> a %20 in the directory space.
>
> (Note: this is tested/run on Mac OS X.2.6 using Java 1.4; it may be
> different on 'doze systems, but I wouldn't expect there to be a
> difference)
>
> Note that as Daniel says, you may need to ensure that the protocol
> isn't also encoded as part of the URI, but there are constructors in
> the URI itself that allows for this:
>
> http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html
>
> o The single-argument  constructor requires any illegal characters in
> its argument to be  quoted and preserves any escaped octets and other
> characters that  are present.
> o The multi-argument constructors quote illegal characters as  required
> by the components in which they appear. The percent character  ('%') is
> always quoted by these constructors. Any other  characters are
> preserved.
>
> If you are appending the 'file:///' on yourself (and the file is being
> read from somwhere else) then using a multi-part URI will solve this
> problem for you, encoding where necessary.
>
> new URI("file",null,myFileName,null) // encodes right part
> automatically. First null is 'host' (may be empty for file URIs),
> second null is fragment (i.e. after #)
>
> Regards,
>
> Alex.
>


Re: [core] Directories w/spaces

Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 26, 2003, at 17:48 Europe/London, Ned G wrote:

> Note: I have tried to compile the code below on windows XP and Windows 
> 2003
> server
> code throws ArrayIndexOutOfBoundsException exception.

That only happens when run without an argument. It was a demonstration 
piece of code, and when running you should provide the name of a file 
with a space in the middle encoded as %20.

java Test "file:///C:\Program%20Files\test.txt"

If run without an argument, you'll get the AIOOBE. It was meant as a 
demonstration that it's possible to use a URI to do this.

note that if the URI instantiation is changed to

File file = new File(new URI("file",null,u,null));

then you don't need to specify file:/// and nor do you need to escape 
the space. So using the above in place, you can do
java Test "c:\Program Files\test.txt"

and it will automatically create an escaped space using the URI.

Alex.

> import java.net.*;
> import java.io.*;
> public class Test {
>    public static void main(String args[]) throws Exception {
>      String u = args[0];
>      System.out.println("\"" + u + "\"");
>      System.out.println(new URI(u));
>      System.out.println(new File(new URI(u)));
>      File file = new File(new URI(u));
>      FileInputStream fin = new FileInputStream(file);
>      byte buffer[] = new byte[1024];
>      fin.read(buffer);
>      System.out.println("Data:");
>      System.out.write(buffer);
>      System.out.println("eData");
>
>      }
>      }


RE: [core] Directories w/spaces

Posted by Ned G <ne...@optushome.com.au>.
Hi, my name is Ned G I have been following this email list for about a few
weeks, and I am new to all this. However I would like to help in anyway I
can.
I have over 7 yrs experience in graphic and web development, and about 4 yrs
with Java, J2EE and PHP development.

Thank you


Note: I have tried to compile the code below on windows XP and Windows 2003
server
code throws ArrayIndexOutOfBoundsException exception.

-----Original Message-----
From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
Sent: Wednesday, 27 August 2003 1:17 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: [core] Directories w/spaces


On Tuesday, Aug 26, 2003, at 15:56 Europe/London, Jason Dillon wrote:

>> String configFromSomewhere = ....
>> File file = new File(new URI(URLEncoder(configFromSomewhere));
>
> Can you actually read a file using this?

The test code that I used allowed me to get the last modification date
of the file, so the file clearly works in the right place. I did not
test it using a FileInputStream or FileReader.

I modified the example code pasted last time to get

import java.net.*;
import java.io.*;
public class Test {
   public static void main(String args[]) throws Exception {
     String u = args[0];
     System.out.println("\"" + u + "\"");
     System.out.println(new URI(u));
     System.out.println(new File(new URI(u)));
     File file = new File(new URI(u));
     FileInputStream fin = new FileInputStream(file);
     byte buffer[] = new byte[1024];
     fin.read(buffer);
     System.out.println("Data:");
     System.out.write(buffer);
     System.out.println("eData");

     }
     }

and it worked seamlessly at printing out the contents of the file with
a %20 in the directory space.

(Note: this is tested/run on Mac OS X.2.6 using Java 1.4; it may be
different on 'doze systems, but I wouldn't expect there to be a
difference)

Note that as Daniel says, you may need to ensure that the protocol
isn't also encoded as part of the URI, but there are constructors in
the URI itself that allows for this:

http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html

o The single-argument  constructor requires any illegal characters in
its argument to be  quoted and preserves any escaped octets and other
characters that  are present.
o The multi-argument constructors quote illegal characters as  required
by the components in which they appear. The percent character  ('%') is
always quoted by these constructors. Any other  characters are
preserved.

If you are appending the 'file:///' on yourself (and the file is being
read from somwhere else) then using a multi-part URI will solve this
problem for you, encoding where necessary.

new URI("file",null,myFileName,null) // encodes right part
automatically. First null is 'host' (may be empty for file URIs),
second null is fragment (i.e. after #)

Regards,

Alex.


Re: [core] Directories w/spaces

Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 26, 2003, at 15:56 Europe/London, Jason Dillon wrote:

>> String configFromSomewhere = ....
>> File file = new File(new URI(URLEncoder(configFromSomewhere));
>
> Can you actually read a file using this?

The test code that I used allowed me to get the last modification date 
of the file, so the file clearly works in the right place. I did not 
test it using a FileInputStream or FileReader.

I modified the example code pasted last time to get

import java.net.*;
import java.io.*;
public class Test {
   public static void main(String args[]) throws Exception {
     String u = args[0];
     System.out.println("\"" + u + "\"");
     System.out.println(new URI(u));
     System.out.println(new File(new URI(u)));
     File file = new File(new URI(u));
     FileInputStream fin = new FileInputStream(file);
     byte buffer[] = new byte[1024];
     fin.read(buffer);
     System.out.println("Data:");
     System.out.write(buffer);
     System.out.println("eData");

     }
     }

and it worked seamlessly at printing out the contents of the file with 
a %20 in the directory space.

(Note: this is tested/run on Mac OS X.2.6 using Java 1.4; it may be 
different on 'doze systems, but I wouldn't expect there to be a 
difference)

Note that as Daniel says, you may need to ensure that the protocol 
isn't also encoded as part of the URI, but there are constructors in 
the URI itself that allows for this:

http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html

o The single-argument  constructor requires any illegal characters in 
its argument to be  quoted and preserves any escaped octets and other 
characters that  are present.
o The multi-argument constructors quote illegal characters as  required 
by the components in which they appear. The percent character  ('%') is 
always quoted by these constructors. Any other  characters are 
preserved.

If you are appending the 'file:///' on yourself (and the file is being 
read from somwhere else) then using a multi-part URI will solve this 
problem for you, encoding where necessary.

new URI("file",null,myFileName,null) // encodes right part 
automatically. First null is 'host' (may be empty for file URIs), 
second null is fragment (i.e. after #)

Regards,

Alex.


Re: [core] Directories w/spaces

Posted by Jason Dillon <ja...@coredevelopers.net>.
> String configFromSomewhere = ....
> File file = new File(new URI(URLEncoder(configFromSomewhere));

Can you actually read a file using this?

--jason


Re: [core] Directories w/spaces

Posted by Alex Blewitt <Al...@ioshq.com>.
How are you running it against File? Java 1.4 has a constructor that 
takes a URI, but no constructor that takes a URL.

Are you using the URL.toString() to obtain a file reference?

I have created a URI based on 'file:///tmp/here%20there' and it works 
as expected when accessing a file. Printing it out unencodes it, but 
passing the URI in its entirety to a File constructor allows the file 
to be accessed seamlessly.

import java.net.*;
import java.io.*;
public class Test {
   public static void main(String args[]) throws Exception {
     String u = args[0];
     System.out.println("\"" + u + "\"");
     System.out.println(new URI(u));
     System.out.println(new File(new URI(u)));
     System.out.println(new File(new URI(u)).lastModified());
     }
     }

java Test "file:///tmp/here%20there"

It would seem that all you need to do is replace URL with URI, and 
ensure that the argument to URI is encoded. You will note that running 
it with java Test "file:///tmp/here there" results in an 
IllegalCharacterException.

String configFromSomewhere = ....
File file = new File(new URI(URLEncoder(configFromSomewhere));

works fine with spaces.

Alex.

On Tuesday, Aug 26, 2003, at 15:17 Europe/London, Jason Dillon wrote:

> A URLEncoded string will cause URL() to puke.  And probably won't work 
> with File() either.
>
> --jason
>
>
> On Tuesday, August 26, 2003, at 09:12  PM, Daniel S. Haischt wrote:
>
>> just as a starting point (don't know whether it helps or not, tho).
>>
>> what about:
>>
>> String test1 = java.net.URLEncoder.encode(
>>   "file:///Program Files/MyProgram/test.txt", "UTF-8");
>> String test2 = java.net.URLDecoder.decode(
>>   test1, "UTF-8");
>>
>> System.out.println(test1 + "\n" + test2);
>>
>> it would decode/encode your strings which are containing
>> whitespaces.
>>
>> regards
>>
>> daniel s. haischt
>> --
>>
>> James Strachan wrote:
>>> On Tuesday, August 26, 2003, at 02:37  pm, Alex Blewitt wrote:
>>>> On Tuesday, Aug 26, 2003, at 13:49 Europe/London, Jason Dillon 
>>>> wrote:
>>>>
>>>>> Looks like the deployment system is not very happy with 
>>>>> directories with spaces in the path.  I looked into this some but 
>>>>> I am stumped with how to fix this right now.
>>>>>
>>>>> URI does not like a space in its spec, but URL is just fine with 
>>>>> this.  ServiceDeploymentPlanner is taking its DeployURL and 
>>>>> turning it into a URI, which fails if the URL has a space.
>>>>>
>>>>> I tried a few hacks to get around this, but then other bits of the 
>>>>> system fail from the space in the URL too.
>>>>>
>>>>> Is there a global solution to this problem, so we can translate a 
>>>>> urlspec into a URL which will also work for a URI and not break 
>>>>> reading content from file URLs too?
>>>>
>>>>
>>>> URI spaces should be escaped into %20 IIRC. So 'new URI("Hello 
>>>> World")' may fail, while 'new URI("Hello%20World")' may work. Of 
>>>> course, it then depends on the URI being properly unencoded at the 
>>>> other end where required.
>>> Thats a HTTP thing isn't it? Doesn't work for file based URIs AFAIK.
>>> James
>>> -------
>>> http://radio.weblogs.com/0112098/
>>
>>
>


Re: [core] Directories w/spaces

Posted by Jason Dillon <ja...@coredevelopers.net>.
A URLEncoded string will cause URL() to puke.  And probably won't work 
with File() either.

--jason


On Tuesday, August 26, 2003, at 09:12  PM, Daniel S. Haischt wrote:

> just as a starting point (don't know whether it helps or not, tho).
>
> what about:
>
> String test1 = java.net.URLEncoder.encode(
>   "file:///Program Files/MyProgram/test.txt", "UTF-8");
> String test2 = java.net.URLDecoder.decode(
>   test1, "UTF-8");
>
> System.out.println(test1 + "\n" + test2);
>
> it would decode/encode your strings which are containing
> whitespaces.
>
> regards
>
> daniel s. haischt
> --
>
> James Strachan wrote:
>> On Tuesday, August 26, 2003, at 02:37  pm, Alex Blewitt wrote:
>>> On Tuesday, Aug 26, 2003, at 13:49 Europe/London, Jason Dillon wrote:
>>>
>>>> Looks like the deployment system is not very happy with directories 
>>>> with spaces in the path.  I looked into this some but I am stumped 
>>>> with how to fix this right now.
>>>>
>>>> URI does not like a space in its spec, but URL is just fine with 
>>>> this.  ServiceDeploymentPlanner is taking its DeployURL and turning 
>>>> it into a URI, which fails if the URL has a space.
>>>>
>>>> I tried a few hacks to get around this, but then other bits of the 
>>>> system fail from the space in the URL too.
>>>>
>>>> Is there a global solution to this problem, so we can translate a 
>>>> urlspec into a URL which will also work for a URI and not break 
>>>> reading content from file URLs too?
>>>
>>>
>>> URI spaces should be escaped into %20 IIRC. So 'new URI("Hello 
>>> World")' may fail, while 'new URI("Hello%20World")' may work. Of 
>>> course, it then depends on the URI being properly unencoded at the 
>>> other end where required.
>> Thats a HTTP thing isn't it? Doesn't work for file based URIs AFAIK.
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>
>


Re: [core] Directories w/spaces

Posted by "Daniel S. Haischt" <me...@daniel.stefan.haischt.name>.
just as a starting point (don't know whether it helps or not, tho).

what about:

String test1 = java.net.URLEncoder.encode(
   "file:///Program Files/MyProgram/test.txt", "UTF-8");
String test2 = java.net.URLDecoder.decode(
   test1, "UTF-8");

System.out.println(test1 + "\n" + test2);

it would decode/encode your strings which are containing
whitespaces.

regards

daniel s. haischt
--

James Strachan wrote:
> 
> On Tuesday, August 26, 2003, at 02:37  pm, Alex Blewitt wrote:
> 
>> On Tuesday, Aug 26, 2003, at 13:49 Europe/London, Jason Dillon wrote:
>>
>>> Looks like the deployment system is not very happy with directories 
>>> with spaces in the path.  I looked into this some but I am stumped 
>>> with how to fix this right now.
>>>
>>> URI does not like a space in its spec, but URL is just fine with 
>>> this.  ServiceDeploymentPlanner is taking its DeployURL and turning 
>>> it into a URI, which fails if the URL has a space.
>>>
>>> I tried a few hacks to get around this, but then other bits of the 
>>> system fail from the space in the URL too.
>>>
>>> Is there a global solution to this problem, so we can translate a 
>>> urlspec into a URL which will also work for a URI and not break 
>>> reading content from file URLs too?
>>
>>
>> URI spaces should be escaped into %20 IIRC. So 'new URI("Hello 
>> World")' may fail, while 'new URI("Hello%20World")' may work. Of 
>> course, it then depends on the URI being properly unencoded at the 
>> other end where required.
> 
> 
> Thats a HTTP thing isn't it? Doesn't work for file based URIs AFAIK.
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 



Re: [core] Directories w/spaces

Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 26, 2003, at 02:37  pm, Alex Blewitt wrote:

> On Tuesday, Aug 26, 2003, at 13:49 Europe/London, Jason Dillon wrote:
>
>> Looks like the deployment system is not very happy with directories 
>> with spaces in the path.  I looked into this some but I am stumped 
>> with how to fix this right now.
>>
>> URI does not like a space in its spec, but URL is just fine with 
>> this.  ServiceDeploymentPlanner is taking its DeployURL and turning 
>> it into a URI, which fails if the URL has a space.
>>
>> I tried a few hacks to get around this, but then other bits of the 
>> system fail from the space in the URL too.
>>
>> Is there a global solution to this problem, so we can translate a 
>> urlspec into a URL which will also work for a URI and not break 
>> reading content from file URLs too?
>
> URI spaces should be escaped into %20 IIRC. So 'new URI("Hello 
> World")' may fail, while 'new URI("Hello%20World")' may work. Of 
> course, it then depends on the URI being properly unencoded at the 
> other end where required.

Thats a HTTP thing isn't it? Doesn't work for file based URIs AFAIK.

James
-------
http://radio.weblogs.com/0112098/


Re: [core] Directories w/spaces

Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 26, 2003, at 14:42 Europe/London, Jason Dillon wrote:

>> URI spaces should be escaped into %20 IIRC. So 'new URI("Hello 
>> World")' may fail, while 'new URI("Hello%20World")' may work. Of 
>> course, it then depends on the URI being properly unencoded at the 
>> other end where required.
>
> I think %20 freaks out with file URLs though... :-(

File URLs in a URI, or File URIs ? Or using URI.getURL() ?

Alex.


Re: [core] Directories w/spaces

Posted by Jason Dillon <ja...@coredevelopers.net>.
> URI spaces should be escaped into %20 IIRC. So 'new URI("Hello 
> World")' may fail, while 'new URI("Hello%20World")' may work. Of 
> course, it then depends on the URI being properly unencoded at the 
> other end where required.

I think %20 freaks out with file URLs though... :-(

--jason


Re: [core] Directories w/spaces

Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 26, 2003, at 13:49 Europe/London, Jason Dillon wrote:

> Looks like the deployment system is not very happy with directories 
> with spaces in the path.  I looked into this some but I am stumped 
> with how to fix this right now.
>
> URI does not like a space in its spec, but URL is just fine with this. 
>  ServiceDeploymentPlanner is taking its DeployURL and turning it into 
> a URI, which fails if the URL has a space.
>
> I tried a few hacks to get around this, but then other bits of the 
> system fail from the space in the URL too.
>
> Is there a global solution to this problem, so we can translate a 
> urlspec into a URL which will also work for a URI and not break 
> reading content from file URLs too?

URI spaces should be escaped into %20 IIRC. So 'new URI("Hello World")' 
may fail, while 'new URI("Hello%20World")' may work. Of course, it then 
depends on the URI being properly unencoded at the other end where 
required.

Alex.