commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rory Winston" <>
Subject Re: enhancements needed for the OS/400 parser?
Date Tue, 05 Dec 2006 17:13:44 GMT
Hi Daniel

You're the second person to raise the issue about swallowing exceptions in less than a week,
so maybe there is something that we can look at there. Possibly we could have a configurable
"fail-fast" policy for parsing directory entries. On the subject of the OS/400 parser, if
there are changes you have made to get this to work, and if you (and/or your employer) are
happy to donate them to the project, I would be happy to incorporate them into the existing
OS/400 parser implementation in [net], giving you due credit, of course.

Best regards

"Jakarta Commons Developers List" <> wrote:

> Hi all,
> I've been using commons-net for FTP for about two years now.  It's been 
> great and we love it (we = the company at which I work).
> But recently our systems have had to interface with an OS/400-based FTP 
> server.  It's been a lot of trouble.
> First, the default date format didn't match what the server was sending 
> (dd/MM/yy instead of the default yy/MM/dd).  Second, the OS/400 parser 
> only understands the *STMF and *DIR types.  But the server I'm working 
> with has a *FILE type.  Additionally, there's a *MEM type too.  Which 
> leads me to the third problem:  each file listing seems to be in two 
> lines.  One as *FILE and the other as *MEM.  But the *MEM lines don't 
> include size or timestamp.  This results in a null being returned from 
> parseEntry() (because the REGEX doesn't match).  When null is returned, 
> the parsing is aborted.  As a result, I would only ever see the first 
> file alphabetically in a listFiles() call.
> To solve my problem without hacking/customizing the commons-net 1.4.1 
> jar, I subclassed the OS/400 parser to try parsing with two REGEX values.
> Could I suggest changing the core of file entry parsing to not give up 
> when it gets a null back, but rather to give up when the listing data 
> stream is done reading?  Any null's return by parseEntry() should be 
> skipped.  At the least, an exception should be thrown to indicate 
> incompatible FTP listing data.
> But, I also discovered that if there's an exception in parsing (null 
> pointer, runtime, etc), commons-net catches this exception and quietly 
> returns.  IMHO, this should be floated up to the caller to be aware of a 
> problem in parsing the FTP data.
> Cheers,
> Dan
> =======================
> here's some debug I put into commons-net to discover what was being read 
> from the server.
> the line read was [CFT             45056 04/12/06 14:19:31 *FILE      
> the line read was [CFT                                     *MEM       
> the line read was [CFT             36864 28/11/06 15:19:30 *FILE      
> the line read was [CFT                                     *MEM       
> the line read was [CFT             45056 04/12/06 14:19:37 *FILE      
> the line read was [CFT                                     *MEM       
> the line read was [QSYSOPR         28672 01/12/06 20:08:04 *FILE      
> the line read was [QSYSOPR                                 *MEM       
> the line read was [null]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Find the home of your dreams with eircom net property
Sign up for email alerts now

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message