Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45786F2D.9080602@manley.name>
Date: Thu, 07 Dec 2006 14:44:45 -0500
From: Daniel Manley <daniel@manley.name>
User-Agent: Thunderbird 1.5.0.8 (X11/20061115)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: enhancements needed for the OS/400 parser?
References: <20061205171409.C9BCC10FB003@herse.apache.org>
In-Reply-To: <20061205171409.C9BCC10FB003@herse.apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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