commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Manley <>
Subject Re: enhancements needed for the OS/400 parser?
Date Thu, 07 Dec 2006 19:44:45 GMT
Hi Rory,

I don't know much about OS/400, OS/390 or MVS.  I would feel more 
comfortable submitting a patch to the OS/400 parser and let you guys 
figure out if this is applicable to OS/390 or MVS.


Rory Winston wrote:
> 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
> Rory
> "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:

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

View raw message