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.
Dan
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" <[email protected]> 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
AFTFRE1.FILE]
the line read was [CFT *MEM
AFTFRE1.FILE/AFTFRE1.MBR]
the line read was [CFT 36864 28/11/06 15:19:30 *FILE
AFTFRE2.FILE]
the line read was [CFT *MEM
AFTFRE2.FILE/AFTFRE2.MBR]
the line read was [CFT 45056 04/12/06 14:19:37 *FILE
AFTFRE6.FILE]
the line read was [CFT *MEM
AFTFRE6.FILE/AFTFRE6.MBR]
the line read was [QSYSOPR 28672 01/12/06 20:08:04 *FILE
FPKI45POK5.FILE]
the line read was [QSYSOPR *MEM
FPKI45POK5.FILE/FPKI45POK5.MBR]
the line read was [null]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-----------------------------------------------------------------
Find the home of your dreams with eircom net property
Sign up for email alerts now http://www.eircom.net/propertyalerts
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
