Startup from a war file fails with Jetty server.

[GoogleCodeExporter]

What steps will reproduce the problem?

  I tried a couple of variations of  this and was able to trace the problems back to the same line of code.
  *  With Persevere 0.9.29 the startup failed on Windows when using a path that included spaces in the pathname to where Jetty unpacked the war file.
  *  With Persevere 1.0.2 the startup failed on a Mac when Jetty used a temporary path that included "+" (plus sign) characters in the file name. 

  Solution included below.

What is the expected output? What do you see instead?

The expected behavior is that persevere will start up.

What happens is that there is an error finding the config directory.

What version of the product are you using? On what operating system?

Persevere version 
Windows XP operating system

Please provide any additional information below.

I have traced the problem to line 105 of the file 
org/persevere/data/DataSource.java:
    webInfPath = webInfLocation.substring("file:/".length());     // v0.9.29
    webInfPath = URLDecoder.decode(webInfLocation.substring("file:/".length()));  // v1.0.2

The first version line gets the string version of a URI stored in 
webInfLocation and attempts to do its own parsing of the URI.  The bug occurs 
when there are spaces in the folder names in the path.  The spaces will be URL 
encoded as "%20", which will then cause the file not to be found.

The second version uses URLDecoder.decode, which will handle the %20 encoding 
of spaces, but it also does more, namely converting "+" to <space>, which 
causes a different mode of failure.

What needs to happen is that the URI has to be turned into a proper filename.  
I think that the most robust way to do that would be to use the following in 
place of the current code

    webInfPath = new File(new URI(webInfLocation)).getCanonicalPath();

and let the java File class handle the conversion of the URI into a filename 
and path.  That should also handle any issues with file separators, etc. as 
well.  This will require adding a new catch clause to the try block as well:

  catch (URISyntaxException e) {
    ...
  }

I have tested this modification in my persevere installation and it solves both 
problems.

Original issue reported on code.google.com by taruss2...@gmail.com on 22 Feb 2011 at 11:20