Hi Daniel
No problem. Any submissions welcome.
Thanks
Rory
Daniel Manley wrote:
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" <commons-dev@jakarta.apache.org>
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
