/**
* Utility method to extract URL from file in safe manner.
*
* @param file the file
* @return the URL representation of file
*/
private String getURLAsString( final File file )
{
try
{
return file.toURL().toExternalForm();
}
catch( final MalformedURLException mue )
{
return null;
//should never occur
}
}As you can see, it relies on the java.io.File.toURL() method to convert the file into a URL suitable for an InputSource. It has always been a misnomer that a File can be turned into a URL beause a URL requires a protocol (i.e. http, ftp, etc.). Instead, the "file://" URLs are not URLs at all, but URIs which are a more general form. That is the 'L' in URL is for Locator and carries with it the definition of what protocol to use, whereas a the 'I' in URI for, I think, Indicator, and carries no such requirement of a protocol. After all, "file:" is not an actual protocol.
Anyways, through experimentation, I've determined that the above code, as used in Phoenix's ConfigurationBuilder to read XML files, will cause certain XML parsers to fail in my situation. My situation is that my XML file's path has a space in it. Certain XML parsers means the newer versions of Xerces. Ths is specifically what the FAQ I mentioned in my earlier messages talks about, but without a reasonable solution.
There are two solutions I've found:
1. Do not use a path with spaces. In this case, that means don't install James into a path with spaces. Using a path with spaces and always using the 8.3 naming (i.e. C:\Progra~1 instead of C:\Program Files) will not work. I tried that, but Java still somehow manages to get the OS to turnit into the real non-8.3 pathname so the spaces re-appear.
2. Change the code in Phoenix. Now, I'm not sure because Phoenix.Excalibur/Avalon/etc.'s relationships confuses the heck out of me, but I think Phoenix is defunct. Anyways, if not, or if it is but we pretendedit isn't, I have to solutions to fix this:
2a. JDK 1.4 added a 'toURI()' method to File which returns a URI. Calling .toString() on a URI properly escapes spaces as '%20'. Here's my test code:
private static String getURLAsString3( final File file )
{
return file.toURI().toString();
}2b. Before JDK 1.4, the escaping must be done manually. My code snippet below takes care of spaces, but a more general escaping solution would really be needed:
private static String getURLAsString2( final File file )
{
String url = getURLAsString(file);
StringBuffer fixedUpUrl = new StringBuffer();
int lastIndex = 0;
while(true) {
int spaceIndex = url.indexOf(' ', lastIndex);
// Tail?
if(spaceIndex < 0) {
fixedUpUrl.append(url.substring(lastIndex));
break;
}
fixedUpUrl.append(url.substring(lastIndex, spaceIndex));
fixedUpUrl.append("%20");
lastIndex = spaceIndex + 1;
}
return fixedUpUrl.toString();
}There may be one other solution. Older versions of Xerces didn't exhibit this problem. I'm not sure if they tightened things up, or removed an intentional work around, but according to the XML specifications, it never should've worked (as far as I understand it). But, if we were to switch to an older, less-proper version of Xerces, it should work. But does Phoenix/James need the features of the latest Xerces?
Regards, Brian.
Noel J. Bergman wrote:
java.net.MalformedURLException: no protocol: ../conf/james-fetchmail.xml
Some people have reported that error. I can't reproduce it here. I am wondering if the people who are reproducing it have done something different in their Java environment.
I plan to take a look at it with the newer Avalon code, and see what we need to do there.
--- Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
