commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <sco...@javactivity.org>
Subject Re: [VFS and Net] Dealing with non-standard FTP servers
Date Sun, 19 Sep 2004 14:57:09 GMT
Sorry, please disregard my earlier reply.  I didn't read your original 
carefully enough.  Mario has provided one workaround.  I would suggest that 
VFS should be enhanced to take advantage of this little-known capability of 
Commons-Net.  I have had it in the back of my mind to do the same for Ant but 
have not found the time yet.


On Sunday 19 September 2004 9:53 am, Steve Cohen wrote:
> On Friday 17 September 2004 1:01 pm, Michael D. Hirsch wrote:
> > Hello,
> >
> > I'm new to this list, but I've been a happy user of commons-vfs for
> > several months, now.  It's saved me tons of work, but now I'm running up
> > against what I think are its limits.  I'm looking for advice on how to
> > get around a problem.
> >
> > I am is using commons-vfs to retrieve files from various sites.  In
> > particular, I'm now trying to get files from a server which is not
> > supported in the standard collection of FTPFileEntryParsers.
> >
> > There are several obstacles for me to do this--some are of my own making
> > and others are in the commons code.  I'll try to separate them out.
> >
> > The main problem is that even though the server presents non-standard
> > file lists, it claims to be of system type "unix".  This means that
> > commons-net will attempt to  parse it like a unix server, and that
> > doesn't work on this output.
> >
> > I could define my own FtpFileEntryParser and register it with
> > DefaultFTPFileEntryParserFactory, but there doesn't seem to be a way to
> > register new parsers--it appears to be hard coded into
> > createFileEntryParser in DefaultFTPFileEntryParserFactory.  Even worse,
> > that wouldn't work cause I can't distinguish this server from a unix
> > server.
> >
> > Another option is to explicitly pass the FQCN for my new parser into
> > DefaultFTPFileEntryParserFactory, but there I'm stymied because, AFAICT,
> > there is no way to pass the FQCN through the vfs layer to the net layer.
> >
> > I keep hoping that I'm just missing something in the API that lets me
> > tell VFS what I really want to do at the net layer.  I need to be able to
> > set the FQCN for the FTPFileEntryParser to use on a given connection.
> >
> > Does anyone have any suggestions for how to proceed?  I'm not opposed to
> > changing the vfs or net code if you think the changes would be accepted
> > back into CVS.
> >
> > Thanks,
> >
> > Michael Hirsch
>
> You are missing something in the API.
> Here is the source for
> DefaultFTPFileEntryParserFactory.createFileEntryParser():
>
> Note that the first thing it tries to do is resolve the key parameter as a
> fully qualified class name of a class derived from FTPFileEntryParser. 
> Only when that fails, does the behavior of parsing key as a SYST return
> value kick in.
>
>     public FTPFileEntryParser createFileEntryParser(String key)
>     {
>         Class parserClass = null;
>         try
>         {
>             parserClass = Class.forName(key);
>             return (FTPFileEntryParser) parserClass.newInstance();
>         }
>         catch (ClassNotFoundException e)
>         {
>             String ukey = null;
>             if (null != key)
>             {
>                 ukey = key.toUpperCase();
>             }
>             if (ukey.indexOf("UNIX") >= 0)
>             {
>                 return createUnixFTPEntryParser();
>             }
>             else if (ukey.indexOf("VMS") >= 0)
>             {
>                 return createVMSVersioningFTPEntryParser();
>             }
> ...
>
> So how would you use this to create and use your own parser?
> The easiest way is to call
> FTPClient.listFiles(String parserKey, String pathname) passing in the fully
> qualified name of your class as the first parameter.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message