commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rory Winston <rwins...@eircom.net>
Subject Re: enhancements needed for the OS/400 parser?
Date Thu, 07 Dec 2006 19:52:56 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>     
>>
>>
>>
>> -----------------------------------------------------------------
>> 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>   
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message