Hi,

are you directly instantiating a FileSource object yourself?
Or are you using the SourceResolver?
The source implementations (like FileSource etc.) are not meant to be directly instantiated. The source resolver is the only service to create source objects. The implementation of the source resolver should take care of special OS paths like drive letters on windows etc.

Carsten

[EMAIL PROTECTED] wrote:
[Using a friend's computer.]  Bug is obvious:
    public FileSource(String uri) throws SourceException, MalformedURLException
    {
        int pos = SourceUtil.indexOfSchemeColon(uri);
        if (pos == -1)
        {
            throw new MalformedURLException("Invalid URI : " + uri);
        }

        String scheme = uri.substring(0, pos);
        String fileName = uri.substring(pos + 1);
        fileName = SourceUtil.decodePath(fileName);
        this.init(scheme, new File(fileName));
    }

Anything before the first colon is treated as the protocol.  Are
single letter schemes illegal? Or is there a "not a real OS" flag to
check for a  "drive letter"?

This code will also fail for real operating systems because it assumes
the String is a URI.  new FileSource("/var/myfile") will throw an
Exception.

I misunderstood the API doc:
   Builds a FileSource given an URI, which doesn't necessarily have to
start with "file:"
That seems to imply a FileSource can be created from a filepath
string.  Guess it means a FileSource can be created from other
protocols.

The API doc needs to explicitly exclude filepaths.  I am surprised a
FileSource cannot be created from a filepath String.  That seems like
the most common operation.

I can fix my code with a simple "file://" prefix.

solprovider

On Jan 28, 2008 5:02 AM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
this seems to be a bug - can you file a bug please?

Thanks
Carsten


[EMAIL PROTECTED] wrote:
FileSource incorrectly repeats the drive specification on Windows.
This causes errors retrieving files relative to the FileSource.

We are receiving this error using excalibur-sourceresolve-2.2.3.jar
(from Cocoon-2.1.11)
cause: java.io.FileNotFoundException: F:\F:\mydirectory\page2xhtml.xsl
(The filename, directory name, or volume label syntax is incorrect)
org.apache.cocoon.ProcessingException: Unable to get transformer
handler for F:///F:/myDirectory/page2xhtml-homepage.xsl

FILE: page2xhtml-homepage.xsl (relatively imports page2xhtml.xsl.)
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:import href="page2xhtml.xsl"/>
</xsl:stylesheet>

JAVA TEST:
import java.io.File;
import org.apache.excalibur.source.Source;
import org.apache.excalibur.source.impl.FileSource;
public class mySourceFactory implements SourceFactory{
  public Source getSource(String location, Map parameters) throws
IOException, MalformedURLException {
      File file = new File(myDirectory, location);
      if(!file.exists()) throw new IOException("Bad file.");
      filepath = file.getAbsolutePath(); //Original assignment is
      print(filepath);  \\ "F:\myDirectory\myfile.xsl"
      FileSource source = new FileSource(filepath);
      print(source.getURI()); \\"F:///F:/myDirectory/myfile.xslt"
      return source;
   }
}

Are we doing something wrong?  Does FileSource.getURI() contain a bug?
 What is the workaround?

TIA,
solprovider

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Carsten Ziegeler
[EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to