I see your point, but it doesn't really solve the problem that I'm seeing.
Sure, it would make it easier for any halfway competent java programmer to
subclass the parser factory, but I believe most of our users are not in this
boat. They want to import our jar into some other application like Ant and
have it work seamlessly without configuration issues or writing code.
So while I'm not opposed to your change - if you submit it as a patch, I'll
commit it - it doesn't really get to the core of the problem that I've been
outlining - a truly automatic detection scheme.
So let's here some more comments: how nasty is this DIRSTYLE toggling thing
that some of us are just hearing about for the first time now?
On Thursday 01 April 2004 12:47 am, Mario Ivankovits wrote:
> Steve Cohen wrote:
> >Wow, that's nasty. Or maybe not.
>
> I think using DIRSTYLE to toggle the output isnt that nice.
> Another idea could be to change the DefaultFTPEntryParserFactory to
> allow easier derivation..
>
> ---snip---
> 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();
> } else if (ukey.indexOf("WINDOWS") >= 0) {
> return createNTFTPEntryParser();
> } else if (ukey.indexOf("OS/2") >= 0) {
> return createOS2FTPEntryParser();
> } else if (ukey.indexOf("OS/400") >= 0) {
> return createOS400FTPEntryParser();
> } else {
> throw new ParserInitializationException(
> "Unknown parser type: " + key);
> }
> } catch (ClassCastException e) {
> throw new ParserInitializationException(
> parserClass.getName()
> + " does not implement the interface "
> + "org.apache.commons.net.ftp.FTPFileEntryParser.", e);
> } catch (Throwable e) {
> throw new ParserInitializationException(
> "Error initializing parser", e);
> }
> }
>
> public FTPFileEntryParser createUnixFTPEntryParser()
> {
> return new UnixFTPEntryParser();
> }
>
> public FTPFileEntryParser createVMSVersioningFTPEntryParser()
> {
> return new VMSVersioningFTPEntryParser();
> }
>
> public FTPFileEntryParser createNTFTPEntryParser()
> {
> return new NTFTPEntryParser();
> }
>
> public FTPFileEntryParser createOS2FTPEntryParser()
> {
> return new OS2FTPEntryParser();
> }
>
> public FTPFileEntryParser createOS400FTPEntryParser()
> {
> return new OS400FTPEntryParser();
> }
> ---snip---
>
> That way, you still have the current behaviour, and one could easily
> override the function "createNTFTPEntryParser()" to return an
> UnixFTPEntryParser.
> People (including me) deriving from DefaultFTPEntryParserFactory also
> benefit from later added parsers.
>
>
> Ciao,
> Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
