Your last post confused me. The SourceResolver uses the configured
SourceFactory(s) to create and return a Source. When creating a
SourceFactory, using the SourceResolver is asking for an infinite
loop. The current implementations of our two custom SourceFactories
return a FileSource (although the SourceResolvers will return other
Sources when pulling from JCR or RDBMS in the future.)
Our StringSource was designed for returning errors from
SourceFactories. The class should always be directly instantiated in
a SourceFactory. This class could be added to the
org.apache.excalibur.source.impl package. The API doc states:
Creates a Source from a String, Document, Node, or XMLizable.
If a String does not start with "<", it is wrapped with <text> tags.
If a String does not start with "<?xml", an XML header is added.
I cannot think of a purpose for StringSourceFactory. No
StringSourceFactory exists so SourceResolver could not create a
StringSource.
How to resolve my "bug" depends on the goals of the Excalibur project.
If Excalibur's gola is simple code, fix the documentation to remove
the confusion. The FileSource single-argument constructor API should
be changed to make clear that a protocol/scheme is required. (Builds
a FileSource given an URI, which doesn't necessarily have to start
with "file:")
If Excalibur's goal is ease of use, fix the FileSource to handle more
input variations.
solprovider
On 1/29/08, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> 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
> Carsten Ziegeler
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
